9 ms·

Reactive prefetch on Google Search: 100-150ms speedup

169 points by igrigorik 12y ago

cryptoz 12y ago
Will other browsers be implementing support for this? How much of this type of improvement should we view as Google's ambitions and fast pace of execution, and how much as a Microsoft-style move to lock in users to a specific platform that offers a better, but incompatible, experience? I'm not taking sides here, I don't know enough to make a judgement. But it's interesting that Google seems to be increasing their pattern of standards-tweaking in order to make a superior product - and who can fault them for that? But isn't that how we got so much of the mess that MS made? What's to be done?
- alec 12y ago
  I don't think this offers an "incompatible experience" - my reading of the post is that the experience is fully compatible and that users of non-Chrome browsers will still be able to use Google Search. Currently, some/all non-Chrome browsers won't do the extra prefetches.
- jewel 12y ago
  I think this is just a work-around for the sloppiness of the web. If all the resources for a page were compiled into a single file and sent all at once, this wouldn't be necessary, but that'd be inefficient to for subsequent page requests. Sites that want to get the same speedup can make sure they don't have any secondary resources that block page rendering. Finally, the particular mechanism, link rel="prefetch" is used by Bing and IE 11 [1]. Google has just found a way to prefetch even earlier than normal, by inserting the prefetch links into the search page as soon as the user clicks. [1]: http://blogs.msdn.com/b/ie/archive/2013/12/04/getting-to-the-content-you-want-faster-in-ie11.aspx?Redirected=true http://blogs.msdn.com/b/ie/archive/2013/12/04/getting-to-the...
  - toomuchtodo 12y ago
    > I think this is just a work-around for the sloppiness of the web. If all the resources for a page were compiled into a single file and sent all at once, this wouldn't be necessary, but that'd be inefficient to for subsequent page requests. The benefit of the web was that you didn't have a fat GUI locally. With the push to aggregate assets together and get the entire UI/logic into the client browser, cached, and read off of remote services, we're slowly making our way back to local GUI apps. This time, the browser is the OS (forgive the poor analogy). What was old is new again.
  - deleted 12y ago
    [deleted]
- rictic 12y ago
  My (biased) view on the matter is that this instance is a useful standards are pushed forwards. rel='prefetch' is well trod (some support existed in Firefox <3.5) and part of the HTML5 standard. The browser appears to be given a lot of leeway in how to implement link prefetching (the page is just hinting that prefetching seems like a good idea), so persisting prefetches across navigations seems entirely within the spirit and the letter of the standard. The high profile launch of this feature in a major product is a signal that other browsers can take that persisting a prefetch across a navigation is worthwhile. That sort of feedback about what works and what's important is very helpful to the standards process, and very much aligned with the spirit of rough consensus and running code. Abuse of standards, to me, looks more like intentionally breaking compatibility with other browsers or implementing features that are easy for one party to implement and hard for anyone else to. For example, ActiveX was problematic in part because it was straightforwards to implement on Windows and a nightmare to try to implement anywhere else. This forced other browsers to either make their non-windows users second class citizens, or fall behind on feature parity. I work at google, but as a ground level engineer working on internal tooling, not on Chrome or Search or anything. My views here are my own.
  - ksk 12y ago
    Or to look at it another way, Google made their search experience faster on platforms they control Android/Chrome, but slower (or normal speed, whatever you want to call it) everywhere else. I'm pretty sure if MS did that they'd be (rightfully) criticized for it.
- igrigorik 12y ago
  Yes, the hope is that they will be! That's why we're working on the "Resource Hints" spec, which documents "reactive prefetch" as one of explicit use cases: https://cdn.rawgit.com/w3c/resource-hints/e19f621dad9856a92bf43a06a62489c0058d19de/index.html#reactive-resource-prefetching-preload https://cdn.rawgit.com/w3c/resource-hints/e19f621dad9856a92b... The early feedback from FF, IE, (and to some extent, Webkit), folks have been positive, and I'm hoping this can be a cross-browser feature in 2015 (yes, I'm an optimist).
qwerta 12y ago
There is simple way to speed this up. All Google Search links point to redirection service: www.google.gr/url?example.com. It is trivial to write script which makes those links direct.
- j_s 12y ago
  A couple open source add-ons to do this: Chrome: https://chrome.google.com/webstore/detail/undirect/dohbiijnjeiejifbgfdhfknogknkglio/reviews https://chrome.google.com/webstore/detail/undirect/dohbiijnj... (source: https://code.google.com/p/undirect/ https://code.google.com/p/undirect/ ) Firefox: https://addons.mozilla.org/en-US/firefox/addon/google-no-tracking-url/ https://addons.mozilla.org/en-US/firefox/addon/google-no-tra... (source: http://matagus.github.io/remove-google-redirects-addon/ http://matagus.github.io/remove-google-redirects-addon/ ) They sometimes run into issues as Google tweaks the search results page.
