As the sibling comment notes, this would unfortunately be too aggressive. In addition to the problems with non-idempotent GETs, doing full prerendering means do

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