Render Budget

SEO

Also: Rendering Budget · JavaScript Render Budget

What it limitsTime Google spends rendering JS

Separate fromCrawl budget

RiskContent never gets seen

Worse whenSite is JavaScript-heavy

Quick definition

Render budget is the finite time and computing resource Google allocates to running a page's JavaScript before indexing it. If a page needs JavaScript to show its content and Google's render budget runs out first, that content may never make it into the index at all.

How it varies across Australia

Australian sites built on heavier JavaScript frameworks without server-side rendering typically show a wider gap between crawl date and index date in Search Console. That delay is the render budget queue in action. Sites serving pre-rendered HTML close the gap almost completely.

See digital maturity benchmarks across Australian industries →

What it actually means

Most people assume Google reads a page the moment it crawls it. That's only true for plain HTML. If your content is built with JavaScript, Google has to run that code before it can see the words on the page, and running code costs more than reading text.

Google handles this in two waves. First, it crawls the raw HTML and indexes whatever is immediately visible. Second, it queues the page for rendering, where a headless browser actually executes the JavaScript and captures what shows up afterwards. That second wave draws from a separate, limited allocation of computing resource. That allocation is the render budget.

The gap between wave one and wave two can be hours on a well-optimised site or weeks on a heavy one. During that gap, anything that only exists after JavaScript runs (product descriptions, prices, key copy) is effectively invisible to Google. Indexing is delayed, not guaranteed, and on a large enough site the render queue never catches up. This sits squarely in the technical SEO and crawl efficiency conversation, right alongside crawl budget and Core Web Vitals.

Crawling gets Google to your page. Rendering is a second queue, and JavaScript-heavy sites wait longer in it.

How it shows up

Render budget problems show up as a lag between when Search Console shows a page was crawled and when its content actually appears in the index. It shows up when the 'View Crawled Page' rendered screenshot in Search Console is missing key content that's clearly visible in a browser. It also shows up as large JavaScript-heavy sites where only a fraction of pages ever get indexed, despite all of them being crawlable. If content only appears after client-side JavaScript runs and indexing volume looks lower than page count justifies, render budget is the usual suspect.

The Australian context

Distance adds a layer most Australian teams don't think about. Google's rendering infrastructure isn't run from inside Australia, so any round trip needed during rendering (API calls, personalisation checks, geolocation lookups) adds latency on top of the render queue itself. Sites that keep critical content out of those round trips and serve it in the initial HTML sidestep most of the problem.

Where people get this wrong

Assuming a page is indexed because it was crawled.Crawling and rendering are separate steps. A crawled page with JavaScript-dependent content can sit unrendered for weeks, which means unindexed for weeks.

Loading critical content only after user interaction.Google's renderer doesn't click, scroll or hover. Content that only appears after an interaction is invisible to it regardless of how much render budget is available.

Treating this as a crawl budget issue and fixing the wrong thing.Crawl budget governs how often Googlebot visits your URLs. Render budget governs whether it can afford to execute the JavaScript once it's there. Fixing one does nothing for the other.

Render Budget vs Crawl Budget

	Render Budget	Crawl Budget
What it governs	Time and compute to execute JavaScript	How many URLs Googlebot visits and how often
Where the delay happens	Between crawling and indexing	Between page publish and first crawl
Fixed by	Server-side rendering, lighter JavaScript	Cleaner site structure, fewer wasted URLs
Visible in Search Console as	Rendered screenshot missing content	Crawl stats showing low crawl frequency

Common questions

How do I know if render budget is affecting my site?

Use the URL Inspection tool in Search Console and compare the rendered screenshot against what a normal browser shows. If key content is missing from the render but visible in your browser, Google hasn't rendered it fully or hasn't rendered it yet.

Does server-side rendering fix render budget problems?

Largely, yes. If content is present in the initial HTML response, Google can index it during the first crawl wave without waiting for the second rendering wave. This removes most of the delay entirely.

Is render budget the same as crawl budget?

No. Crawl budget is about how often and how many pages Googlebot visits. Render budget is about the separate computing allocation used to execute JavaScript on the pages it has already crawled. A site can have plenty of crawl budget and still lose content to render budget limits.

Does render budget affect small sites?

Rarely in a serious way. Render budget constraints mostly bite large, JavaScript-heavy sites with thousands of pages competing for the same rendering queue. A small brochure site with client-side JavaScript will usually still get rendered, just with more delay than plain HTML would need.

Debrief

Get the next one

No spam. No fluff. Just the next article, straight to your inbox.

Keep exploring

About New Rebellion

New Rebellion is a marketing intelligence consultancy. We build tools, score Australian businesses on how their marketing actually performs, and publish Debrief every day. This dictionary is part of how we work in the open.

How we think →