12 ms·

Instant.page

265 points by vinnyglennon 6y ago

animationwill 6y ago
>> 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?
- toomuchtodo 6y ago
  You would also want to break out CDN requests versus http server requests; theoretically, CDN requests are cheaper than requests to your server fleet.
- eli 6y ago
  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.
- grp000 6y ago
  They say two loads per click, so it sounds like you'll have 100% increase rate in requests less hovers under 65ms that click.
- xevrem 6y ago
  Isn't that how modern preloading works on browsers already?
- HenryBemis 6y ago
  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.
  - warkdarrior 6y ago
    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.
  - RobLach 6y ago
    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.
    - theon144 6y ago
      Funnily enough, HN therefore seems to be a time traveler from decades ago :)
      - renewiltord 6y ago
        7 requests per page load. No, I don't think so.
        theon144 6y ago
        None of which are javascript-triggered.
  - renewiltord 6y ago
    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.
- youngtaff 6y ago
  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
- aabbcc1241 6y ago
  Sounds like that could fraud statistics like GA
  - ComodoHacker 6y ago
    >only the HTML is preloaded
moralestapia 6y ago
Great idea, thanks for sharing!
- laumars 6y ago
  It’s an old idea that keeps resurfacing and frankly I think it misses the real problem of modern websites: they’re too bloated with code that the user is expected to run and yet isn’t there to serve the user. I’d love to see a world where cloud computing / time sharing was tipped on its head and users and businesses could charge back their compute time spent running JavaScript trackers, analytics, etc from the sites their users visit. Of course this fantasy would never be technically possible but one can dream.
  - foxrob92 6y ago
    >It’s an old idea that keeps resurfacing and frankly I think it misses the real problem of modern websites: they’re too bloated with code that the user is expected to run and yet isn’t there to serve the user. I can't find it now, but I thought there was an article recently that looked at page rendering times and how they have changed over the years (as bandwidth has also increased). In general, page rendering time hasn't decreased as much over the last few decades as you would expect, and a part of that is the amount of js (often for tracking - not to serve the user) that is pervasive nowadays.
  - lewiscollard 6y ago
    > It’s an old idea that keeps resurfacing and frankly I think it misses the real problem of modern websites: they’re too bloated with code that the user is expected to run and yet isn’t there to serve the user. I agree that the latter is a problem with many modern websites. That, however, does not mean that this approach does not have a place; many people (especially people among the HN and HN-adjacent crowd, who tend towards simple layouts and static site generators) optimise their sites as much as is reasonably possible, and specifically, don't pessimise their sites with megabytes of tracker & ad scripts. For those people, instant.page might well be a worthwhile optimisation.
CGamesPlay 6y ago
> instant.page’s script is hosted serverless with Cloudflare Workers so that there’s no server to hack into. There are a lot of reasons that this software is "safe" but this absolutely isn't one of them and highlights to me as a potential user that you haven't thought through your thread model. The subresource integrity line should absolutely be the headline here.
- dieulot 6y ago
  It’s useful for the ~.4% of browsers that will execute a module script without checking its integrity. But I do indeed intend to put more emphasis on SRI in the future.
  - CGamesPlay 6y ago
    I encourage you to think through some ways that an attacker would compromise my service and how your service is a gateway to that compromise. Notably, "serverless" doesn't mean anything to the consumer of your service--it has always just meant "somebody else's server". So, why don't you talk on this page about how your Cloudflare account has a very strong password and 2factor enabled? It doesn't make sense because it doesn't cover the threat model for me, which is that somebody--you, Cloudflare, Saudi hackers--compromises the server. One thing you may have meant by "serverless" is that you don't use a database / don't collect data on users. This is another angle you might want to use to highlight the safety of using your service.
  - strogonoff 6y ago
    > It’s useful for the ~.4% of browsers that will execute a module script without checking its integrity. What if someone modifies not only the script, but also integrity hashes in snippets on your site?
    - progval 6y ago
      If they can modify the integrity hash on your site, then they can probably modify anything else on your site.
makeworld 6y ago
Hmm, my Pi-Hole blocks this. I wonder why. Exact matches for instant.page found in: - https://block.energized.pro/blu/formats/hosts.txt - https://v.firebog.net/hosts/AdguardDNS.txt
- dieulot 6y ago
  It’s due to bullshit from EasyList: https://github.com/easylist/easylist/issues/4023 https://github.com/easylist/easylist/issues/4023
  - slenk 6y ago
    You said it yourself: > it’s a theoretical minor violation of privacy Their goal is to protect privacy. It makes sense to me.
    - dieulot 6y ago
      > theoretical
      - choo-t 6y ago
        Like everything until it's used.
    - perryizgr8 6y ago
      Then why doesn't easylist add google.com and facebook.com to their list? I'm sure G/FB track every single click you do on their pages. Huge privacy violation. Not even theoretical. Block youtube also, they are tracking your viewing habits, how much you watched, where you skipped, etc. Just block all this. I wish there was a way to easily override individual entries in easylist/ubo.
      - monadgonad 6y ago
        Because those are services that people use and consent to (implicitly at least) violating their privacy. There's a huge difference between YouTube tracking my habits to improve my YouTube experience (as well as for marketing reasons) and a third party tracking them solely for marketing reasons.
