TL;DR. Render budget describes the limited compute Google's Web Rendering Service spends executing a page's JavaScript before its content counts toward the index, a term the SEO community coined since Google itself has never published an official metric by this name. Pages that depend on JavaScript to reveal their content wait through a second indexing pass that has been observed running anywhere from minutes to several days after the first.
What is render budget?
Render budget refers to the finite processing resources Google's Web Rendering Service allocates to running a page's JavaScript and producing its final, fully assembled content. Nobody at Google publishes a number for it. The term exists because site owners needed language for a real bottleneck: getting crawled is not the same as getting rendered, and getting rendered is not the same as getting indexed with the page's full content intact.
The concept builds directly on crawl budget, one step further down the pipeline. A URL can clear the crawl budget hurdle easily and still stall at the rendering stage, invisible to Google until the Web Rendering Service actually gets around to it.
Key highlights
- Google indexes JavaScript-heavy pages in two separate passes. The first reads the raw HTML response. The second, arriving later, hands the page to the Web Rendering Service for JavaScript execution.
- The gap between those two passes has been observed running from a few minutes to several days, largely tracking a site's crawl priority and overall authority.
- Chromium sits underneath the Web Rendering Service, evergreen and headless, executing scripts and assembling the DOM the same way a real browser would, just without anyone watching.
- Content that only materializes after JavaScript runs is not just delayed. It is also weighted differently in the near term, since Google has not yet confirmed the page's full state.
How two-wave indexing actually plays out
Googlebot's first pass fetches whatever the server returns immediately: raw HTML, present links, present metadata, no scripts executed. Whatever content lives outside that raw response has to wait for the second pass, when the page enters a render queue and the Web Rendering Service takes over.
Nothing added by JavaScript exists to Google until that second pass finishes. If the render queue is backed up, or the site carries less crawl priority, that content sits invisible for as long as the queue takes to clear.
Where render budget and crawl budget split
Crawl budget caps how many URLs Googlebot bothers fetching in the first place. Render budget caps something downstream of that: how much of what got fetched actually gets its JavaScript run and its final state captured.
A page can burn through its crawl budget in seconds and then sit unrendered for days, a distinction that barely matters on a small static site and matters enormously on a large JavaScript-heavy one.
Cutting a page's dependence on render budget
- Ship critical content through server-side rendering or static generation so it arrives in the first wave's raw HTML, no render queue required.
- Save client-side rendering for content nobody needs indexed, personalization widgets, logged-in dashboards, anything that was never going to rank.
- Trim the JavaScript execution path itself, since a simpler script finishes faster once the second wave actually reaches the page.
- Pull up the URL Inspection Tool's rendered HTML view and compare it against the raw source, since that comparison is the only reliable way to know what Google currently sees.
Frequently asked questions
What is render budget?
Render budget names the limited compute Google spends running a page's JavaScript, not an official Google term, but community shorthand for a real constraint on how fast, or whether, a script-dependent page gets its full content indexed.
Does a fast crawl guarantee a fast render?
No. Crawling and rendering are separate stages with separate budgets. A page fetched instantly by Googlebot can still sit in a render queue for days before its JavaScript executes, which is exactly the gap render budget describes.
Why does two-wave indexing exist at all?
Two-wave indexing exists because executing JavaScript at web scale is expensive. Reading raw HTML is cheap and can happen immediately for every crawled URL. Running a full headless browser against every page is not, so Google defers that work to a second pass and prioritizes it using signals like site authority.
Is server-side rendering worth the switch?
Server-side rendering removes the problem outright for content that needs to rank, since fully formed HTML ships in the first wave and Google never has to wait on the second. Sites that depend on rankings for JavaScript-heavy pages treat this as closer to a requirement than an optimization.