tunetheweb

For prefetch, it follows Chrome’s 5 minute timeout, so your next day issue shouldn’t be a concern.

For prerender, there is no timeout as long as the page is in the foreground. And sleeping the computer does not count as backgrounding. I’ve raised this issue to see if we should improve this: https://issues.chromium.org/issues/335924597

For now, if you have those specific concerns, prefetch may be the better option for you. It won’t quite be an instant navigation, but should still provide a good headstart anyway.

That’s not strictly true Weston.

Speculation Rules basically uses the memory cache, so it can also be used for resources that aren’t cacheable in the HTTP Cache. As I often say it’s like right clicking a link and opening it in a new tab but not switching until later. In that case you wouldn’t expect the other tab the user opened to be closed when state changes and that doesn’t happen for Speculation Rules pages either.

However, it will only live for the duration the user is on the page (unless it’s saved in the HTTP Cache too as usual) so there is no long term cache.

To cancel a speculation you need to move to another page, or remove the speculation JSON from the page (which needs to be done through JavaScript and is not something the plugin can do since it doesn’t know what triggers that removal need).

However, it seems the OP has a longer term issue here so seems like it’s completely separate to speculation rules maybe?

Oops that should say ” lazy loaded images are now incredibly common“!

Hi Dan,

Prerendering can affect analytics and personalization.

For client-side JavaScript, is recommended to delay these until the page clicks and some solutions (like Google Analytics) already do this automatically for prerender. See here: https://developer.chrome.com/docs/web-platform/prerender-pages#impact-on-analytics. Additionally cross-origin iframes are not loaded until activation which can further avoid issues here.

Speculating on hover (moderate) increases the chance the page will be loaded, over preloading without this signal, and thus reduces the risk here. Alternatively, the plugin offers to only speculate on mouse/pointer down (conservative) which further reduces the risk here and is an option for sites which are concerned about this, at the cost of having less of a lead time and so less of a performance gain.

A prerendered page is linked to the page that prerenders it, so personalisation may already be known by this point and changes (e.g. browsing other products, or logging in/out) may require a new page load, and hence a new prerender anyway, which will take these into account. But it definitely is something to be aware of and test!

Oh that sounds odd. Is the content returned set server-side and differs for mobile and desktop? Could you perhaps share the URL? Or a minimal reproducible example?

Hi Chris,

If the link is to the exact same page, then no it won’t prerender the page again but is smart enough to recognise this as the same.

If it has different query params, then it will treat those as different pages as it can’t know whether the page is the same or different. If those query params aren’t important to the rendering of the page (e.g. UTM pages), then we are working on ways for sites owners to let the browser know those query params don’t matter and can be treated as the same page (this already is available for prefetch but not for prerender).

Speculation Rules will also keep up to two prerendered links in memory at a time, to reduce the memory impact of this feature.

So, if you hover over link1, then link2, then link3, then link1 again it will prerender links 1, then 1+2, then 2+3 (evicting link 1), then re-prerender link 3 (evicting link 2) so you have links 2+3 prerendered.

But, even with this, there’s a few things to keep in mind:

• The user must hover over a link for 200ms so just randomly scanning past a link will not initiate the prerender.
• If you have concerns about this, then you can change the setting from the default “moderate” eagerness setting to “conservative” so prerendering only triggers on mouse/pointer down. This will trigger a lot less, but at the cost of having a smaller lead time (so not as much performance gain as the page may not be fully prerendered by the time the user finishes the “click” and navigates to the page). See this recent tweet.
• If still concerned then can also choose prefetch over prerender. However, with WordPress sites without HTTP Caching (that I’ll cover next) this is often nearly as costly as a full prerender.
• Speculation Rules will make use of the HTTP cache. So if you prerender link1 then any cacheable resources (with cache-control headers) will be stored in the HTTP cache. Then if you prerender link1 a second time, the resources can be read from the cache and the cost to prerender the second time is much reduced (basically memory and CPU costs but no—or at least much reduced—network and server costs). A word of warning here is that many sites (including many WordPress sites) set the HTML to be uncacheable so you may have to refetch the document in this case. 🙁 It’s recommended to set even a small cache time for performance anyway and that would avoid this.

Hope that answers all your questions here but let us know if you have any more questions.

We’ve thought long and hard about trying to reduce the cost of speculation as much as possible and make this feature as easy as possible for most sites to use without having to be too concerned about that.