[whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets

[Ian Hickson]

On Sun, 10 Jun 2012, Scott Jehl wrote:
> 
> CSS referenced by link elements or @import has always come with the 
> limitation that it will block page rendering until it has finished 
> loading.

Not always, actually. In theory, it's not necessary. Originally, the 
blocking was added to avoid flashes of unstyled content (FoUCs). Later, it 
turned out scripts relied on this blocking in their computations, which 
rather forced the issue.


> However, the downside of this behavior is that ALL CSS, not just the CSS 
> that will apply to the particular device and viewport at the time of 
> page load, will block page rendering. This means that sites that use 
> CSS3 media queries to deliver different styles to different browsing 
> conditions will be delivering more and more overhead.

Given the size of CSS sheets, I don't think that's a huge deal. It's 
already possible to merge all one's sheets into a single gzip-compressed 
file, at which point the bulk of the slowdown is in the latency, not the 
bandwidth. (That is, the time from the page being received to the first 
byte of the style sheet being received will vastly overwhelm the time 
between the first byte and the last byte of the style sheet.)


> Recently, I did some research into how browsers request CSS files via 
> link elements with inapplicable media queries. The results were grim. Of 
> all browsers that I tested, every one would not only request all CSS 
> files referenced with inapplicable media types/queries, but they would 
> also block the rendering of page content until all of those inapplicable 
> styles were loaded.
> 
> Here's the test page including a table with the test results: 
> http://scottjehl.github.com/CSS-Download-Tests/

Part of the problem is that the style sheets are supposed to be exposed to 
the DOM, which is detectable from script. So you have to block before 
script executes. You can work around this a bit by putting your scripts 
first. (In general, the less you observe what the browser is doing, the 
cleverer it can be. This makes testing a bit difficult...)


> Proposal for change:
> 
> I'd like to propose that the spec recommends that vendors defer the 
> loading of Stylesheets referenced via inapplicable media so that they do 
> not block page rendering.

Unfortunately this is not Web-compatible, as I understand it, because it 
affects how they are exposed in the DOM.


We could add a feature that prevents blocking on a style sheet if the 
media query doesn't apply, I guess, if there's implementor interest. I 
recommend seeing if any vendor is interested in experimenting with this.


> 2. Reducing the amount of time that an unresponsive stylesheet can block 
> page rendering
> 
> One last suggestion. In the research above, I found that many modern 
> browsers will prevent page rendering for upwards of 30 seconds 
> (sometimes more) to ensure that all stylesheets have loaded. If a server 
> is not responding for some reason, this results in a completely unusable 
> experience.

Blocking scripts when waiting for a style sheet is required by the 
specification, but blocking rendering is not. This is a quality-of- 
implementation issue.


On Sun, 10 Jun 2012, Scott Jehl wrote:
> 
> That said, merely deferring the load of stylesheets that don't apply at 
> initial load would be a huge performance improvement for users.

Are you sure? In high-bandwidth, high-latency situations, this seems 
highly unlikely. (I agree that it could be true in low-bandwidth, 
low-latency situations, but those are much rarer.) The round-trip time 
will often far outweigh the download time, and multiple requests can be 
made in parallel, not blocking on each other. If it takes 10 seconds to 
get a file, and each file fits in a single TCP packet, then you could 
download one file or six files and it would in either case take 10 
seconds. Not loading them would have no client-side-visible difference.


On Sun, 10 Jun 2012, Boris Zbarsky wrote:
>
> E.g. nothing in the spec actually has any requirements at all on 
> starting rendering.

Actually technically the spec requires that rendering happen when the 
event loop spins. :-)


On Mon, 11 Jun 2012, Boris Zbarsky wrote:
> > 
> > I think you've rightfully pointed out that the lazy-loading idea 
> > probably won't fly with vendors and could even cause problems in 
> > certain cases.
> 
> I think it would be quite doable and the spec should be changed to allow 
> it. I'm just not sure that the spec should _require_ it in all cases, 
> because we can end up in situations where simply detecting whether 
> something should be lazy-loaded or not is more expensive than just 
> loading it.

The spec doesn't require any network loads to be done in finite time, 
which essentially allows lazy loading. (The only requirement is that 
scripts block if there's style sheets that could affect them.)

The spec also says, specifically for <link> resources, that:

# User agents may opt to only try to obtain such resources when they are
# needed, instead of pro-actively fetching all the external resources
# that are not applied.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'