Back/Forward Cache

## The two things that can happen when a user presses Back A history navigation has two very different outcomes. In the good case the browser restores the previous page from its back/forward cache: the document is brought back in the state it was in, including scroll offset, form values, and the values held in the page's JavaScript. Nothing is requested from the network, no HTML is parsed, no scripts are executed, and there is no render of an empty skeleton first. To the user it looks less like a navigation than like an undo. In the bad case the back navigation is an ordinary page load. The browser fetches the document (possibly from the HTTP cache, possibly from the network), parses it, runs the scripts, the application boots, data is fetched again, and only then does the list appear — usually scrolled back to the top. The user has to find their place again. That last part matters more than the milliseconds: losing scroll position in a long results list is a task cost, not just a latency cost. ## This is not the HTTP cache A common confusion is to assume a well-cached site gets instant back navigation for free. The HTTP cache saves you from *downloading bytes*; it does not save you from *rebuilding the page*. Even with every asset served from disk, a repeat page load still parses HTML, evaluates JavaScript, boots the app, re-runs data fetching, and re-lays-out the page. On a mid-range phone that work is often the dominant cost. The back/forward cache is the only mechanism that skips all of it, because the page was never torn down in the first place. ## Sizing the opportunity Back and forward navigations are not a rounding error. Browser vendors have reported them as roughly a tenth of desktop navigations and closer to a fifth on mobile — the exact figure varies by site, and yours is measurable from your own analytics. Some journeys are dominated by it: search results → detail → back → detail → back is the core loop of e-commerce, job boards, real-estate listings, and news indexes. On those templates a restored back navigation may be the single most common repeat interaction in the funnel, so making it instant moves a large slice of sessions. ## Why it is considered cheap leverage Most performance work trades something away. Shrinking a bundle means deleting features or splitting code and re-testing; adding a CDN costs money and adds a cache-invalidation problem; deferring scripts risks breaking behaviour. Back/forward cache eligibility is different in kind: you are not making the page smaller or faster, you are removing whatever is telling the browser "this page cannot be safely revived". The typical fix is small — a header, a listener, a third-party tag — and its payoff applies to every eligible back navigation on every page it covers, with no per-request cost. That ratio of effort to breadth is why it sits near the top of a performance backlog once it is measured. ## Where it does not help It does nothing for first visits, for forward navigation to a page the user has not seen, for reloads, or for pages opened in a fresh tab. It also does nothing for a user who never presses Back. And it has a genuine product consequence: the restored page carries the data it had when the user left it, so anything time-sensitive — a cart total, a price, a live count, an auth state that may have changed in another tab — needs a deliberate refresh path when the page comes back. That is real work, not a footnote, and it is the reason a team occasionally decides some page should not be restored. ## What to do with it in practice Treat it as a measured lever, not a checkbox. Find out what share of your navigations are back navigations and on which templates; find out what share of those are currently being restored; then decide whether closing that gap is worth more than the next item on the list. Because eligibility is binary per page load, the payoff curve is unusually steep: a single blocker on a shared layout can hold an entire site at a near-zero restore rate, and removing it can flip the whole site at once. That is also the risk — the same single change in the other direction silently loses the gain, so once you have it, it needs a guard.