Shared publicly  - 
Chrome’s preloader delivers a ~20% speed improvement!

Wait, what’s a preloader? The preload scanner is designed to look ahead in the requested document and discover critical resources (CSS, JavaScript, images), such that they can be dispatched as soon as possible - this helps reduce the overhead of network latency. All modern browsers use this or similar technique to help speed up your browsing.

How do I design my pages to take advantage of the preloader? Simple, specify your critical resources in the document (aka, HTML). The PreloadScanner does not (and cannot) speculatively execute JavaScript, so if you are scheduling resources from JS, then you’re not getting the benefit of the PreloadScanner. This is why declaring your resources in the HTML markup is so important for performance!

Below results are a direct comparison with Chrome preloader ON vs. OFF, run against ~2000 sites. For full and raw results, see: - courtesy of +Patrick Meenan and +James Simonsen.

Curious to learn more about Chrome networking performance? Check out “High Performance Networking in Google Chrome” @
MARTELKA's profile photoAlistair Lattimore's profile photoSamim Mirhosseini's profile photoLars Lentfer's profile photo
This is nice info, +Ilya Grigorik, nice work.

Although this update admittedly pertains to an improvement in Chrome specifically, your advice about declaring more assets in the markup would of course impact all browsers. It'd be really helpful for developers like me to see some analysis on whether optimizing for Chrome/Blink's preloading behavior in the way you recommend or may not adversely affect other popular browsers' (Firefox, IE 8+, iOS Safari, Android 2.3 native browser, Opera Mini and Mobile) loading performance. For example, might a browser that does not implement prefetch as aggressively presumably have a faster "time to glass" if developers continue to utilize dynamic (JS-based) loading of heavier scripts, and minimizing direct links to assets in the source? I'd presume so, but only based on my own small-sample-set research. More info on the cross-browser impact of optimizations like this would be hugely beneficial. I'd love to know which techniques are a good idea to use broadly, and which are more "nice to know" for potential future use.

Thanks again!
+Scott Jehl as I mentioned in the post, AFAIK, all browsers employ the same (or very similar) optimization strategy - aka, have a preloader. Hence, I would expect similar benefits across all browsers.

Note that the HTMLPreloadScanner is part of WebKit (and Blink), not Chrome specifically. Hence iOS, Safari, and all other WebKit derivatives are in the same boat. The PreloadScanner emits the URLs, and browser specific network stack then determines when to makes the dispatch: this is where Chrome will differ from other (webkit) browser.

In short: no, you're highly unlikely to get a faster "time to render" through JS-based loading.

+Patrick McManus would be the guy to comment on how FF handles this. :-)
Thanks, Ilya. Interesting stuff. And to be sure, there are other reasons for dynamic loading, such as the ability to decide which dependencies need to even load in the first place, but I still get the impression that the practice of deferring requests with JS is largely performance-minded as well. Is that based on old thinking? If removing an HTTP request entirely from the critical path helps improve time to render, wouldn't asynchronously loading that script make a similar impact across relevant browsers today?
+Scott Jehl, +Ilya Grigorik is right.. Gecko (Firefox) works similarly - the speculative loader spits out the urls to the network stack which decides which ones to load immediately and which ones to wait on. css/js/html are always loaded immediately and images are loaded speculatively too as long as the higher priority stuff has finished transferring. so  creating references to css/js through js isn't such a great idea.

If you're using SPDY it can all be requested immediately and the images are just tagged with a lower priority.. spdy can make sure their transfer doesn't interfere with higher priority items.
+Scott Jehl I don't think its "old thinking" -- the best request is a request not made. Having said that, ideally you want to let the browser know as soon as possible what resources it will need to construct the initial page (aka, the critical path): that's why the preloader exists, use it! Anything that doesn't belong on the critical path should be deferred, and loaded later (if at all).
That's a clearer way of putting it, Ilya. Thanks for the clarification. I do wish script elements had something like [media] and [supports] attributes - detecting environment and feature conditions is still a common reason we dynamically load.
Good questions +Scott Jehl !

And I'm guessing the answer is the same, +Ilya Grigorik , but still: does the same principle also apply for the web-page ranking by Google for speed of initial loading?

You could get a faster initial load if you did, in fact, defer as much as possible, even if that would be worse for the prefetcher - resulting in a faster load for the Google Bot.
+Hasan Karagülmez don't optimize for "making the crawler think it loaded fast" - that'll backfire. Instead, optimize for "making the page load fast for your users"... The rest will take care of itself.
I think you really need to work on your graphs Ilya. It took me an age to work out what this was trying to show. Maybe even just changing the title to "Percent Improvement with Chrome Preloader On".

Wouldn't it be better to plot base time vs. 50/75/95 percentile times?
+Ilya Grigorik So I see that the standard Google Analytics tracking JavaScript snippet is a large part of the delay before "start render" in my page.

Is there something different we should be doing for Google Analytics?

Perhaps something that can help browsers other than Chrome too?
+Ilya Grigorik +Hasan Karagülmez thanks for your thoughts. Already using the Async snippet exactly as prescribed.

It's not all the time but the waterfall sometimes shows a delay in rendering whilst Async scripts are loading, then the render kicking in in the middle of GA loading the JS some 40/120ms after it could have rendered the page.

If it happens randomly whilst using it makes me wonder about real user experiences.
+Ilya Grigorik : How do I go disable the preloader (specifically for images). I am debugging a particular issue and have a hunch that there is something thats not working well and need to temporarily disable this feature to see whats going on.

I couldnt find any command line switch to do this. Short of a new build, any recommendations on how best to proceed?
+Paddy Ganti there is no way to disable the preloader. You'd have to compile a custom build.
Will the preload scanner shuffle the sequences of the JavaScript source files loading?
+袁源 it may, all depends on how the application loads the files (which attributes, XHR vs markup, etc).
+Ilya Grigorik Here is a project using AngularJs v1.2.16, and in the JavaScript controllers, the MomentJs lib( is used. However, the MomentJs lib happened to be loaded after the javascript controller files on one occasion, while the controllers files are at the bottom of the HTML file. May it be a consequence of  the preload scanner?
+袁源 maybe, but it could be many things - e.g. slow server response or high latency, etc. The waterfall sequence may vary run to run due to many different reasons.
Add a comment...