dang 6y ago
A few months ago: https://news.ycombinator.com/item?id=23203658 https://news.ycombinator.com/item?id=23203658. (Once a submission has had significant attention, we mark reposts as dupes for a year or so. See https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html.) Also a big discussion from last year: https://news.ycombinator.com/item?id=19122727 https://news.ycombinator.com/item?id=19122727
kissgyorgy 6y ago
Try Gatsby. It can be even faster than this.
- oatmealsnap 6y ago
  Ok, I'll just rewrite my clients' entire website using a trendy, brand new JS framework that is built on top of an ever-changing trendy JS library, requiring the entire site to be compiled from scratch when my client wants to update a title. Different tools for different projects. Gatsby and Gridsome, or any other static site generator is not comparable to a simple script like this.
  - beaker52 6y ago
    Throwing a random script onto a website I was responsible for, which claims to magically preload things and make things faster is not my idea of simple. Easy, perhaps. Risky, yes. Simple, no.
  - kissgyorgy 6y ago
    This can speed up your legacy site at most 200-300 ms. If your page load time is above 500ms, this won't do much...
stephenhuey 6y ago
2 decades ago there was a product whose name escapes me. It was a tool to speed up web browsing, but instead of preloading which link it thought you were about to click next, it simply started preloading all the hyperlinks on the webpage.
- blhack 6y ago
  Some of us just used to include the next images as 1px squares to speed up loading of images that the user might click on next. Back then the images really were the only big bandwidth hog.
  - rimliu 6y ago
    Back then one of the common mistakes used to be taking a huge image and "resize" it with "width" and "height" attributes on the img tag. It still is, but it used to too.
- josefrichter 6y ago
  I think this was available as browser extension. Maybe still is.
- judge2020 6y ago
  Sounds like AMP :) RES for Reddit also has an option that preloads every post that shows on the page for instant loading at the cost of bandwidth (I had an increase of ~100gb for one month)
- tribby 6y ago
  I wonder if you're thinking of netzero - IIRC they did this after they became a paid service, to market their 56k offering against early DSL
- laumars 6y ago
  And didn’t that get people into trouble in corporate networks because some of the links it followed were links the user would never have clicked on. I vaguely recall that problem arising in the late 90s / early 00s.
ritonlajoie 6y ago
A little bit off topic : the axios website on mobile 4G loads quite instantly on my phone. Even better than most FANG websites. I'm not sure it's only the CDN doing this. Any clue?
- dieulot 6y ago
  For as-fast-as-possible first time load, use TLS 1.3 + inline CSS + server close to user (with a CDN for global audiences) + not much JS (absolutely no 30kB framework). For as-fast-as-possible subsequent page loads, use preloading (à la instant.page) + light SPA. My previous library, InstantClick, did just that but it’s alas mostly just a proof of concept (lacks good docs), I intend to “reboot“ it this year and announce it on HN. FANG websites aren’t a very good site speed standard. :)
- adventured 6y ago
  It's modestly fast for how bloated it is, I'll grant them that. From Pingdom's Washington DC test location, on this Axios page: https://www.axios.com/tropical-storm-sally-forms-off-florida-coast-ab1e97df-99bf-4e21-93a8-b3f0bccda493.html https://www.axios.com/tropical-storm-sally-forms-off-florida... It rings in at 414ms, 1.9mb uncompressed (~1mb compressed), with a rather obnoxious 90 requests. They're loading 961kb of script and 197kb of font content. A whole 41kb of actual HTML content in that obese vat of bytes. On a small Quora page with no major images, they come in at 2mb of junk, 1500ms to load, with 79 requests. A typical small Wikipedia page with one image will come in at 400kb-500kb and load in 400-500ms, with 26 requests. GTMetrix lists the average load page size for their performance tests, compressed (!), at 3mb (with 89 requests). Framework bloat is like living on a sugar diet.
  - minxomat 6y ago
    Thanks for using Pingdom btw. Always happy to see our products used in the wild
- ffpip 6y ago
  Axios loads off Google's servers. They serve only AMP pages. They don't have any non-amp servers If you log the requests, you can see that they load everything from ampproject.org
rado 6y ago
Beware, this broke my lightbox component, because the images had href.
aphroz 6y ago
I managed to have a 603ms click on mobile, who can beat me ?
- ffpip 6y ago
  0 :) https://i.imgur.com/OhmLu5I.jpg https://i.imgur.com/OhmLu5I.jpg
  - aphroz 6y ago
    The longer the better, the more you will cheat latency ;)