- wlamond 12y ago
  I don't work at Google, but I think they do that to gather click through data for links and positions on the results page. Simply linking to the destination would prevent them from learning valuable information about the quality of their search engine and what users think is valuable.
  - lkbm 12y ago
    I'm sure they do. They could probably get that data from the vast majority of users using Javascript. I assume a concurrent onclick request wouldn't slow things down noticeably.
    - deleted 12y ago
      [deleted]
    - nezza-_- 12y ago
      An onclick request wouldn't be concurrent with the loading of the new page.
mark242 12y ago
I would imagine that once HTTP/2 becomes a serious implementation, this kind of thing will be unnecessary.
- acdha 12y ago
  HTTP/2 won't help with connections to a previously-unused server – you'd still have to take the initial connection latency, although after the initial request an optimized endpoint would be able to push render-blocking resources out before the browser parses the page and requests them.
- igrigorik 12y ago
  No, HTTP/2 has no effect on this. The insight here is that we're initiating the fetch for the HTML and its critical resources in parallel... which requires that the page initiating the navigation knows which critical resources are being used on the target page.
  - oconnore 12y ago
    With HTTP/2 server push, there is no difference between acquiring the html and the critical resources. They all get sent without a round trip. Then there is no latency benefit from requesting in parallel, because there is no round trip to avoid.
    - dragonwriter 12y ago
      But isn't HTTP/2 push restricted to same-origin content? Critical resources may not be same-origin, so I'd expect this technique to have some utility even when HTTP/2 is fully deployed on clients and servers and fully utilized.
      - igrigorik 12y ago
        Actually, you're both right. With http/2 the server can push critical assets delivering similar results. But, that requires that the server supports http/2 and is smart enough to initiate the push, AND those resources are same-origin. The benefit of above technique is that it's deployable today, doesn't require the destination server to be upgraded, and works for cross-origin resources.
dzhiurgis 12y ago
How long until Google just allows to host the results on their website - the destination opens instantly (preloaded while you gaze thru the results). I mean it's not great for net neutrality standpoint, but it's a next logical step for them.
- lkbm 12y ago
  Well, they do have snippets from Wikipedia and the like. Bing (I believe) had the magnifying glass tool that would show you a thumbnail of the result on hover. Google came out with something similar for a bit--you'd click a result and it would pull up a thumbnail(?) to the right. That may still be a thing, actually.
- Animats 12y ago
  That seems to be where Google is going with HTTP2. That multiplexed pipe approach only works well if everything comes from the same site.
throwaway4719 12y ago
Posting from a throwaway account since I work on a competing browser. I think Google needs to check its steps quite carefully when doing things like these. For quite some time they have leveraged their search monopoly (think about their EU search market share) to bring search/browser-type integration features to chrome first. I would say this is abusing a monopoly in one market segment (search in the EU) to attempt to create a monopoly in another segment (browsers in the EU) by continually making sure that Chrome is the browser that works better than other browsers when using Google search services. Yes, this is innovative, but there is also a concept known as antitrust laws. Another way of bringing this to the market would have been to invite competing browsers to use this and build a credible time plan for a simultaneous launch for all the browsers that wanted to support this.
- cmelbye 12y ago
  I'm confused, isn't it an open standard? http://www.w3.org/html/wg/drafts/html/master/links.html#link-type-prefetch http://www.w3.org/html/wg/drafts/html/master/links.html#link... Perhaps their implementation differs, but they even showed the JS they're using to perform the prefetch in the post. It doesn't seem like they're trying to hide anything.
  - throwaway4719 12y ago
    They kept the fact that they were going to deploy this on the search service that has a monopoly on search in EU secret until it was launched in Chrome. Before this, this link prefetching has seen very little use in the wild.
    - LukeB_UK 12y ago
      They don't have to tell anyone what they're doing. As cmelbye stated, it's an open standard. Other browsers can implement it if they wish.
- karangoeluw 12y ago
  So you're saying they should giveaway their competitive edge? Learn to survive competition.
