News for hackers. Stuff that matters.
Re:Instant.page by animationwill on Monday September 14, 2020 @08:39PM (#24476719)
>> Before a user clicks on a link, they hover their mouse over that link. When a user has hovered for 65 ms there is one chance out of two that they will click on that link, so instant.page starts preloading at this moment, leaving on average over 300 ms for the page to preload.

This sounds great! I immediately wonder how many additional HTTPS requests will hit your web server fleet. Has anyone using this calculated a percentage of additional requests vs additional clicks from their http logs?

Re:Instant.page by youngtaff on Tuesday September 15, 2020 @02:40AM (#24478488)
In my case it was multiple extra requests (7x?) it was enough that we could see a degradation in server response times.

Even with that extra server load we still saw improvements visitor performance as measuring using Real User Monitoring

Re:Instant.page by eli on Monday September 14, 2020 @08:48PM (#24476782)
A neat hack would be to have it prefetch only pages already cached on the server (though those are the least in need of speeding up). Or maybe the prefetch requests go into a separate queue at a lower priority.
Re:Instant.page by xevrem on Monday September 14, 2020 @08:49PM (#24476794)
Isn't that how modern preloading works on browsers already?
Re:Instant.page by HenryBemis on Tuesday September 15, 2020 @01:18AM (#24478097)
So my browser starts loading a page from a link that I haven't clicked. Does anyone else see the potential security nightmare on this scenario?

Drive-by downloads, malware, etc. I totally get the benefits of this mechanism until it starts being abused for tracking and delivery malware, and then add-ons will (hopefully) appear to block this.

Re:Instant.page by renewiltord on Tuesday September 15, 2020 @04:19AM (#24478995)
What, how is this a security nightmare? What's your threat model? You think I, the website operator, am the enemy? Then I can just window.location you. You think the website operator is hosting compromising links because they've been suckered? But then once you click them you're going to be compromised.

I swear to God, so many HN comments just say "security nightmare" for everything.

Re:Instant.page by RobLach on Tuesday September 15, 2020 @02:14AM (#24478354)
It's no different than any other javascript enabled browser + web page.

The modern web is pulling in the background all the time.

You'd have to go back decades for 1 click to equal 1 GET.

Re:Instant.page by theon144 on Tuesday September 15, 2020 @04:23AM (#24479016)
Funnily enough, HN therefore seems to be a time traveler from decades ago :)
Re:Instant.page by renewiltord on Tuesday September 15, 2020 @03:01PM (#24485340)
7 requests per page load. No, I don't think so.
Re:Instant.page by theon144 on Tuesday September 22, 2020 @02:24AM (#24551496)
None of which are javascript-triggered.
Re:Instant.page by warkdarrior on Tuesday September 15, 2020 @02:12AM (#24478343)
The preloaded page won't get rendered until you click on it. Assuming that malware activates only by rendering, not simply by downloading, this seems safe.
Re:Instant.page by toomuchtodo on Monday September 14, 2020 @08:44PM (#24476751)
You would also want to break out CDN requests versus http server requests; theoretically, CDN requests are cheaper than requests to your server fleet.
Re:Instant.page by aabbcc1241 on Tuesday September 15, 2020 @03:50AM (#24478830)
Sounds like that could fraud statistics like GA
Re:Instant.page by ComodoHacker on Tuesday September 15, 2020 @04:51AM (#24479180)
>only the HTML is preloaded
Re:Instant.page by grp000 on Monday September 14, 2020 @08:49PM (#24476787)
They say two loads per click, so it sounds like you'll have 100% increase rate in requests less hovers under 65ms that click.