- codetrotter 6y ago
  Longest click I was able to make on mobile was 510ms. And my initial click, which was not attempting to use a long time, was about 69ms.
  - aphroz 6y ago
    The challenge is to release your finger just before the contextual menu pop out.
    - codetrotter 6y ago
      Yup
helsinkiandrew 6y ago
How does this relate to the preload spec <link rel=“preload”> is it only preloading when the link is visible/hovered over? https://w3c.github.io/preload/ https://w3c.github.io/preload/ https://caniuse.com/link-rel-preload https://caniuse.com/link-rel-preload
- divbzero 6y ago
  Looks like instant.page at its core uses <link rel=prefetch>: [1] const prefetcher = document.createElement('link') prefetcher.rel = 'prefetch' prefetcher.href = url document.head.appendChild(prefetcher) [1]: https://github.com/instantpage/instant.page/blob/v5.1.0/instantpage.js#L230-L233 https://github.com/instantpage/instant.page/blob/v5.1.0/inst...
jwr 6y ago
I think rather than waste bandwidth and fight for those last 80ms, we should fix sites that take multiple seconds to load. Especially after the first load — subsequent pages should load instantly. In general, it's 2020, and if every click on your site takes 5 seconds, something is very wrong.
- hombre_fatal 6y ago
  It makes a big difference and doesn't only help websites that take seconds to load. Just look at its hover->click speed demo on the landing page. I'm getting 500ms+ if I click it casually like I do most links. All of that time could be spent loading the next page. https://dev.to/ https://dev.to/ (blog platform) does prefetching to great effect. The onus is on you to decide if this would create a bunch of false positive prefetches for your desktop users, like if your website was a bunch of densely packed links. You could also scope this to prefetch only a subset of links. But your users deserve more deliberation over their UX than a kneejerk yay/nay.
- Thev00d00 6y ago
  /me scowls at the Google Cloud console.
- onion2k 6y ago
  subsequent pages should load instantly Every page should load fast, obviously, but instantly means the data has to be prefetched and that's potentially a lot of data to download that the user might never actually need. That's a waste of everyone's bandwidth, especially on mobile. Pages that a user will view (eg first page behind a login), or that they're very likely to view (eg top result in a search), should be prefetched/prerendered but whether you should prefetch more than that requires thought and measurement.
  - ComodoHacker 6y ago
    A great stimulus for "thought and measurement" would be user feedback. If users could see who wastes their data plan as easily as they can see who eats their battery, this would change the picture. Browser vendors should implement per-site traffic breakdown.
compumike 6y ago
We use this, with <body data-instant-intensity="10"> on https://ultimateelectronicsbook.com/ https://ultimateelectronicsbook.com/ It's already a static Jekyll-compiled site served from a CDN, but combined with other techniques, instant.page makes the site quite snappy. (We had the EasyList blocking problem described below, so we started bundling it into our own post-load JS bundle.) Honestly, unrelated, but the biggest performance improvement for us has been to do server-side rendering of the LaTeX equations, rather than using MathJax client-side.
polytely 6y ago
Fasted hover to click I got was 93ms, it's really hard to get under a 100ms, very curious to see who the fastest clicker on hn is.
- grahoho 6y ago
  I got 73 ms.
- grenoire 6y ago
  Got 0 ms by chance through dragging my mouse from right to left across the button and timing it in. I feel like a tool-assisted speedrun robot now.
- thegabriele 6y ago
  You don't have to think about it ("click when on the box"), casually doing it took me to 43ms
