Behind this clickbait title lies a really nifty little tool. I stumbled upon this while browsing Hacker News a while back. Actually it's been active on this website since february now but I never took to time talk about it. Instant.page is a tiny Javascript library which is using just-in-time preloading – it preloads an anchor right before a user clicks on a hyperlink.
The technique used if fairly simple: Instant.page calculates the time a user spends hovering a link (which is an obvious behavior when you want to click on something) and will start preloadind said link if that time exceeds 65ms. Since the average human perceives actions taking less than 100ms as instantaneous, Instant.page tricks the brain, hence allowing your users to get a faster, better experience.
The installation is fairly simple, just insert the <script> tag containing the link to the script right before the closing </body> of your website (which is where all your scripts should reside anyways), and you're all set! Instant.page will glue itself automatically to each link on the page. The library is small, a mere 1kB. It's free and open source (MIT).
Instant.page allows you to control what content should be preloaded or not. You might want to prevent it from preloading some anchors, like logout links for instance. To do that, simply add a data-no-instant attribute to said links and Instant.page will ignore them. You can even specify that you want to allow preloading for external links.
Simple, light and easy. If you want to try it yourself, check out Instant.page here: https://instant.page
Top comments (14)
The DEV site uses something similar to this, InstantClick. It actually uses the same attribute,
data-no-instant, to ignore links just like Instant.page. I wrote about it a while back. I wonder if Instant.page was inspired by InstantClick.dev.to’s Frontend: a brain dump in one act
Nick Taylor (he/him) ・ Apr 23 '19 ・ 8 min read
Well as it turns out, InstantClick was made by Alexandre Dieulot, the creator of Instant.page! 😄
I guess it is his improvement to InstantClick? Could be worth investigating upgrading to Instant.page for DEV. It might even be an interesting Hacktoberfest PR.
IIRC, InstantClick kind of makes your website behave like an SPA. It uses pjax and replaces only the contents of the body tag and the document title. Instant.page on the other hand, simple prefetches contents so that the browser cache can kick in when the user actually clicks the link.
There also seems to be a Google project called quicklink that prefetches links in the viewport. I guess this is similar to what Gatsby does.
I asked Alexandre directly and here is his reply:
There is also guess. So many great projects.
Libraries & tools for enabling Machine Learning driven user-experiences on the web
Guess.js (alpha)
Libraries and tools for enabling data-driven user-experiences on the web.
Quickstart
For Webpack users:
Install and configure GuessPlugin - the Guess.js webpack plugin which automates as much of the setup process for you as possible.
Should you wish to try out the modules we offer individually, the
packagesdirectory contains three packages:gaandparsermodules and offers a large number of options for configuring how predictive fetching should work in your application.For non-Webpack users:
Our predictive-fetching for sites workflow provides a set of steps you can…
Thanks :) , Here is another plugin, the author in this and this post compares
QuickLinkandInstantPageand says thatQuickLinkdoesn't have options like@pavelloz What both of you think which is better ?
Ouh, and when it comes to using 3rd party wordpress plugin (i dont use wordpress) i would think twice before i would install unknown plugin from untrusted source on my server, just to get something that is available as (usually) 1-2KB of open source code on github.
Thats a dangerous game, and as an WP administrator i wouldnt do it, thats for sure.
Thanks, when you said minimize ssl handshake is it using
preconnectlink tag ? Also I think instead of using the plugins toprefetchthe whole next page. We can useprefetchto load js and image file of next page ? Is this good scenario ? are there any other scenario to use them wisely ?Well, you can minimize handshakes by self-hosting everything you can, on your domain. It also removes 3rd party dependencies being your dependencies, as a positive side-effect
I use preconnect to project's cdn domain, and those 3rd parties that i didnt manage to self host.
I think better approach to js performance is dynamic code splitting (ie. in webpack -
import()- docs here). It not only makes your initial bundle smaller, but also defers downloads of dependencies/plugins/vendor code after initial bundle has been executed. And because webpack is an amazing tool, you can also set some prefetching/preloading to those dynamically created chunks as well - webpack.js.org/guides/code-splitti... .Honestly, long term i think none of them all good, because they are trying to mask the real issue which is slow/big loading pages.
This shouldnt happen on desktop at all, because desktops are usually low-latency devices (wifi).
On mobile on the other hand, in theory it should be a good idea, but when you think about cost per MB, then your users might not want you to make those decisions for them. They probably are on a budget and websites are big enough already. I know there are ways to detect slow connections within native web api, but arent those connections really the main beneficient of those predictive preloading mechanisms?
I have free 4G everywhere and i know my phones bottleneck is the amount of JS to parse + execute, but if i had 3G that i would have to pay crazy amounts of money (like they do in the US) i would be really mad if someone made me download additional 1MB that i will never see, because i got tired of the webpage at the "Hey this is our app!, download it now!" / "Remember about cookieZZ!!!" / "Pay us on patreon" phase, and left before i ever used those unnenessairly download MBs.
So i would focus on making pages smaller, less js, compress every little graphic (or change the format of it) less css, less 3rd party slowdowns, load on demand whats not needed, speed up DB queries, minimize SSL handshakes (especially for critical path).
I would spend my time here as performance oriented web developer. I once did a fast website, and adding things like instant.page (or any other of its variance, including quicklinks, guess.js [this one actually required addition of GA, so its a no-go for some]) or turbolinks actually hurt performance.
By accident, found this on HN now, comments are kind of saying the same thing i wrote above, which is sentiment, dont send me trash in the first place.
news.ycombinator.com/item?id=21905301
I know about instant.page for a long time, but never used it on production because:
1) i usually remember about it when i have 0 ideas how to further optimize the page (meaning, it is very fast already) and using it actually didnt change anything (for the better)
2) when page is slow there is usually a bigger fish to fry and fundamental problem to solve, that instant.page will only mask (i prefer seeing red errors than wonder whats wrong)
But for those who are looking for quick wins thats probably a good direction. I also recommend looking at: