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

61–70 of 93 posts

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

#61

Post by ksk »

rictic wrote: post #11
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 straigh…

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.

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

#62

Post by dchichkov »

sliverstorm wrote: post #58
dchichkov wrote: post #56

Earlier quoted context omitted.

So, they don't care, that right-clicks vs left-clicks is actually different data? And that tracking a bit more intelligently can reduce user frustration? So basically it is not stupid/evil, it is just lazy/evil? (And BTW, this is a compliment to Google, as I'm asking the question. Not assuming that by default, as any other big co they've just filled with bozos.)

It could be for a lot of reasons. Busy with other things, lazy- or even about things like performance. Once upon a time I remember when their home page was heavily stripped and used unterminated HTML (e.g. no tag) as part of an effort to minimize bandwidth and improve latency. I don't know why, but especially when something is following the default behavior I do not assume malice.

Unlikely performance. Google search results page is relatively heavy, with Google+/etc. And this one, is a simple change of a few lines of code. Yes, sure, it is a default behavior and I also don't assume malice (evil = lazy / stupid / don't care about users, not malice). I'm just surprised about the oversight, that they apparently don't care about having slightly better click types data and also making the user experience slightly better.

(And BTW, this is again compliment to Google, as I'm surprised. Not assuming that by default, as any other big co they've just filled with bozos.)

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

#63

Post by SquareWheel »

dchichkov wrote: post #34
acdha wrote: post #12

Earlier quoted context omitted.

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/Ele…

Wow. I'd love to see these treacherous "onmousedown" handlers that substitute the link on Google site gone! Especially on the RIGHT click. Actually, I could never understand, why Google substitutes the link with the redirect on the RIGHT click. It is necessary when you LEFT click, the page looses control and it doesn't matter much for users anyway. But WHY do it on the right click? When the user RIGHT clicks the link…

What about Right Click > Open in new tab?

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

#64

Post by oconnore »

igrigorik wrote: post #40
dragonwriter wrote: post #24

Earlier quoted context omitted.

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.

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.

Yeah, it would be quite a feat for an http server to force another http server to inject content into it's TCP stream :P (aka, cross origin)

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

#65

Post by magicalist »

ksk wrote: post #60
acdha wrote: post #53

Earlier quoted context omitted.

> What 'misunderstanding'? I don't want people knowing what third party links I'm clicking on. There's no misunderstanding. I understand it perfectly. I just don't want it. This is exactly what I was talking about: the misunderstanding is thinking that your outrage changes the privacy situation in any way. The options on offer are “Stop using Google” or “Let Google collect data about the search results you click on”;…

Disabling all the JS crap that modern sites layer on top of content - reduces memory and CPU usage. I paid for the memory and CPU, and I don't want several hundreds of MBs spent caching JS interpreter/optimizer data structures and analytics scripts wasting my CPU compute power - decreasing the battery life of my device. While you may be right that the privacy angle is something that few users care about, there are re…

That's fine but not especially relevant to the GP's point. The Google redirect and don't require JavaScript.

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

#66

Post by crystaln »

nly wrote: post #31
acdha wrote: post #12

Earlier quoted context omitted.

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/Ele…

> 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 What 'misunderstanding'? I don't want people knowing what third party links I'm clicking on. There's no misunderstanding. I understand it perfectly. I just don't want it. I disable 3rd party HTTP referers as…

In theory, centralizing such requests with a ping should make it much easier for a browser to disable the pings, so if anything this improves security. Of course, if Google wanted to detect the lack of clicks from a given user and fall back to redirection, they could, in which case the net benefit and harm for security would be zero.

As others have said, there is no way to prevent Google from gathering this information, so adding the capability to a browser doesn't change the situation.

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

#67

Post by ksk »

magicalist wrote: post #65
ksk wrote: post #60

Earlier quoted context omitted.

Disabling all the JS crap that modern sites layer on top of content - reduces memory and CPU usage. I paid for the memory and CPU, and I don't want several hundreds of MBs spent caching JS interpreter/optimizer data structures and analytics scripts wasting my CPU compute power - decreasing the battery life of my device. While you may be right that the privacy angle is something that few users care about, there are re…

That's fine but not especially relevant to the GP's point. The Google redirect and don't require JavaScript.

Ah okay, I didn't know that. I thought that Google returned direct links when you disabled JS.

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

#68

Post by dragonwriter »

oconnore wrote: post #64
igrigorik wrote: post #40

Earlier quoted context omitted.

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.

Yeah, it would be quite a feat for an http server to force another http server to inject content into it's TCP stream :P (aka, cross origin)

Cross-origin could be an HTTP server itself serving content from a different origin via a push channel (which it could do either because the different origins share servers -- which can occur -- or by having, e.g., prefetched the data itself from the foreign server and pushing it.)

HTTP/2, I'm pretty sure, doesn't allow this (and there are all kinds of reasons it wouldn't be a good idea), but it wouldn't necessarily require forcing the other server to push the content.

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

#69

Post by dchichkov »

nly wrote: post #59
phpnode wrote: post #55

Earlier quoted context omitted.

> I'm pretty confident that they don't in my case. Would you mind sharing the details of how you achieve this?

Monitor the HTTP activity with FF developer tools while using Google. It's plain to see that no new traffic flows to Google occurs when I click a link.

AFAIK they track links only for a subset of users and not every time.

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

#70

Post by magicalist »

ksk wrote: post #67
magicalist wrote: post #65

Earlier quoted context omitted.

That's fine but not especially relevant to the GP's point. The Google redirect and don't require JavaScript.

Ah okay, I didn't know that. I thought that Google returned direct links when you disabled JS.

Yeah, it appears that they both add and remove the direct links in JS, so with JS disabled you never see the direct link (at least, that's what I get when I disable javascript).
Post reply on HN