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

11–20 of 93 posts

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

#11

Post by rictic »

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…

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 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.

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

#12

Post by acdha »

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.

They use that to improve search quality by seeing which links people actually click on – a key signal they're not going to give up – but the good news is that there's a better way to do that and they're already using it. HTML5 added a ping attribute to the tag which tells the browser to make an untracked asynchronous request to a different URL to record the click: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#...

According to the same author, that was deployed over a year ago but only to browsers which support it:

https://plus.google.com/+IlyaGrigorik/posts/fPJNzUf76Nx

Unfortunately, this was implemented in Firefox years ago but disabled due to a fear-mongering campaign by some self-styled privacy advocates who were quite vocal in sharing their misunderstanding of web privacy:

https://web.archive.org/web/20060126211610/http://weblogs.mo...

EDIT: I forgot to mention the new Beacon API, which is getting more traction because it's more powerful and is fully supported as of Firefox 31:

https://developer.mozilla.org/en-US/docs/Web/API/navigator.s...

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

#13

Post by igrigorik »

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.

Actually, this is already handled with , see earlier post: https://plus.google.com/+IlyaGrigorik/posts/fPJNzUf76Nx - you're right it's a big latency improvement!

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

#14

Post by acdha »

mark242 wrote: post #7

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

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.

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

#15

Post by igrigorik »

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…

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/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).

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

#16

Post by igrigorik »

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.

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

#17

Post by [deleted] »

lkbm wrote: post #10
wlamond wrote: post #9

Earlier quoted context omitted.

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.

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]

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

#19

Post by nezza-_- »

lkbm wrote: post #10
wlamond wrote: post #9

Earlier quoted context omitted.

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.

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.

An onclick request wouldn't be concurrent with the loading of the new page.

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

#20

Post by lkbm »

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.

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.
Post reply on HN