AI Summary
This case study races the same content to the index using different delivery methods and measures how long each takes. The result is consistent: content that is already in the HTML is indexed on the first crawl wave, while content that only appears after JavaScript has to wait in Google's render queue, which is often quick but highly variable with a long tail.
- HTML and server rendered pages are indexed fastest, on the first wave.
- Client side JavaScript waits for a second render wave before its content counts.
- The render delay is variable, so time sensitive pages are the ones at risk.
- Winning the race means putting the important content and links in the HTML.
Indexing is not instant, and it is not equally fast for every page. This case study turns that into a race: publish the same content through different delivery methods and clock how long each takes to appear in the index. The pattern that falls out is the practical heart of JavaScript SEO. What is already in the HTML crosses the line first, and what depends on JavaScript has to wait for a second pass whose timing you do not control.
Two waves means two speeds
Google indexes in two waves. The first wave reads the raw HTML at crawl time and can index whatever is already there. If the meaningful content only exists after scripts run, that content is not in the first wave, so the URL is queued for rendering and picked up in a second wave later. For a static or server rendered page the two waves collapse into one fast step, because the HTML already carries everything. For a client side rendered page the second wave is a separate event, and the gap between them is the delay this race measures.
Why the render delay is so variable
The render queue is not a fixed timer. How quickly a page is rendered depends on Google's available resources, how much it wants to crawl your site, and how heavy the page is to render. Google has said the typical wait is short, but it is an average with a long tail: some pages render almost immediately while others sit for much longer. That unpredictability is the real problem, because you cannot promise a stakeholder when a JavaScript dependent page will be findable.
Delivery method versus indexing speed
| Delivery method | What the first crawl sees | Relative time to index | Best suited for |
|---|---|---|---|
| Content in the HTML source | Full content and links | Fastest | Anything time sensitive |
| Server side rendering | Full content and links | Fast | Dynamic apps that need fresh HTML |
| Static generation or ISR | Full prebuilt content | Fast | Large, mostly stable catalogs |
| Client side rendering only | An empty shell, content later | Slowest and variable | Low priority or logged in areas |
When the delay actually matters
For an evergreen article that will earn traffic for years, a few extra days to index is a rounding error. For a news story, a product launch, a limited drop, an event page, or anything with a price or stock level that changes, the delay is the difference between being found in time and missing the window. The rule of thumb is simple: the more perishable the page, the less you can afford to leave its content behind a render wave.
How to run your own indexing speed test
You do not need a lab to check this on your own site. Publish a page, note the timestamp, and use the URL Inspection tool to watch when it moves from crawled to indexed, and whether the indexed version contains the JavaScript dependent content. Compare the raw HTML with the rendered HTML to confirm what is waiting on the render wave. For a cleaner comparison, deliver equivalent content two ways and measure the gap, which mirrors the experimental thinking in SEO experimental design and causal inference.
How to win the race
- Put the important content and links in the HTML. Server side rendering or static generation removes the dependence on the second wave entirely.
- Help discovery. Keep sitemaps current, link new URLs from pages that are already indexed, and request indexing for genuinely urgent pages.
- Keep the page cheap to render. Smaller bundles and a fast server shorten both the crawl and the render steps.
- Do not hide content behind interactions. Content that appears only after a click or scroll event is even harder for the crawler to capture.
The resource cost behind that render wave is unpacked in JavaScript versus crawl budget, and the trade offs between rendering modes are compared in React rendering modes on product pages.
This SEO case study documents a successful optimization initiative, providing actionable insights for practitioners. The documented approach demonstrates how strategic SEO implementation drives measurable results.
Initial Situation
Understanding the starting point is essential context for evaluating any case study. This documentation covers the initial challenges, competitive position, and business objectives that shaped the SEO strategy.
Strategy and Approach
The strategic approach combined multiple SEO disciplines to address identified opportunities. Key decisions around prioritization and resource allocation provide a template for similar initiatives.
Implementation
Moving from strategy to execution required specific technical implementations, content development, and process changes. This case study documents the practical steps that translated strategy into action.
Results and Learnings
The outcomes demonstrate effectiveness through measurable improvements in rankings, traffic, and business metrics. Analysis of successes and challenges provides learning value for practitioners.
Case studies like this contribute to the SEO knowledge base, helping practitioners learn from documented real-world experiences.
Source: https://strategiq.co/javascript-indexing-drag-race/
FAQ
Often yes. Content that only appears after JavaScript is picked up on a second render wave rather than the first crawl, so it waits in Google render queue. Content already in the HTML is eligible for indexing on the first wave, which is why it is consistently faster.
It varies. Google has said the typical wait is short, but it is an average with a long tail, so some pages render almost immediately and others wait much longer. Because you cannot control or predict it, time sensitive pages should not depend on it.
Content that is already in the HTML, whether static, server side rendered, or statically generated, is indexed fastest because the first crawl wave already has it. Client side rendering is slowest because its content only exists after the render wave.
It matters most for perishable pages: news, product launches, limited releases, event pages, and anything with prices or stock that change. For evergreen content a small delay has little impact, so the effort should go where timing is critical.
Publish a page, record the time, and use URL Inspection in Search Console to watch when it becomes indexed and whether the indexed version includes the JavaScript dependent content. Comparing the raw and rendered HTML shows exactly what is waiting on the render wave.
The most effective step is to stop depending on the render wave by moving content into the HTML with server side rendering or static generation. Beyond that, keep sitemaps current, link the URL from already indexed pages, keep the page fast to render, and request indexing for urgent pages.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