ams6110 12y ago
is 0.1 seconds improvement a big deal? Especially on mobile/g3 that is lost in the noise. By comparison, pages right here on HN routinely take 10+ seconds to load for me, even on a gigabit uplink.
- robrenaud 12y ago
  Yes, latency matters a lot in aggregate. http://perspectives.mvdirona.com/2009/10/31/TheCostOfLatency.aspx http://perspectives.mvdirona.com/2009/10/31/TheCostOfLatency... From Marissa Mayer while at Google: > Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%. > Ouch. Why? Why, when users had asked for this, did they seem to hate it? > After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds. > Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.
  - taeric 12y ago
    This feels like a situation where we found an answer, and extrapolated to say it must be the answer. The article does at least have plenty of examples. I just can't help but think some of these are heavily confounded with "changes cause people to change." That is, I'd be curious to know if any of the tests did nothing other than increase latency. The increase from 10 to 30 results, for example, had to have changed the look of the page. Would that alone have been enough to change behavior? My hypothesis is that it would be. Especially if there was a viable alternative that was still familiar to the user. Can't fathom by how much, though.
mkramlich 12y ago
if you like this topic you might also be interested in a recent HN post of mine, that did not get much attention, on the topic of all the various possible techniques or patterns we can draw from in order to improve performance (eg. lower latency, increased throughput) or scalability: https://news.ycombinator.com/item?id=8665707 https://news.ycombinator.com/item?id=8665707
daxfohl 12y ago
Should reactively download precompiled javascript too.
Illniyar 12y ago
Other then search engines what type of sites gain any benefit from this? For external links, if you aren't a search engine, you don't know what resources need to be prefetched and even if you did you will have no way of knowing when it changes (other then manually). For internal links, in most cases the resources are already cached and http 2.0 server push is going to fix the rest. Beyond that, the API looks clunky - instead of having a "prefetch" attribute on a link, you need to add more links with special syntax to the header dynamically. What's the point in adding this functionality to a browser? this looks like an implementation specifically designed to make only google search faster.
- 3minus1 12y ago
  > you don't know what resources need to be prefetched and even if you did you will have no way of knowing when it changes you could find out if google set up an API that exposed this information. Then a simple plugin could update the links on your page.
rjammala 12y ago
book by the author: http://chimera.labs.oreilly.com/books/1230000000545/index.html http://chimera.labs.oreilly.com/books/1230000000545/index.ht...

169 points by igrigorik 12y ago

Will other browsers be implementing support for this? How much of this type of improvement should we view as Google's ambitions and fast pace of execution, and how much as a Microsoft-style move to lock in users to a specific platform that offers a better, but incompatible, experience? I'm not taking sides here, I don't know enough to make a judgement. But it's interesting that Google seems to be increasing their pattern of standards-tweaking in order to make a superior product - and who can fault them for that? But isn't that how we got so much of the mess that MS made? What's to be done?

alec 12y ago
I don't think this offers an "incompatible experience" - my reading of the post is that the experience is fully compatible and that users of non-Chrome browsers will still be able to use Google Search. Currently, some/all non-Chrome browsers won't do the extra prefetches.
jewel 12y ago
I think this is just a work-around for the sloppiness of the web. If all the resources for a page were compiled into a single file and sent all at once, this wouldn't be necessary, but that'd be inefficient to for subsequent page requests. Sites that want to get the same speedup can make sure they don't have any secondary resources that block page rendering. Finally, the particular mechanism, link rel="prefetch" is used by Bing and IE 11 [1]. Google has just found a way to prefetch even earlier than normal, by inserting the prefetch links into the search page as soon as the user clicks. [1]: http://blogs.msdn.com/b/ie/archive/2013/12/04/getting-to-the-content-you-want-faster-in-ie11.aspx?Redirected=true http://blogs.msdn.com/b/ie/archive/2013/12/04/getting-to-the...
- toomuchtodo 12y ago
  > I think this is just a work-around for the sloppiness of the web. If all the resources for a page were compiled into a single file and sent all at once, this wouldn't be necessary, but that'd be inefficient to for subsequent page requests. The benefit of the web was that you didn't have a fat GUI locally. With the push to aggregate assets together and get the entire UI/logic into the client browser, cached, and read off of remote services, we're slowly making our way back to local GUI apps. This time, the browser is the OS (forgive the poor analogy). What was old is new again.
- deleted 12y ago
  [deleted]
