Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reactive prefetch on Google Search: 100-150ms speedup

plus.google.com

Post reply on HN
Print view View original

21–30 of 93 posts

Re: Reactive prefetch on Google Search: 100-150ms speedup

#21

Post by oconnore »

igrigorik wrote: post #16
mark242 wrote: post #7

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

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.

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.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#22

Post by Animats »

dzhiurgis wrote: post #18

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.

That seems to be where Google is going with HTTP2. That multiplexed pipe approach only works well if everything comes from the same site.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#23

Post by Animats »

qwerta wrote: post #5

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.

If you do that, and block ads, and block trackers with Ghostery, you'll get a substantial improvement in performance.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#24

Post by dragonwriter »

oconnore wrote: post #21
igrigorik wrote: post #16

Earlier quoted context omitted.

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.

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.

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.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#25

Post by [deleted] »

jewel wrote: post #4
cryptoz wrote: post #2

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 pat…

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 u…

[deleted]

Re: Reactive prefetch on Google Search: 100-150ms speedup

#26

Post by throwaway4719 »

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.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#27

Post by cmelbye »

throwaway4719 wrote: post #26

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 t…

I'm confused, isn't it an open standard? 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.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#28

Post by karangoeluw »

throwaway4719 wrote: post #26

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 t…

So you're saying they should giveaway their competitive edge? Learn to survive competition.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#29

Post by throwaway4719 »

cmelbye wrote: post #27
throwaway4719 wrote: post #26

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 t…

I'm confused, isn't it an open standard? 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.

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.

Re: Reactive prefetch on Google Search: 100-150ms speedup

#30

Post by throwaway4719 »

karangoeluw wrote: post #28
throwaway4719 wrote: post #26

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 t…

So you're saying they should giveaway their competitive edge? Learn to survive competition.

It is illegal to use a monopoly in one market to create a monopoly in another market.
Post reply on HN