3 ms·

> Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activat

> Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activated when the user clicks a link. This gives truly instant-feeling navigations. I recall Opera doing this sort of thing around two decades ago. It had a setting to aggressively cash all links, and navigating between those was instantaneously. Is this what Chrome does?

MrJohz 4y ago
I remember reading once (but now I can't find the details, this may be apocryphal): a few browsers did try this for a while, but it turned out be a disaster for certain sites. If, for example, you have a page loaded with a list of items, each of which has a delete link next to it (think PHPMyAdmin): what happens if the browser automatically sends a get request to every link it sees in order to prefetch the content? The server will just see this as a user clicking a link to the delete page and automatically delete the item. The solution to this is obviously that servers should obey the rules of HTTP methods better: GET is idempotent and doesn't change state, so it should be impossible to delete data just by clicking a link. Instead, you should at least need to submit a form via a POST request in some way. In practice, though, browsers need to deal with badly designed servers, which is why almost all of this prerendering, precaching, etc stuff requires an explicit opt-in from the website.
domenicd 4y ago
As the sibling comment notes, this would unfortunately be too aggressive. In addition to the problems with non-idempotent GETs, doing full prerendering means downloading all subresources and running all JavaScript, so things like analytics or tracking pixels or "update the user's most recently visited document list" in a document-viewer app might get triggered as well. That is, in reality while a HTTP GET might be idempotent on a well-designed page, very few people design their page so that a HTTP GET + running all the page's on-load JavaScript is idempotent. To solve this, for the modern implementation you can read about in the article, (1) prerenders are limited to same-site pages, to avoid cross-site identity joining; (2) prerendering is opt-in on the referrer side (and, for cross-origin same-site cases, on the destination side as well). This unfortunately means only sites that are willing to put in the extra work, get the speed benefit. In particular, right now the effort of auditing all your third party libraries is probably the biggest cost. We're looking into what kind of providers we can work with to reduce this, by evangelizing them into becoming prerendering-aware (e.g., not logging analytics while being prerendered).

MrJohz 4y ago

I remember reading once (but now I can't find the details, this may be apocryphal): a few browsers did try this for a while, but it turned out be a disaster for certain sites. If, for example, you have a page loaded with a list of items, each of which has a delete link next to it (think PHPMyAdmin): what happens if the browser automatically sends a get request to every link it sees in order to prefetch the content? The server will just see this as a user clicking a link to the delete page and automatically delete the item. The solution to this is obviously that servers should obey the rules of HTTP methods better: GET is idempotent and doesn't change state, so it should be impossible to delete data just by clicking a link. Instead, you should at least need to submit a form via a POST request in some way. In practice, though, browsers need to deal with badly designed servers, which is why almost all of this prerendering, precaching, etc stuff requires an explicit opt-in from the website.

domenicd 4y ago

As the sibling comment notes, this would unfortunately be too aggressive. In addition to the problems with non-idempotent GETs, doing full prerendering means downloading all subresources and running all JavaScript, so things like analytics or tracking pixels or "update the user's most recently visited document list" in a document-viewer app might get triggered as well. That is, in reality while a HTTP GET might be idempotent on a well-designed page, very few people design their page so that a HTTP GET + running all the page's on-load JavaScript is idempotent. To solve this, for the modern implementation you can read about in the article, (1) prerenders are limited to same-site pages, to avoid cross-site identity joining; (2) prerendering is opt-in on the referrer side (and, for cross-origin same-site cases, on the destination side as well). This unfortunately means only sites that are willing to put in the extra work, get the speed benefit. In particular, right now the effort of auditing all your third party libraries is probably the biggest cost. We're looking into what kind of providers we can work with to reduce this, by evangelizing them into becoming prerendering-aware (e.g., not logging analytics while being prerendered).