Google mobile search is getting faster - to be exact, 100-150 milliseconds faster! When you click on one of the search results, the browser begins fetching the destination page… and here's the trick: we also provide a hint to the browser indicating which other critical resources it should fetch in parallel to speed up rendering of the destination page!
This is a powerful pattern and one that you can use to accelerate your site as well. The key insight is that we are not speculatively prefetching resources and do not incur unnecessary downloads. Instead, we wait for the user to click the link and tell us exactly where they are headed, and once we know that, we tell the browser which other resources it should fetch in parallel - aka, reactive prefetch!
As you can infer, implementing the above strategy requires a lot of smarts both in the browser and within the search engine... First, we need to know the list of critical resources that may delay rendering of the destination page for every page on the web! No small feat, but the Search team has us covered - they're good like that. Next, we need a browser API that allows us to invoke the prefetch logic when the click occurs: the search page listens for the click event, and once invoked, dynamically inserts prefetch hints into the search results page. Finally, this is where Chrome comes in: as the search results page is unloaded, the browser begins fetching the hinted resources in parallel with the request for the destination page. The net result is that the critical resources are fetched much sooner, allowing the browser to render the destination page 100-150 milliseconds earlier.
P.S. Currently, reactive prefetch is only enabled for users of Google Chrome on Android, as it is the only browser that supports (a) dynamically inserted prefetch hints, and (b) reliably allows prefetch requests to persist across navigations. We hope to add support for other browsers once these features become available!
This is a powerful pattern and one that you can use to accelerate your site as well. The key insight is that we are not speculatively prefetching resources and do not incur unnecessary downloads. Instead, we wait for the user to click the link and tell us exactly where they are headed, and once we know that, we tell the browser which other resources it should fetch in parallel - aka, reactive prefetch!
As you can infer, implementing the above strategy requires a lot of smarts both in the browser and within the search engine... First, we need to know the list of critical resources that may delay rendering of the destination page for every page on the web! No small feat, but the Search team has us covered - they're good like that. Next, we need a browser API that allows us to invoke the prefetch logic when the click occurs: the search page listens for the click event, and once invoked, dynamically inserts prefetch hints into the search results page. Finally, this is where Chrome comes in: as the search results page is unloaded, the browser begins fetching the hinted resources in parallel with the request for the destination page. The net result is that the critical resources are fetched much sooner, allowing the browser to render the destination page 100-150 milliseconds earlier.
P.S. Currently, reactive prefetch is only enabled for users of Google Chrome on Android, as it is the only browser that supports (a) dynamically inserted prefetch hints, and (b) reliably allows prefetch requests to persist across navigations. We hope to add support for other browsers once these features become available!

View 45 previous comments
I was looking into https://w3c.github.io/resource-hints and I dont know if I am getting it right. Does this help page load times on direct access to the website? And is there any performace difference between meta header <link> and HTTP header Link version?52w
+Martin Odstrčilík yes, the hint is injected as you navigate to the site, allowing the browser to fetch the index page and the CSS resource in parallel.
Re, element vs header: header is restricted to, well, headers.. it can be processed sooner, but once the page is active, you can inject elements.52w
+Ilya Grigorik And is there any performance difference between meta header <link> and HTTP header Link version of the same resource? I was trying this out in Chrome Network monitor and it seems, that Chrome recognizes only <link> meta header.52w
+Martin Odstrčilík depends on how the response is served. Many sites "flush" their HTTP response headers early, which also means the Link header can be processed earlier. If, however, your headers and response come back at the same time, then the difference will be much less. Link header should work.. you're unlikely to see that fetch in DevTools, as it's initiated before the page is 'active' in devtools.52w
+Ilya Grigorik To conclude this, let's consider this use-case. I have a JavaScript file that needs to be loaded for the website to be fully functional. Using HTTP header Link: <http://website.com/asset/my_critical_js.js>; rel=prefetch I will get better user experience, because website will be ready to use sooner than without this header. Am I right? Or am I missing something here? Thanks52w
+Martin Odstrčilík yep, that's correct.52w