rictic 12y ago
My (biased) view on the matter is that this instance is a useful standards are pushed forwards. rel='prefetch' is well trod (some support existed in Firefox <3.5) and part of the HTML5 standard. The browser appears to be given a lot of leeway in how to implement link prefetching (the page is just hinting that prefetching seems like a good idea), so persisting prefetches across navigations seems entirely within the spirit and the letter of the standard. The high profile launch of this feature in a major product is a signal that other browsers can take that persisting a prefetch across a navigation is worthwhile. That sort of feedback about what works and what's important is very helpful to the standards process, and very much aligned with the spirit of rough consensus and running code. Abuse of standards, to me, looks more like intentionally breaking compatibility with other browsers or implementing features that are easy for one party to implement and hard for anyone else to. For example, ActiveX was problematic in part because it was straightforwards to implement on Windows and a nightmare to try to implement anywhere else. This forced other browsers to either make their non-windows users second class citizens, or fall behind on feature parity. I work at google, but as a ground level engineer working on internal tooling, not on Chrome or Search or anything. My views here are my own.
- ksk 12y ago
  Or to look at it another way, Google made their search experience faster on platforms they control Android/Chrome, but slower (or normal speed, whatever you want to call it) everywhere else. I'm pretty sure if MS did that they'd be (rightfully) criticized for it.
igrigorik 12y ago
Yes, the hope is that they will be! That's why we're working on the "Resource Hints" spec, which documents "reactive prefetch" as one of explicit use cases: https://cdn.rawgit.com/w3c/resource-hints/e19f621dad9856a92bf43a06a62489c0058d19de/index.html#reactive-resource-prefetching-preload https://cdn.rawgit.com/w3c/resource-hints/e19f621dad9856a92b... The early feedback from FF, IE, (and to some extent, Webkit), folks have been positive, and I'm hoping this can be a cross-browser feature in 2015 (yes, I'm an optimist).

qwerta 12y ago

There is simple way to speed this up. All Google Search links point to redirection service: www.google.gr/url?example.com. It is trivial to write script which makes those links direct.

j_s 12y ago
A couple open source add-ons to do this: Chrome: https://chrome.google.com/webstore/detail/undirect/dohbiijnjeiejifbgfdhfknogknkglio/reviews https://chrome.google.com/webstore/detail/undirect/dohbiijnj... (source: https://code.google.com/p/undirect/ https://code.google.com/p/undirect/ ) Firefox: https://addons.mozilla.org/en-US/firefox/addon/google-no-tracking-url/ https://addons.mozilla.org/en-US/firefox/addon/google-no-tra... (source: http://matagus.github.io/remove-google-redirects-addon/ http://matagus.github.io/remove-google-redirects-addon/ ) They sometimes run into issues as Google tweaks the search results page.
wlamond 12y ago
I don't work at Google, but I think they do that to gather click through data for links and positions on the results page. Simply linking to the destination would prevent them from learning valuable information about the quality of their search engine and what users think is valuable.
- lkbm 12y ago
  I'm sure they do. They could probably get that data from the vast majority of users using Javascript. I assume a concurrent onclick request wouldn't slow things down noticeably.
  - deleted 12y ago
    [deleted]
  - nezza-_- 12y ago
    An onclick request wouldn't be concurrent with the loading of the new page.

mark242 12y ago

I would imagine that once HTTP/2 becomes a serious implementation, this kind of thing will be unnecessary.

acdha 12y ago
HTTP/2 won't help with connections to a previously-unused server – you'd still have to take the initial connection latency, although after the initial request an optimized endpoint would be able to push render-blocking resources out before the browser parses the page and requests them.
igrigorik 12y ago
No, HTTP/2 has no effect on this. The insight here is that we're initiating the fetch for the HTML and its critical resources in parallel... which requires that the page initiating the navigation knows which critical resources are being used on the target page.
- oconnore 12y ago
  With HTTP/2 server push, there is no difference between acquiring the html and the critical resources. They all get sent without a round trip. Then there is no latency benefit from requesting in parallel, because there is no round trip to avoid.
  - dragonwriter 12y ago
    But isn't HTTP/2 push restricted to same-origin content? Critical resources may not be same-origin, so I'd expect this technique to have some utility even when HTTP/2 is fully deployed on clients and servers and fully utilized.
    - igrigorik 12y ago
      Actually, you're both right. With http/2 the server can push critical assets delivering similar results. But, that requires that the server supports http/2 and is smart enough to initiate the push, AND those resources are same-origin. The benefit of above technique is that it's deployable today, doesn't require the destination server to be upgraded, and works for cross-origin resources.

