search

instantpage / instant.page

Make your site’s pages instant in 1 minute and improve your conversion rate by 1%
https://instant.page
MIT License
6.04k stars 205 forks source link

What’s wrong about Instant.page? #50

Closed LukaszJaro closed 4 years ago

LukaszJaro commented 4 years ago

How accurate is this?:

Usually, a user takes around 300ms from hover to click. So if the server didn’t respond within 300ms, then most likely you won’t notice any difference. Achieving <300ms TTFB is pretty hard. Most of the hosting providers have this around 400ms and even 1s to halfway around the globe.

From: https://wpspeedmatters.com/quicklink-vs-instant-page-vs-flying-pages/

lrehmann commented 4 years ago

This issue is dampened by server-level and CDN caching.

Perhaps Instant.page could be adopt similar preload feature by adding a force-preload tag to links, preloading all links in viewport, or (for desktop) preloading links when the mouse is heading towards the link – similar to how Amazon improves their menu UI.

https://www.technologyreview.com/s/512376/the-ingenious-engineering-trick-that-makes-amazon-menus-usable/

dieulot commented 4 years ago

It’s not accurate. If the server takes more than 300ms to respond, then you’ll still have gained 300ms and noticed a speed boost. And it’s rare that TTFB is over 300ms in my experience (living in France).

For those that want a more extreme form of preloading, I’m planning to introduce an option to preload everything that is in the viewport (similar to quicklink and Flying pages).

I don’t have a plan to make instant.page preload when the user is heading toward a link, as I said in the first paragraph the simple act of preloading on hover is enough, and preloading when the user is heading toward the link would make a lot of additional requests (even just preloading on hover without a delay makes a lot of request that is unacceptable for most sites).