- FractalParadigm 6y ago
  The mobile site features a similar button, which measures the time between screentouch and release - tapping it casually like I would any other link netted ~120 ms, fastest I could physically tap was 20ms! That demonstration alone was enough to pique my interest and give this a try.
  - perryizgr8 6y ago
    I'm regularly getting 7-15ms. Not tapping particularly fast. Could it have something to do with the touch refresh rate? I'm on Chrome/GalaxyS10.
    - FractalParadigm 6y ago
      Interesting theory. To throw out some 'anecdata' (maybe we can turn this into a sort of study?) - my three-device test (iPhone 6S and Pixel 2 XL at 60Hz, 12.9" iPad Pro at 120Hz) would seem to indicate that the refresh speed does not affect the touch refresh rate, however, this could be the result of the large performance differences between devices used, as the average and maximum times trend down with the newer/faster devices in testing. Min/avg/max of 10 taps, as fast as possible; 17/26.6/36 -- iPhone 6S 16/23.7/34 -- Pixel 2 XL 17/21.7/33 -- 12.9" iPad Pro I would probably conclude overall that my hands are just slower than yours!
Gormisdomai 6y ago
Presumably this won't work on mobile because there's no hover to trigger the pre-loading. I wonder if there's something else that could be used there.
- INdek 6y ago
  They mention mobile in the page, they use the onmousedown to preload, which (they claim) gives in average a 90ms improvement, instead of waiting for the click evento.
beaker52 6y ago
Pre-loading is a great idea when you're dealing with optimised, cached content. Pre-loading with some third-party script as a magic fix for free milliseconds is something people should think twice about.
deleted 6y ago
[deleted]
The_rationalist 6y ago
How is this different than https://github.com/GoogleChromeLabs/quicklink https://github.com/GoogleChromeLabs/quicklink?
- lewiscollard 6y ago
  Quicklink prefetches links as they arrive in the viewport. Instant.page prefetches them when you hover over them.
chrismorgan 6y ago
I think this library has gotten steadily worse over time. After 1.2.2, each new release just introduces more configurability that >99.99% of sites won’t want, more complications, more bugs and more misfeatures. Most notably version 5 introduced triggering load on mouse down, which I call catastrophically wrong, 100% dealbreaker with prejudice. 5.1.0 made it opt-in, but it’s still functionality that just shouldn’t exist. I golfed 1.2.2 down a long way, removing other configurability and functionality that I didn’t want; see https://news.ycombinator.com/item?id=23204741 https://news.ycombinator.com/item?id=23204741, part of the discussion a few months ago at https://news.ycombinator.com/item?id=23203658 https://news.ycombinator.com/item?id=23203658 (where there was much wringing of hands about the whole load-on-mousedown mess). 5.1.0 is 2,842 bytes, 1,169 gzipped; my version got to 981 bytes, 532 gzipped. At that point it’s almost certainly cheaper to inline it than to have it as an external script (though if your CSP has script-src excluding unsafe-inline, you’ll need to give it a nonce or sha hash if you want to do it inline).
- pimterry 6y ago
  > version 5 introduced triggering load on mouse down, which I call catastrophically wrong, 100% dealbreaker with prejudice. Could you provide more context? Why is that catastrophically wrong?
  - chrismorgan 6y ago
    See some of the discussion on https://news.ycombinator.com/item?id=23203658 https://news.ycombinator.com/item?id=23203658. It breaks how links work normally.
    - celsoazevedo 6y ago
      https://instant.page/changelog https://instant.page/changelog I agree it was a bad decision to do that by default, but it's opt-in since 5.1: "Make triggering clicks on mousedown opt-in".
      - chrismorgan 6y ago
kabacha 6y ago
Is shaving off 1% really justifies such a hack? The web is already so extremely implicit that even seasoned web-developers are lost in it.
Tepix 6y ago
Self-hosting Hosting the script yourself is also possible. Download the latest version at https://instant.page/5.1.0 https://instant.page/5.1.0 then add a module script tag just before </body>: <script src="instantpage-5.1.0.js" type="module" defer></script> You can also install it via npm: npm i instant.page
noname120 6y ago
With Vimium[1] I consistently get 0 ms from hover to click. :) [1] https://github.com/philc/vimium https://github.com/philc/vimium
cblconfederate 6y ago
Even if this is a bandaid solution attacking the wrong problem, it's great to see people caring for speed for a change. But isn't it dangerous? How does it know you re not preloading the "please delete everything" link? It would be nice to have a standard html tag preloading="yes" so that one day browsers can have it as standard feature. I'd much rather have this than AMP
- whylo 6y ago
  > But isn't it dangerous? How does it know you re not preloading the "please delete everything" link? In a perfect world no-one would be using links for actions which modify state - they should always be a POST behind a button, not a GET behind a link. But in the real world this is probably a legitimate concern. They do have methods to mark links as non-preloadable (https://instant.page/blacklist https://instant.page/blacklist), but anyone using it should definitely do a thorough test, not just copy and paste and hope for the best
- lewiscollard 6y ago
  > But isn't it dangerous? How does it know you re not preloading the "please delete everything" link? As a sibling comment points out, if it's possible for someone to delete everything via a link, your users have already lost. Someone could, e.g., trick your users into loading an IMG tag or an IFRAME pointing to that page, or give them a shortened URL that redirects to your "delete everything" page. GET requests should never have side effects.
  - cblconfederate 6y ago
    clicking an activation link in an email ?
jooize 6y ago
Would it save time by loading pages without making a normal new page request? I mean using AJAX/jQuery/… and updating URL with window.history.pushState.
donbrae 6y ago
I use instant.page and it doesn't appear to work in Safari (at least in desktop version 13.1.2): I can't see any transfers in the Network tab on hover.
tiffanyh 6y ago
This is the successor to http://instantclick.io http://instantclick.io for those who recall that library. Some things to note: - at it's core, this is using PREFETCH - Safari at the moment doesn't support link prefetching, so this library doesn't work for Safari - yes, it works on mobile and arguably people see even better results on mobile due to inconsistent network/latency of mobile networks. An old HN discussion on the predecessor library: https://news.ycombinator.com/item?id=7365204 https://news.ycombinator.com/item?id=7365204
masswerk 6y ago
I'm somewhat concerned about this kind of preloading. Given that network traffic is a huge, if not the major part of the total energy consumption of IT (I've seen estimates of about 40% of the total), this is adding a significant extra (according to the webpage only 50% of the triggered preloads are actually followed by a page view, which equals to an increase of 100% in initial traffic) for a gain of a few milliseconds. Mind that reducing (initial) page loads by a fraction will do the same for you and even more.

