Closed LukaszJaro closed 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.
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).
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/