Shared publicly  - 
Huge performance win for G+ team by switching their CSS download from XHR to a regular link tag! 
Interesting results from an experiment I ran recently to switch Google+ from downloading CSS via XHR to using the link tag.

We were using XHR to download CSS (this was to work around an issue in IE - exceeding the limit on the number of rules in a single stylesheet; for convenience we used XHR for all browsers). When it came it our attention that XHRs are requested at low priority (unless they are sync), we decided to run an experiment to see its impact on G+ latency.

In SPDY capable browsers this resulted in a big latency improvement. In Chrome 27 we saw a 4x speedup at the median, and 5x at 25th percentile. In Firefox 21 we saw a 5x speedup at median, and 8x at 25th percentile. No significant impact was seen at the 99th percentile.

In conclusion, in a SPDY world, XHRs are requested at low priority (except sync XHRs), and are opaque to the browser. Using declarative markup like <link> enables the browser to do appropriate resource prioritization.
Peng Lanston's profile photoNanda Kishore's profile photoKim Hogeling's profile photoMariano Glas's profile photo
Nice to see that straight forward = good performance :)
Thanks for sharing the details. Hopefully the browsers give us a way to asynchronously load CSS and multipart script contents.
webfont.js loads the font stylesheet in via XHR - could this mean we need to re-evaluate if it's still the best way of including webfonts?
What took google so long to discover this was the problem? It should not have been done in the first place. Using XHR for anything other than web services and scripts (for jsonp mostly) should be discouraged.
+Joshua Baker thanks. Just saw someone else mentioned it earlier. But was this change done for all browsers?
+Shubhie Panicker Compared to XHR, the <link> tag has the nice property that it is apparent in the page, and HTML pre-scanners can find it early to trigger downloads, thus combatting network latency.

In addition, a speculative (and concurrent) CSS parser could already parse the CSS, hiding even more latency, because the styles are likely ready to be consumed by the time they are requested by the HTML parser or JS engine.

Paper here:

Looking forward for browsers to get there ;)
If most of the speed improvements are from the speculative parser and pre-fetching, do you see any benefits dynamically insert <link> tags vs using XHRs?
+Xavi Ramirez An ordinary pre-scanner will not see dynamically inserted link tags, but depending on the JS engine it's still less overhead to insert a <link> node into the DOM tree, and trigger the pre-fetching hooks, compared to XHR.
Just out of interest, how many is the maximum number of selectors allowed by IE in a single stylesheet?
One would guess inline CSS would be even faster then link or xhr. I wonder if G+ would experiment with that.
+Drit Suljoti Not necessarily.  Take BBC News, which had 300K+ CSS last I looked.  If that's inlined, the HTML parser would have to go past all this to get the next bits of HTML.  That would serialize discovery of further resources, the prescanner would have to do more work, etc., etc.
Add a comment...