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

31–40 of 93 posts

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

#31

Post by nly »

acdha wrote: post #12
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/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 well (using the RefControl extension). Sure it's not the only way sites can implement this behaviour, and I'm glad an official way exists... but only so Google will use it and then I can disable it. The argument against having an off switch is basically 'well, they're going to fuck you anyway, so bend over and here's some lube'.

You say 'some self-styled privacy advocates' are fear-mongering, well its because webheads keep implementing insanely harmful features and aren't actively making the web better for the privacy concious. They (we, I guess) are grossly under-served.

The response to link tracking should be "Hmm, how can we have websites ask for this permission, and shut down all these nasty means of doing it?" not "oh boy, these people are tracking people in an ugly way, how can we make this fast?". But guess which one is actually a hard problem.

Do you suppose that most everyday users know (not suspect, but know) that Google are watching every link they click on? A technologically illiterate user base cannot consent.

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

#33

Post by DannyBee »

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…

"Yes, this is innovative, but there is also a concept known as antitrust laws."

I'm curious what exact antitrust concept you think this violates.

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

#34

Post by dchichkov »

acdha wrote: post #12
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/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, the user needs the ORIGINAL link! And the user IS NOT leaving the page. Google is free to record a right click. And yet, instead of just recording the right click Google mangles the link instead. WHY? Just evil/stupid? or I'm not understanding some hidden wisdom here?

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

#35

Post by robrenaud »

ams6110 wrote: post #32

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.

Yes, latency matters a lot in aggregate.

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.

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

#36

Post by DannyBee »

throwaway4719 wrote: post #30
karangoeluw wrote: post #28

Earlier quoted context omitted.

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.

This statement, as written, is false. In both the US and the EU, it is only illegal if you use certain techniques to accomplish it, and only then, if it has actual anticompetitive effects.

For example, Microsoft performed a technique known as tying.

But even the claim was not simply "they shipped IE with Windows 98" , or that they introduced other product features to work well with IE first, but "they made IE deliberately difficult to remove, and deliberately and intentfully made it harder for netscape navigator to work". This is not the same as "we made IE the best, and did nothing to competitive products". In particular, it is not the fact that they introduced stuff to IE first, it is the fact that they deliberately harmed the other products.

See paragraphs 94, 95, and 96 on http://law.justia.com/cases/federal/appellate-courts/F3/253/...

Even then, the court held the tying should be analyzed deferentially, and that the US would have to prove this had actual anticompetitive effect.

See in particular, the court's admonition at 93

"As a general rule, courts are properly very skeptical about claims that competition has been harmed by a dominant firm's product design changes. See, e.g., Foremost Pro Color, Inc. v. Eastman Kodak Co., 703 F.2d 534, 544-45 (9th Cir. 1983). In a competitive market, firms routinely innovate in the hope of appealing to consumers, sometimes in the process making their products incompatible with those of rivals; the imposition of liability when a monopolist does the same thing will inevitably deter a certain amount of innovation. This is all the more true in a market, such as this one, in which the product itself is rapidly changing. See Findings of Fact p 59. Judicial deference to product innovation, however, does not mean that a monopolist's product design decisions are per se lawful. See Foremost Pro Color, 703 F.2d at 545; see also Cal. Computer Prods., 613 F.2d at 739, 744; In re IBM Peripheral EDP Devices Antitrust Litig., 481 F. Supp. 965, 1007-08 (N.D. Cal. 1979)."

Note that these are also tying between sold products and given away products, not just given away products. Otherwise, open source linux distributions with large market share would have tying issues (and in fact, they've been unsuccessfully sued for illegal competition before)

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

#37

Post by quonn »

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…

I think the point is that tracking already is possible, but the proposed solution was technically cleaner. So there are not new privacy problems.

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

#38

Post by RobertKerans »

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…

Seconding this, it drives me up the wall. Little frustrations, that mount and mount when you just want to do basic things..

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

#39

Post by nly »

quonn wrote: post #37
nly wrote: post #31

Earlier quoted context omitted.

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

I think the point is that tracking already is possible, but the proposed solution was technically cleaner. So there are not new privacy problems.

There are. It means there are now N+1 instead of N things to worry about for those of us that actually do care. It signals an acceptance that this is something to be encouraged and welcomed. All behind users backs.

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

#40

Post by igrigorik »

dragonwriter wrote: post #24
oconnore wrote: post #21

Earlier quoted context omitted.

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.

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.

Post reply on HN