265 points by vinnyglennon 6y ago

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

toomuchtodo 6y ago
You would also want to break out CDN requests versus http server requests; theoretically, CDN requests are cheaper than requests to your server fleet.
eli 6y ago
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.
grp000 6y ago
They say two loads per click, so it sounds like you'll have 100% increase rate in requests less hovers under 65ms that click.
xevrem 6y ago
Isn't that how modern preloading works on browsers already?
HenryBemis 6y ago
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.
- warkdarrior 6y ago
  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.
- RobLach 6y ago
  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.
  - theon144 6y ago
    Funnily enough, HN therefore seems to be a time traveler from decades ago :)
    - renewiltord 6y ago
      7 requests per page load. No, I don't think so.
      - theon144 6y ago
        None of which are javascript-triggered.
- renewiltord 6y ago
  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.
youngtaff 6y ago
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
aabbcc1241 6y ago
Sounds like that could fraud statistics like GA
- ComodoHacker 6y ago
  >only the HTML is preloaded

moralestapia 6y ago

Great idea, thanks for sharing!

laumars 6y ago
It’s an old idea that keeps resurfacing and frankly I think it misses the real problem of modern websites: they’re too bloated with code that the user is expected to run and yet isn’t there to serve the user. I’d love to see a world where cloud computing / time sharing was tipped on its head and users and businesses could charge back their compute time spent running JavaScript trackers, analytics, etc from the sites their users visit. Of course this fantasy would never be technically possible but one can dream.
- foxrob92 6y ago
  >It’s an old idea that keeps resurfacing and frankly I think it misses the real problem of modern websites: they’re too bloated with code that the user is expected to run and yet isn’t there to serve the user. I can't find it now, but I thought there was an article recently that looked at page rendering times and how they have changed over the years (as bandwidth has also increased). In general, page rendering time hasn't decreased as much over the last few decades as you would expect, and a part of that is the amount of js (often for tracking - not to serve the user) that is pervasive nowadays.
- lewiscollard 6y ago
  > It’s an old idea that keeps resurfacing and frankly I think it misses the real problem of modern websites: they’re too bloated with code that the user is expected to run and yet isn’t there to serve the user. I agree that the latter is a problem with many modern websites. That, however, does not mean that this approach does not have a place; many people (especially people among the HN and HN-adjacent crowd, who tend towards simple layouts and static site generators) optimise their sites as much as is reasonably possible, and specifically, don't pessimise their sites with megabytes of tracker & ad scripts. For those people, instant.page might well be a worthwhile optimisation.

CGamesPlay 6y ago

> instant.page’s script is hosted serverless with Cloudflare Workers so that there’s no server to hack into. There are a lot of reasons that this software is "safe" but this absolutely isn't one of them and highlights to me as a potential user that you haven't thought through your thread model. The subresource integrity line should absolutely be the headline here.

dieulot 6y ago
It’s useful for the ~.4% of browsers that will execute a module script without checking its integrity. But I do indeed intend to put more emphasis on SRI in the future.
- CGamesPlay 6y ago
  I encourage you to think through some ways that an attacker would compromise my service and how your service is a gateway to that compromise. Notably, "serverless" doesn't mean anything to the consumer of your service--it has always just meant "somebody else's server". So, why don't you talk on this page about how your Cloudflare account has a very strong password and 2factor enabled? It doesn't make sense because it doesn't cover the threat model for me, which is that somebody--you, Cloudflare, Saudi hackers--compromises the server. One thing you may have meant by "serverless" is that you don't use a database / don't collect data on users. This is another angle you might want to use to highlight the safety of using your service.
- strogonoff 6y ago
  > It’s useful for the ~.4% of browsers that will execute a module script without checking its integrity. What if someone modifies not only the script, but also integrity hashes in snippets on your site?
  - progval 6y ago
    If they can modify the integrity hash on your site, then they can probably modify anything else on your site.

makeworld 6y ago

Hmm, my Pi-Hole blocks this. I wonder why. Exact matches for instant.page found in: - https://block.energized.pro/blu/formats/hosts.txt - https://v.firebog.net/hosts/AdguardDNS.txt

dieulot 6y ago
It’s due to bullshit from EasyList: https://github.com/easylist/easylist/issues/4023 https://github.com/easylist/easylist/issues/4023
- slenk 6y ago
  You said it yourself: > it’s a theoretical minor violation of privacy Their goal is to protect privacy. It makes sense to me.
  - dieulot 6y ago
    > theoretical
    - choo-t 6y ago
      Like everything until it's used.
  - perryizgr8 6y ago
    Then why doesn't easylist add google.com and facebook.com to their list? I'm sure G/FB track every single click you do on their pages. Huge privacy violation. Not even theoretical. Block youtube also, they are tracking your viewing habits, how much you watched, where you skipped, etc. Just block all this. I wish there was a way to easily override individual entries in easylist/ubo.
    - monadgonad 6y ago
      Because those are services that people use and consent to (implicitly at least) violating their privacy. There's a huge difference between YouTube tracking my habits to improve my YouTube experience (as well as for marketing reasons) and a third party tracking them solely for marketing reasons.

