---
title: "Googlebot's two-wave rendering: how long JS content actually waits"
url: https://seomadman.com/research/javascript-rendering-googlebot-delay
section: research
published: 2026-07-17T00:00:00.000Z
modified: 2026-07-17T00:00:00.000Z
author: Adam Hafez
topics: ["Technical SEO"]
---

# Googlebot's two-wave rendering: how long JS content actually waits

## The short answer

A 2024 Vercel and MERJ study tracked over 100,000 Googlebot fetches on nextjs.org and found 100% of valid HTML pages were eventually fully rendered. The median delay between crawl and render was 10 seconds, but the 99th percentile stretched to roughly 18 hours. Google confirms a two-wave process: HTML first, JavaScript later, on a queue with no fixed wait time.

## Key takeaways

- Vercel and MERJ analyzed over 100,000 Googlebot fetches on nextjs.org in April 2024 and reported 100% of valid HTML pages were fully rendered.
- The measured render delay had a median of 10 seconds and a 75th percentile of 26 seconds, but stretched to about 3 hours at the 90th percentile and about 18 hours at the 99th.
- Google's own JavaScript SEO documentation confirms the two-wave structure: an initial HTML crawl, then a separate rendering pass once resources allow.
- Google's documentation states the rendering queue delay can be a few seconds but can also take longer, without naming a fixed maximum.
- Google's own crawl budget documentation says most sites do not need to think about crawl budget at all; it names large or rapidly-changing sites as the exception, not the rule.

Googlebot does not read a JavaScript-rendered page the way a browser does, in one pass. It fetches
the raw HTML first, queues the links it finds there, and executes the page's JavaScript separately,
later, when rendering capacity is available. That structure is old news to anyone who has read
Google's own documentation. What has been harder to pin down is how long the gap between those two
steps actually runs in practice, and a 2024 study set out to measure exactly that instead of
describing it only in general terms.

## What the study measured

[Vercel and MERJ](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process)
instrumented nextjs.org with Vercel's own Edge Middleware for 30 days in April 2024, comparing
Googlebot requests recorded in server logs against rendering beacons fired once a page's
JavaScript had actually executed. Two smaller sites, monogram.io and basement.io, were included as
secondary checks. After excluding error responses and pages marked non-indexable, the study
tracked over 100,000 Googlebot fetches and matched roughly 37,000 of them to a completed render.

**Every valid page in the sample eventually rendered.** The study's own figure is that 100% of
valid HTML pages resulted in a full-page render. That is a completion rate, not a speed claim, and
it is worth keeping the two apart: it says Googlebot did not give up on any page in the sample, not
that every page rendered quickly.

**Speed is where the real variation shows up.** The median time between crawl and completed render
was 10 seconds, and a quarter of pages rendered within 4 seconds. That is fast enough that most
JavaScript-dependent content in this sample was not meaningfully delayed at all.

## The slow tail is the part worth remembering

A median of 10 seconds understates the picture on its own, because the distribution has a long
tail. The 75th percentile was 26 seconds, still fast, but the 90th percentile stretched to roughly
3 hours, the 95th to roughly 6 hours, and the 99th to roughly 18 hours. A small share of pages in
the sample waited nearly a full day for their JavaScript to execute.

**This lines up with Google's own framing, not against it.** Google's [JavaScript SEO
documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
describes the render queue directly: a page may stay on it for a few seconds, but it can take
longer than that, with no committed maximum. The study puts real numbers on a delay Google has
always described only qualitatively, and both sources agree on the shape, fast for most pages, with
a real tail for some.

## Why we care

For most sites, the practical read is not "chase faster rendering," it is "don't assume JavaScript
content is invisible to Google by default." A page whose critical content depends on client-side
JavaScript is very likely to render, per this study's own numbers, and often within seconds. The
exception worth planning for is the tail: a page that needs to be indexed within minutes, not hours,
should not depend on the render queue at all, whether through server-side rendering or static
generation for that specific content. It is also worth resisting the jump some coverage makes from
"render delay exists" straight to "crawl budget problem." Google's own [crawl budget
documentation](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget)
is explicit that most sites do not need to manage crawl budget as a distinct concern at all; that
applies mainly to large or very fast-changing sites. A render-delay finding on one Next.js site in
one month of 2024 is not evidence that typical single-page apps are burning crawl budget at scale,
and no verifiable source was found for that specific claim.

## Frequently asked questions

### Does the 100% full-render figure mean Google renders every JavaScript site perfectly?

No. It is the completion rate the study measured on one site, nextjs.org, over one 30-day window in 2024, after excluding error pages and pages marked non-indexable. It says every valid page eventually got rendered in that sample, not that rendering was instant or that every framework performs the same way.

### What is two-wave indexing, in Google's own terms?

Google's JavaScript SEO documentation describes crawling and rendering as separate steps rather than one pass. Googlebot fetches and parses the raw HTML first, queuing any links it finds; a headless Chromium instance executes the page's JavaScript in a later, separate step once rendering resources are available. Google's own wording says that wait can be a few seconds but can also take longer, without committing to a fixed number.

### Should a typical site worry about crawl budget because of render delay?

Google's own crawl budget documentation says most sites do not need to think about crawl budget as a distinct problem; it applies mainly to very large sites or sites whose pages change very fast. A render-delay finding on JavaScript content is a separate question from crawl budget, and conflating the two overstates the risk for a typical site.

## Sources

1. [Javascript SEO: How Google Crawls, Renders & Indexes JS](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) - Vercel (primary)
2. [Google's JavaScript Rendering Capabilities](https://merj.com/blog/googles-javascript-rendering-capabilities) - MERJ
3. [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) - Google Search Central (primary)
4. [Large site owner's guide to managing your crawl budget](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) - Google Search Central