CSR/SSR

Modern front-end frameworks can deliver a page in two ways. With server-side rendering (or static generation) the HTML sent by the server already contains the content, and JavaScript only adds interactivity. With client-side rendering the server sends an almost empty shell and the browser builds the page from scripts and API calls. The second approach costs time on every visit and hides the content from anything that does not run JavaScript. This auditor measures how much of the page depends on JavaScript by rendering it both ways and comparing the results.

​

How it works

1. Render with JavaScript — loads the audited URL as 37AuditsBot in a headless Chromium with JavaScript enabled, waits for the network to go idle plus a short grace period, and keeps the rendered HTML. A blocked navigation (HTTP 403, HTTP 429 or a Cloudflare challenge) ends the audit with 590; no response, or an HTTP status of 400 or more, ends it with 500. A browser error, after one relaunch on a crash, ends it with 501.
2. Render without JavaScript — loads the same URL in a second context with JavaScript disabled and keeps that HTML too.
3. Compare — computes the size difference ratio |sizeWithJs − sizeWithoutJs| / max(sizeWithJs, sizeWithoutJs) (two empty documents count as no difference).
4. Rules — a ratio above 20% warns (300): the content is built in the browser. A ratio of 20% or less is SUCCESS (200): the content is delivered by the server. The message of either outcome gives both sizes and the ratio.

​

What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 500–599 error.

​

Output documentation

Every SUCCESS and WARNING check carries the measured values in data: sizeWithJs, sizeWithoutJs, sizeDifference (characters), ratio, threshold (0.2) and isCsr.

​

Risks and considerations

​

Why rendering strategy matters

• Search engines do render JavaScript, but later and with a smaller budget than plain HTML; client-rendered pages are often indexed days after server-rendered ones, or with missing content when a script fails.
• Many AI crawlers, link unfurlers (chat apps, social networks) and accessibility tools read the raw HTML only. A client-rendered page gives them an empty shell.
• Visitors on slow networks or devices wait for every script before the first content appears, which raises Largest Contentful Paint and bounce rates.

​

A size heuristic, not a framework detector

• The auditor compares the size of the two rendered documents, nothing else. A page whose scripts add a cookie banner, a chat widget or large tracking markup can cross the 20% threshold while its main content is server-rendered; a client-rendered page that replaces a large placeholder with content of a similar size can stay under it.
• The threshold is a fixed constant (20%) and is not configurable.
• Both renders wait for the network to go idle plus 1.5 seconds; content loaded after that, on scroll or on interaction, is not counted.

​

Changes from the previous version of this auditor

• A page whose JavaScript-enabled navigation answers with an HTTP status of 400 or more is no longer rendered and compared as if it were the site: the audit ends with ERROR 500.
• A browser failure that survives the one relaunch is reported as ERROR 501 with that code, instead of an error check without a code.
• The verdict thresholds are unchanged: a size difference above 20% still warns, 20% or less still succeeds.

​

What this auditor does not check

• Whether the server-rendered HTML is also correct, complete or hydrated without errors.
• Pages beyond the audited URL; a site can mix strategies per route.
• Which framework or rendering mode (SSR, SSG, ISR, streaming) the site uses.