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

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 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 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 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.