dang 6y ago

A few months ago: https://news.ycombinator.com/item?id=23203658 https://news.ycombinator.com/item?id=23203658. (Once a submission has had significant attention, we mark reposts as dupes for a year or so. See https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html.) Also a big discussion from last year: https://news.ycombinator.com/item?id=19122727 https://news.ycombinator.com/item?id=19122727

kissgyorgy 6y ago

Try Gatsby. It can be even faster than this.

oatmealsnap 6y ago
Ok, I'll just rewrite my clients' entire website using a trendy, brand new JS framework that is built on top of an ever-changing trendy JS library, requiring the entire site to be compiled from scratch when my client wants to update a title. Different tools for different projects. Gatsby and Gridsome, or any other static site generator is not comparable to a simple script like this.
- beaker52 6y ago
  Throwing a random script onto a website I was responsible for, which claims to magically preload things and make things faster is not my idea of simple. Easy, perhaps. Risky, yes. Simple, no.
- kissgyorgy 6y ago
  This can speed up your legacy site at most 200-300 ms. If your page load time is above 500ms, this won't do much...

stephenhuey 6y ago

2 decades ago there was a product whose name escapes me. It was a tool to speed up web browsing, but instead of preloading which link it thought you were about to click next, it simply started preloading all the hyperlinks on the webpage.

blhack 6y ago
Some of us just used to include the next images as 1px squares to speed up loading of images that the user might click on next. Back then the images really were the only big bandwidth hog.
- rimliu 6y ago
  Back then one of the common mistakes used to be taking a huge image and "resize" it with "width" and "height" attributes on the img tag. It still is, but it used to too.
josefrichter 6y ago
I think this was available as browser extension. Maybe still is.
judge2020 6y ago
Sounds like AMP :) RES for Reddit also has an option that preloads every post that shows on the page for instant loading at the cost of bandwidth (I had an increase of ~100gb for one month)
tribby 6y ago
I wonder if you're thinking of netzero - IIRC they did this after they became a paid service, to market their 56k offering against early DSL
laumars 6y ago
And didn’t that get people into trouble in corporate networks because some of the links it followed were links the user would never have clicked on. I vaguely recall that problem arising in the late 90s / early 00s.

ritonlajoie 6y ago

A little bit off topic : the axios website on mobile 4G loads quite instantly on my phone. Even better than most FANG websites. I'm not sure it's only the CDN doing this. Any clue?

dieulot 6y ago
For as-fast-as-possible first time load, use TLS 1.3 + inline CSS + server close to user (with a CDN for global audiences) + not much JS (absolutely no 30kB framework). For as-fast-as-possible subsequent page loads, use preloading (à la instant.page) + light SPA. My previous library, InstantClick, did just that but it’s alas mostly just a proof of concept (lacks good docs), I intend to “reboot“ it this year and announce it on HN. FANG websites aren’t a very good site speed standard. :)
adventured 6y ago
It's modestly fast for how bloated it is, I'll grant them that. From Pingdom's Washington DC test location, on this Axios page: https://www.axios.com/tropical-storm-sally-forms-off-florida-coast-ab1e97df-99bf-4e21-93a8-b3f0bccda493.html https://www.axios.com/tropical-storm-sally-forms-off-florida... It rings in at 414ms, 1.9mb uncompressed (~1mb compressed), with a rather obnoxious 90 requests. They're loading 961kb of script and 197kb of font content. A whole 41kb of actual HTML content in that obese vat of bytes. On a small Quora page with no major images, they come in at 2mb of junk, 1500ms to load, with 79 requests. A typical small Wikipedia page with one image will come in at 400kb-500kb and load in 400-500ms, with 26 requests. GTMetrix lists the average load page size for their performance tests, compressed (!), at 3mb (with 89 requests). Framework bloat is like living on a sugar diet.
- minxomat 6y ago
  Thanks for using Pingdom btw. Always happy to see our products used in the wild
ffpip 6y ago
Axios loads off Google's servers. They serve only AMP pages. They don't have any non-amp servers If you log the requests, you can see that they load everything from ampproject.org

rado 6y ago

Beware, this broke my lightbox component, because the images had href.

aphroz 6y ago

I managed to have a 603ms click on mobile, who can beat me ?

ffpip 6y ago
0 :) https://i.imgur.com/OhmLu5I.jpg https://i.imgur.com/OhmLu5I.jpg
- aphroz 6y ago
  The longer the better, the more you will cheat latency ;)
codetrotter 6y ago
Longest click I was able to make on mobile was 510ms. And my initial click, which was not attempting to use a long time, was about 69ms.
- aphroz 6y ago
  The challenge is to release your finger just before the contextual menu pop out.
  - codetrotter 6y ago
    Yup

