Re: Using preload for "async" CSS by changing `rel` trick


Thanks all for feedback!

On Sun, Jan 14, 2018 at 12:05 PM, Chris Harrelson <>

> I share Ben's concern that the relationship between the browser cache and
> rendering behavior during the lifetime of a web page is insufficiently
> specified to be fully reliable. I also agree with Ilya that the issue is
> orthogonal to preload. I'd call it a rendering pipeline definitional issue
> rather than a resource loading issue.
> Two examples for images, in which onload does not guarantee that the next
> frame will show an image. Reasons: (1) image decoding may be async, and (2)
> image caching may be async.
> Progress has been made very recently on (1), by defining the async
> attribute on images. Chrome now respects them. However, there are still
> situations where (2) is a problem. e.g. I believe that if an <img> were
> removed from the DOM and re-inserted, it may not be in the memory cache
> (instead would be in the on-disk cache, or not even there), meaning that it
> would not necessarily display in the next frame. It's also a problem when
> reloading a "cached" web app - the images may not appear in time to avoid
> flashing.

That's a good example that would be nice to drive clarity on. On a related
note, I think we also need to explore what happens under memory pressure to
various renderer/memory caches in our pipelines. In the case of preload,
the renderer may also be holding on to a non-cacheable HTTP response, in
which case it'd be nice for us to have some smarts for how things are

Let's continue this part of the thread in:

> Regarding style sheets: I think the spec / implementations should ensure
> that "loaded" style sheets always apply to the next frame drawn to the
> screen. I'm hoping we can make progress addressing cases in which this
> fails in 2018. Blink and Webkit both have some strange and heuristic
> behavior during load regarding how style sheets apply, which we should try
> to fix.

Where's the right place to surface and keep track of this conversation? CSS
WG, somewhere else?


> On Sat, Jan 13, 2018 at 11:50 PM, Anne van Kesteren <>
> wrote:
>> On Sat, Jan 13, 2018 at 7:23 PM, Ilya Grigorik <>
>> wrote:
>> > Anne, what's missing for preload specifically? Happy to address it if we
>> > can.
>> > My observation here is that you can remove preload out of this question
>> and
>> > rephrase it as: "If I programmatically inject a <link rel=stylesheet>
>> what
>> > execution guarantees, if any, are provided?"
>> I think it's more complex. It's a combination of:
>> * What does the standard say
>> * What do implementations do
>> * What do websites rely on
>> where the latter two are much more important than the first. I think
>> ideally it's always asynchronous, but in practice <script> can block
>> on the stylesheet being loaded (this is defined in HTML). Ben's
>> example shows something different however which relates to the
>> "implementation details" (not quite as they're observable) of preload
>> in Chromium and WebKit. That also shows why it's important to define
>> this. If sites start to rely on <link rel=preload onload> and from
>> that event handler inject a <link rel=stylesheet> of which they then
>> immediately query the styles, it better be defined as otherwise
>> browsers are back at having to reverse engineer each other to figure
>> out how the web works.
>> (I'm sure you've seen the "X is the new IE6" meme. This is really what
>> that comes down to.)
>> --

Received on Monday, 15 January 2018 16:38:53 UTC