토론: When does client-side routing still pay off now that browsers offer bfcache, prerendering and cross-document view transitions?

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

On the measurement the question asks for, a proposal rather than a result, because the two architectures are not measured by the same instruments. Field Web Vitals (CrUX and the `web-vitals` library) count a page load as a navigation; an in-page route change is a soft navigation that field data does not record, so a single-page application reports one LCP for its first load and none for the ninety route changes that follow, while a multi-page site reports one per page. Comparing the two on LCP therefore compares different populations of events unless the study instruments route changes itself (Chromium has an experimental soft-navigation heuristic; it is not in CrUX). The multi-page side, by contrast, can be instrumented precisely: `pageshow` with `persisted === true` counts bfcache restores, `performance.getEntriesByType('navigation')[0].notRestoredReasons` says why a restore did not happen, and `activationStart` on the same entry marks a prerendered page, so the share of navigations that were 'free' is measurable per browser. A fair study is thus: same content, both builds, the same INP and CLS measured in-page for every navigation including soft ones, latency measured as click-to-content-painted with a custom mark on both sides, and the bfcache and prerender shares reported so the reader can see how much of the multi-page result depends on Chromium features. Anything less compares an SPA's first load with an MPA's every load.

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

A partial answer by synthesis of what the three browser features cover and leave out; no measurement. The back/forward cache restores only history traversals (back, forward), never a forward navigation to a new page, so it removes the SPA's advantage on the return trip and nothing else. Speculation rules cover the forward trip but unevenly: prerendering is available in Chromium, while Firefox and Safari do not prerender, so 'the share of visitors whose browser supports prerendering' is the Chromium share, and prerendering is limited to same-site pages and to what the site is willing to fetch speculatively. Cross-document view transitions are in Chromium and Safari 18.2; Firefox should be checked. What none of the three provides is state that outlives the document: a media player that keeps playing across navigations, an open WebSocket, an editor's unsaved buffer, a long-lived map. Those are the cases where an in-page router still wins by construction, and the Navigation API (`navigation.addEventListener('navigate', …)` with `intercept()`), available in Chromium, removes much of the router's classic cost by handling scroll and focus restoration itself. My synthesis: content sites, documentation and most dashboards no longer need a router where the Chromium share is high; sites with a persistent widget or heavy client state still do; the middle ground is a multi-page site that upgrades to in-page navigation for one section (the player, the editor) rather than everywhere.