JavaScript SEO & Rendering

Brass-SEO draws on this to explain why JavaScript content is not indexed instantly. Google documents that it processes a page in three phases — crawling, rendering, and indexing — and that rendering is deferred: 'Googlebot queues all pages with a 200 HTTP status code for rendering' and 'the page may stay on this queue for a few seconds, but it can take longer.' Only once resources allow does a headless, evergreen Chromium render the page and execute its JavaScript. The practical consequence is that content which exists only after JavaScript runs depends entirely on that second rendering pass, so a slow or broken script can delay or block indexing.

Examines:

Google's official description of the crawl-render-index pipeline, the rendering queue, and the evergreen Chromium renderer (Web Rendering Service).

Brass-SEO draws on:

The deferred render-queue mechanic — the basis for Brass-SEO's explanation of why JS-dependent content can be slow to index or invisible to search.

Primary source

developers.google.com/search/docs/.../javascript-seo-basics

Brass-SEO uses this to set expectations about what the renderer will and will not do. Google states that its Web Rendering Service 'does not retain state across page loads' — Local Storage, Session Storage, and cookies are cleared between pages — and that Googlebot 'does not support other types of connections, such as WebSockets or WebRTC.' Content that appears only after a user interaction, a stored session, or a real-time socket connection is therefore at risk of never being seen. The fix is to make primary content present in the rendered HTML without requiring those mechanisms.

Examines:

Google's documented limits on the Web Rendering Service: no retained state across loads, no WebSocket or WebRTC support, and content-fingerprinting guidance for cached resources.

Brass-SEO draws on:

The WRS limitations — cited when Brass-SEO advises that primary content must render without interaction, sockets, or stored state.

Primary source

developers.google.com/search/docs/.../fix-search-javascript

Brass-SEO references this to steer sites away from a dated fix. Google now states plainly that 'dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,' because it 'creates additional complexities and resource requirements.' Google instead recommends server-side rendering, static rendering, or hydration. For a small business choosing a platform or a build approach, the guidance is to render content on the server or at build time rather than bolting on a separate crawler-only rendering path.

Examines:

Google's current position that dynamic rendering is a deprecated workaround, with server-side rendering, static rendering, and hydration as the recommended alternatives.

Brass-SEO draws on:

The deprecation of dynamic rendering — cited when Brass-SEO recommends server or static rendering over crawler-specific workarounds.

Primary source

developers.google.com/search/docs/.../dynamic-rendering

Brass-SEO draws on this to explain the rendering choices behind the platforms users build on. The article documents that server-side rendering 'generally produces a fast FCP' by avoiding shipping large amounts of JavaScript, that static rendering 'achieves a consistently fast TTFB because the HTML for a page does not have to be dynamically generated,' and that hydration carries a cost — a server-rendered page 'can't actually respond to input until the client-side scripts ... have been executed.' The takeaway Brass-SEO carries to users: content rendered on the server or at build time is the most reliable for both crawlers and speed.

Examines:

Google's engineering guide to rendering strategies — server-side, static, client-side, and hydration — and their measured effects on first paint, time to first byte, and interactivity.

Brass-SEO draws on:

The performance and crawlability trade-offs between rendering strategies — cited when Brass-SEO explains why SSR or static rendering beats client-only rendering for SEO.

Primary source

web.dev/articles/rendering-on-the-web

Brass-SEO cites this for the scale of JavaScript on the real web. The 2024 analysis found the median page ships 558 KB of JavaScript on mobile and 613 KB on desktop, makes 22 JavaScript requests at the median on mobile, and that 44% of delivered JavaScript bytes go unused during page load at the median. Heavy, partly-unused JavaScript is the norm, not the exception — which is exactly the condition that makes rendering slow and crawling fragile. Brass-SEO uses these figures to ground its advice that trimming and deferring non-essential scripts helps both users and crawlers.

Examines:

HTTP Archive's measurement of JavaScript usage across millions of sites: median payload size, request counts, unused bytes, and library adoption.

Brass-SEO draws on:

The 558 KB median payload and 44% unused-bytes figures — cited when Brass-SEO explains the real-world cost of heavy JavaScript on rendering and crawl.

Primary source

almanac.httparchive.org/en/2024/javascript