helsinkiandrew 6y ago

How does this relate to the preload spec <link rel=“preload”> is it only preloading when the link is visible/hovered over? https://w3c.github.io/preload/ https://w3c.github.io/preload/ https://caniuse.com/link-rel-preload https://caniuse.com/link-rel-preload

divbzero 6y ago
Looks like instant.page at its core uses <link rel=prefetch>: [1] const prefetcher = document.createElement('link') prefetcher.rel = 'prefetch' prefetcher.href = url document.head.appendChild(prefetcher) [1]: https://github.com/instantpage/instant.page/blob/v5.1.0/instantpage.js#L230-L233 https://github.com/instantpage/instant.page/blob/v5.1.0/inst...

jwr 6y ago

I think rather than waste bandwidth and fight for those last 80ms, we should fix sites that take multiple seconds to load. Especially after the first load — subsequent pages should load instantly. In general, it's 2020, and if every click on your site takes 5 seconds, something is very wrong.

hombre_fatal 6y ago
It makes a big difference and doesn't only help websites that take seconds to load. Just look at its hover->click speed demo on the landing page. I'm getting 500ms+ if I click it casually like I do most links. All of that time could be spent loading the next page. https://dev.to/ https://dev.to/ (blog platform) does prefetching to great effect. The onus is on you to decide if this would create a bunch of false positive prefetches for your desktop users, like if your website was a bunch of densely packed links. You could also scope this to prefetch only a subset of links. But your users deserve more deliberation over their UX than a kneejerk yay/nay.
Thev00d00 6y ago
/me scowls at the Google Cloud console.
onion2k 6y ago
subsequent pages should load instantly Every page should load fast, obviously, but instantly means the data has to be prefetched and that's potentially a lot of data to download that the user might never actually need. That's a waste of everyone's bandwidth, especially on mobile. Pages that a user will view (eg first page behind a login), or that they're very likely to view (eg top result in a search), should be prefetched/prerendered but whether you should prefetch more than that requires thought and measurement.
- ComodoHacker 6y ago
  A great stimulus for "thought and measurement" would be user feedback. If users could see who wastes their data plan as easily as they can see who eats their battery, this would change the picture. Browser vendors should implement per-site traffic breakdown.

compumike 6y ago

We use this, with <body data-instant-intensity="10"> on https://ultimateelectronicsbook.com/ https://ultimateelectronicsbook.com/ It's already a static Jekyll-compiled site served from a CDN, but combined with other techniques, instant.page makes the site quite snappy. (We had the EasyList blocking problem described below, so we started bundling it into our own post-load JS bundle.) Honestly, unrelated, but the biggest performance improvement for us has been to do server-side rendering of the LaTeX equations, rather than using MathJax client-side.

polytely 6y ago

Fasted hover to click I got was 93ms, it's really hard to get under a 100ms, very curious to see who the fastest clicker on hn is.

