Reactive prefetch on Google Search: 100-150ms speedup
plus.google.com
Reactive prefetch on Google Search: 100-150ms speedup
1–10 of 93 posts
Re: Reactive prefetch on Google Search: 100-150ms speedup
#2Will 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?
Re: Reactive prefetch on Google Search: 100-150ms speedup
#3Will 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 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.
Re: Reactive prefetch on Google Search: 100-150ms speedup
#4Will 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 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...
Re: Reactive prefetch on Google Search: 100-150ms speedup
#5There 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.
Re: Reactive prefetch on Google Search: 100-150ms speedup
#6Will 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…
> 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.
Re: Reactive prefetch on Google Search: 100-150ms speedup
#7I would imagine that once HTTP/2 becomes a serious implementation, this kind of thing will be unnecessary.
Re: Reactive prefetch on Google Search: 100-150ms speedup
#8There 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.
A couple open source add-ons to do this:
Chrome: https://chrome.google.com/webstore/detail/undirect/dohbiijnj... (source: https://code.google.com/p/undirect/ )
Firefox: https://addons.mozilla.org/en-US/firefox/addon/google-no-tra... (source: http://matagus.github.io/remove-google-redirects-addon/ )
They sometimes run into issues as Google tweaks the search results page.
Re: Reactive prefetch on Google Search: 100-150ms speedup
#9There 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.
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.
Re: Reactive prefetch on Google Search: 100-150ms speedup
#10There 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.
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.