dzhiurgis 12y ago

How long until Google just allows to host the results on their website - the destination opens instantly (preloaded while you gaze thru the results). I mean it's not great for net neutrality standpoint, but it's a next logical step for them.

lkbm 12y ago
Well, they do have snippets from Wikipedia and the like. Bing (I believe) had the magnifying glass tool that would show you a thumbnail of the result on hover. Google came out with something similar for a bit--you'd click a result and it would pull up a thumbnail(?) to the right. That may still be a thing, actually.
Animats 12y ago
That seems to be where Google is going with HTTP2. That multiplexed pipe approach only works well if everything comes from the same site.

throwaway4719 12y ago

Posting from a throwaway account since I work on a competing browser. I think Google needs to check its steps quite carefully when doing things like these. For quite some time they have leveraged their search monopoly (think about their EU search market share) to bring search/browser-type integration features to chrome first. I would say this is abusing a monopoly in one market segment (search in the EU) to attempt to create a monopoly in another segment (browsers in the EU) by continually making sure that Chrome is the browser that works better than other browsers when using Google search services. Yes, this is innovative, but there is also a concept known as antitrust laws. Another way of bringing this to the market would have been to invite competing browsers to use this and build a credible time plan for a simultaneous launch for all the browsers that wanted to support this.

cmelbye 12y ago
I'm confused, isn't it an open standard? http://www.w3.org/html/wg/drafts/html/master/links.html#link-type-prefetch http://www.w3.org/html/wg/drafts/html/master/links.html#link... Perhaps their implementation differs, but they even showed the JS they're using to perform the prefetch in the post. It doesn't seem like they're trying to hide anything.
- throwaway4719 12y ago
  They kept the fact that they were going to deploy this on the search service that has a monopoly on search in EU secret until it was launched in Chrome. Before this, this link prefetching has seen very little use in the wild.
  - LukeB_UK 12y ago
    They don't have to tell anyone what they're doing. As cmelbye stated, it's an open standard. Other browsers can implement it if they wish.
karangoeluw 12y ago
So you're saying they should giveaway their competitive edge? Learn to survive competition.

ams6110 12y ago

is 0.1 seconds improvement a big deal? Especially on mobile/g3 that is lost in the noise. By comparison, pages right here on HN routinely take 10+ seconds to load for me, even on a gigabit uplink.

robrenaud 12y ago
Yes, latency matters a lot in aggregate. http://perspectives.mvdirona.com/2009/10/31/TheCostOfLatency.aspx http://perspectives.mvdirona.com/2009/10/31/TheCostOfLatency... From Marissa Mayer while at Google: > Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%. > Ouch. Why? Why, when users had asked for this, did they seem to hate it? > After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds. > Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.
- taeric 12y ago
  This feels like a situation where we found an answer, and extrapolated to say it must be the answer. The article does at least have plenty of examples. I just can't help but think some of these are heavily confounded with "changes cause people to change." That is, I'd be curious to know if any of the tests did nothing other than increase latency. The increase from 10 to 30 results, for example, had to have changed the look of the page. Would that alone have been enough to change behavior? My hypothesis is that it would be. Especially if there was a viable alternative that was still familiar to the user. Can't fathom by how much, though.

mkramlich 12y ago

if you like this topic you might also be interested in a recent HN post of mine, that did not get much attention, on the topic of all the various possible techniques or patterns we can draw from in order to improve performance (eg. lower latency, increased throughput) or scalability: https://news.ycombinator.com/item?id=8665707 https://news.ycombinator.com/item?id=8665707

daxfohl 12y ago

Should reactively download precompiled javascript too.

Illniyar 12y ago

Other then search engines what type of sites gain any benefit from this? For external links, if you aren't a search engine, you don't know what resources need to be prefetched and even if you did you will have no way of knowing when it changes (other then manually). For internal links, in most cases the resources are already cached and http 2.0 server push is going to fix the rest. Beyond that, the API looks clunky - instead of having a "prefetch" attribute on a link, you need to add more links with special syntax to the header dynamically. What's the point in adding this functionality to a browser? this looks like an implementation specifically designed to make only google search faster.

3minus1 12y ago
> you don't know what resources need to be prefetched and even if you did you will have no way of knowing when it changes you could find out if google set up an API that exposed this information. Then a simple plugin could update the links on your page.

rjammala 12y ago

book by the author: http://chimera.labs.oreilly.com/books/1230000000545/index.html http://chimera.labs.oreilly.com/books/1230000000545/index.ht...