Single-page app or multi-page site.
In one the application navigates, in the other the browser; since cross-document transitions, “you need an app for smooth transitions” is no longer true.
For a decade this comparison had an obvious answer: if you wanted smooth transitions, preserved state and fast page changes, you wrote an application. The technical assumption behind that answer has changed. The browser can now animate between two separate documents, and one line of CSS is enough to ask for it. So the comparison is open again.
What the application takes over
A single-page app takes over a job the browser used to do: navigation. What is taken over is more than swapping content — where does focus go, what is the page title, what is announced to a screen reader, what does the back button do, is scroll position restored? All of that gets written and tested. In return there is a real gain: state stays in memory. A half-filled form, a playing track or an open map survives the navigation.
Where the multi-page side stands today
In a multi-page site every address is its own document and the browser navigates. What is new is that the navigation can also be visually continuous: a cross-document transition animates between the last frame of the old page and the first frame of the new one. The transition is defined in CSS, no JavaScript is required, and in an engine without support the navigation is simply unanimated.
The second difference is measurement: in a multi-page site each navigation is a page load of its own, so field metrics are collected per address. In a single-page app soft navigations fall outside today’s metrics; what you measure is mostly the first load.
A measurement trap: the lab browser is not the real one
When measuring a page that opts into cross-document transitions, be careful: the browser a lab tool starts does not run with the same flags as a visitor’s, and that difference can delay the first frame by seconds. That is exactly what we measured on this site, and the detail has its own post: why Lighthouse says 87 and real Chrome says 98. When deciding, a lab score should not be the only evidence — field data and a real-browser measurement belong on the table too.
How to decide
The question is not “which is modern” but “where does state live”. If a visitor carries state through the session — a document being edited, a long form, an open player — the application side makes that easier. If pages are read independently of each other, the multi-page side gives you less code, a narrower failure surface and the browser’s built-in behaviour for free. This site belongs to the second group, and it sets up its transition without writing an application.
Criterion
- First screen — Single-page app: Nothing shows until the app bundle downloads and runs (unless pre-rendered on the server) · Multi-page site (+ cross-document transitions): HTML from the server is visible in the first frame
- Cost of a navigation — Single-page app: After the first load, data only · Multi-page site (+ cross-document transitions): A document per navigation; caching and prefetching decide the cost
- Navigation animation — Single-page app: In application code, via a router and an animation layer · Multi-page site (+ cross-document transitions): In CSS with `@view-transition`; no application code needed
- State — Single-page app: Kept in memory: forms, players, scroll position · Multi-page site (+ cross-document transitions): The document changes; state that must survive is carried deliberately (URL, storage, server)
- Focus, title, back/forward — Single-page app: Managed by hand: move focus, set the title, announce the change · Multi-page site (+ cross-document transitions): Done by the browser; anchors and back/forward are built in
- Search engines and agents — Single-page app: If content is produced on the client, an extra crawling step is required · Multi-page site (+ cross-document transitions): Every address carries its own HTML
- Failure surface — Single-page app: One JavaScript error can stop navigation entirely · Multi-page site (+ cross-document transitions): An error stays within the page; navigation belongs to the browser
- Measurement — Single-page app: Soft navigations are outside today’s field metrics; what you measure is the first load · Multi-page site (+ cross-document transitions): Every navigation is its own page load; lab tools may measure cross-document transitions differently from a real browser
- Where it fits — Single-page app: Interfaces that carry state through a session: dashboards, editors, maps, games · Multi-page site (+ cross-document transitions): Content surfaces: publications, documentation, portfolios, business sites
FREQUENTLY ASKED QUESTIONS
Are cross-document transitions available in every browser?
No, and nothing breaks where they are not: the rule is opt-in, and in an engine without support the navigation is simply unanimated. Content, addresses and back/forward behave the same.
Isn’t navigation slow on a multi-page site?
It depends on measurement. If the HTML comes from an edge cache or a prefetch, a navigation costs one document download; on this site the worst measured real-user LCP is 476 milliseconds. Slowness comes from a cache miss and a heavy page, not from the architecture.
Is a single-page app bad for search?
Not bad — expensive: if the content is produced on the client, whoever reads it has to take an extra step, and you cannot assume that step is identical in every engine. A server-rendered app closes most of that gap — but at that point the architecture is already a mixture of the two.