grahoho 6y ago
I got 73 ms.
grenoire 6y ago
Got 0 ms by chance through dragging my mouse from right to left across the button and timing it in. I feel like a tool-assisted speedrun robot now.
thegabriele 6y ago
You don't have to think about it ("click when on the box"), casually doing it took me to 43ms
FractalParadigm 6y ago
The mobile site features a similar button, which measures the time between screentouch and release - tapping it casually like I would any other link netted ~120 ms, fastest I could physically tap was 20ms! That demonstration alone was enough to pique my interest and give this a try.
- perryizgr8 6y ago
  I'm regularly getting 7-15ms. Not tapping particularly fast. Could it have something to do with the touch refresh rate? I'm on Chrome/GalaxyS10.
  - FractalParadigm 6y ago
    Interesting theory. To throw out some 'anecdata' (maybe we can turn this into a sort of study?) - my three-device test (iPhone 6S and Pixel 2 XL at 60Hz, 12.9" iPad Pro at 120Hz) would seem to indicate that the refresh speed does not affect the touch refresh rate, however, this could be the result of the large performance differences between devices used, as the average and maximum times trend down with the newer/faster devices in testing. Min/avg/max of 10 taps, as fast as possible; 17/26.6/36 -- iPhone 6S 16/23.7/34 -- Pixel 2 XL 17/21.7/33 -- 12.9" iPad Pro I would probably conclude overall that my hands are just slower than yours!

Gormisdomai 6y ago

Presumably this won't work on mobile because there's no hover to trigger the pre-loading. I wonder if there's something else that could be used there.

INdek 6y ago
They mention mobile in the page, they use the onmousedown to preload, which (they claim) gives in average a 90ms improvement, instead of waiting for the click evento.

beaker52 6y ago

Pre-loading is a great idea when you're dealing with optimised, cached content. Pre-loading with some third-party script as a magic fix for free milliseconds is something people should think twice about.

deleted 6y ago

[deleted]

The_rationalist 6y ago

How is this different than https://github.com/GoogleChromeLabs/quicklink https://github.com/GoogleChromeLabs/quicklink?

lewiscollard 6y ago
Quicklink prefetches links as they arrive in the viewport. Instant.page prefetches them when you hover over them.

chrismorgan 6y ago

I think this library has gotten steadily worse over time. After 1.2.2, each new release just introduces more configurability that >99.99% of sites won’t want, more complications, more bugs and more misfeatures. Most notably version 5 introduced triggering load on mouse down, which I call catastrophically wrong, 100% dealbreaker with prejudice. 5.1.0 made it opt-in, but it’s still functionality that just shouldn’t exist. I golfed 1.2.2 down a long way, removing other configurability and functionality that I didn’t want; see https://news.ycombinator.com/item?id=23204741 https://news.ycombinator.com/item?id=23204741, part of the discussion a few months ago at https://news.ycombinator.com/item?id=23203658 https://news.ycombinator.com/item?id=23203658 (where there was much wringing of hands about the whole load-on-mousedown mess). 5.1.0 is 2,842 bytes, 1,169 gzipped; my version got to 981 bytes, 532 gzipped. At that point it’s almost certainly cheaper to inline it than to have it as an external script (though if your CSP has script-src excluding unsafe-inline, you’ll need to give it a nonce or sha hash if you want to do it inline).

pimterry 6y ago
> version 5 introduced triggering load on mouse down, which I call catastrophically wrong, 100% dealbreaker with prejudice. Could you provide more context? Why is that catastrophically wrong?
- chrismorgan 6y ago
  See some of the discussion on https://news.ycombinator.com/item?id=23203658 https://news.ycombinator.com/item?id=23203658. It breaks how links work normally.
  - celsoazevedo 6y ago
    https://instant.page/changelog https://instant.page/changelog I agree it was a bad decision to do that by default, but it's opt-in since 5.1: "Make triggering clicks on mousedown opt-in".
    - chrismorgan 6y ago

kabacha 6y ago

Is shaving off 1% really justifies such a hack? The web is already so extremely implicit that even seasoned web-developers are lost in it.

Tepix 6y ago

Self-hosting Hosting the script yourself is also possible. Download the latest version at https://instant.page/5.1.0 https://instant.page/5.1.0 then add a module script tag just before </body>: <script src="instantpage-5.1.0.js" type="module" defer></script> You can also install it via npm: npm i instant.page

noname120 6y ago

With Vimium[1] I consistently get 0 ms from hover to click. :) [1] https://github.com/philc/vimium https://github.com/philc/vimium

cblconfederate 6y ago

Even if this is a bandaid solution attacking the wrong problem, it's great to see people caring for speed for a change. But isn't it dangerous? How does it know you re not preloading the "please delete everything" link? It would be nice to have a standard html tag preloading="yes" so that one day browsers can have it as standard feature. I'd much rather have this than AMP

whylo 6y ago
> But isn't it dangerous? How does it know you re not preloading the "please delete everything" link? In a perfect world no-one would be using links for actions which modify state - they should always be a POST behind a button, not a GET behind a link. But in the real world this is probably a legitimate concern. They do have methods to mark links as non-preloadable (https://instant.page/blacklist https://instant.page/blacklist), but anyone using it should definitely do a thorough test, not just copy and paste and hope for the best
lewiscollard 6y ago
> But isn't it dangerous? How does it know you re not preloading the "please delete everything" link? As a sibling comment points out, if it's possible for someone to delete everything via a link, your users have already lost. Someone could, e.g., trick your users into loading an IMG tag or an IFRAME pointing to that page, or give them a shortened URL that redirects to your "delete everything" page. GET requests should never have side effects.
- cblconfederate 6y ago
  clicking an activation link in an email ?

jooize 6y ago

Would it save time by loading pages without making a normal new page request? I mean using AJAX/jQuery/… and updating URL with window.history.pushState.

donbrae 6y ago

I use instant.page and it doesn't appear to work in Safari (at least in desktop version 13.1.2): I can't see any transfers in the Network tab on hover.

tiffanyh 6y ago

This is the successor to http://instantclick.io http://instantclick.io for those who recall that library. Some things to note: - at it's core, this is using PREFETCH - Safari at the moment doesn't support link prefetching, so this library doesn't work for Safari - yes, it works on mobile and arguably people see even better results on mobile due to inconsistent network/latency of mobile networks. An old HN discussion on the predecessor library: https://news.ycombinator.com/item?id=7365204 https://news.ycombinator.com/item?id=7365204

masswerk 6y ago

I'm somewhat concerned about this kind of preloading. Given that network traffic is a huge, if not the major part of the total energy consumption of IT (I've seen estimates of about 40% of the total), this is adding a significant extra (according to the webpage only 50% of the triggered preloads are actually followed by a page view, which equals to an increase of 100% in initial traffic) for a gain of a few milliseconds. Mind that reducing (initial) page loads by a fraction will do the same for you and even more.