Speed up your website in 1 minute with Instant.page

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

Comments

[Nick Taylor]

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

#meta #javascript #preact #webpack

[Fabien Lasserre ☕️]

Well as it turns out, InstantClick was made by Alexandre Dieulot, the creator of Instant.page! 😄

[Nick Taylor]

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.

[Sivasubramanyam A]

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.

[Sivasubramanyam A]

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.

[Fabien Lasserre ☕️]

I asked Alexandre directly and here is his reply:

"instant.page uses only <link rel=prefetch>, InstantClick uses Ajax and pushState which makes a website into an SPA (and therefor needs for scripts to be adapted).

InstantClick gives a better experience, but lacks documentation. It's more of a proof of concept.

For the moment I recommend Instant.page more"

[Nick Taylor]

There is also guess. So many great projects.

guess-js / guess

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:

⚫ Data-driven bundling

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 packages directory contains three packages:

• ga - a module for fetching structured data from the Google Analytics API to learn about user navigation patterns.
• parser - a module providing JavaScript framework parsing. This powers the route-parsing capabilities implemented in the Guess webpack plugin.
• webpack - a webpack plugin for setting up predictive fetching in your application. It consumes the ga and parser modules and offers a large number of options for configuring how predictive fetching should work in your application.

For non-Webpack users:

⚫ Data-driven loading

Our predictive-fetching for sites workflow provides a set of steps you can…

View on GitHub

[Shaiju T]

Thanks :) , Here is another plugin, the author in this and this post compares QuickLink and InstantPage and says that QuickLink doesn't have options like

• Limit preloads per second .
• Stops preloading on slow response.
• Stops preloading if server crashes .

@pavelloz What both of you think which is better ?

[Paweł Kowalski]

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.

[Shaiju T]

Thanks, when you said minimize ssl handshake is it using preconnect link tag ? Also I think instead of using the plugins to prefetch the whole next page. We can use prefetch to load js and image file of next page ? Is this good scenario ? are there any other scenario to use them wisely ?

[Paweł Kowalski]

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

[Paweł Kowalski]

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.

[Paweł Kowalski]

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

[Paweł Kowalski]

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:

• github.com/turbolinks/turbolinks
• github.com/MoOx/pjax
• guess-js.github.io/ < this one is interesting, but has a dependency