Browser Rendering
How cloud browser rendering works under the hood
By default the crawler fetches pages with plain HTTP - fast, free, and accurate for server-rendered sites. Sites that build their content with JavaScript (SPAs, client-side frameworks) can look nearly empty to a plain fetch, which skews every content rule.
Cloud browser rendering fixes that: each page is loaded in a real headless browser in the cloud, and the fully rendered DOM is returned to your local crawler. Everything downstream - parsing, rules, reports - works exactly as it does with plain HTTP, just on the post-JavaScript HTML.
Cost
2 credits per page rendered. A 100-page crawl with rendering costs 200 credits, so mind your per-audit cap - the default cap of 200 covers rendering for about 100 pages and nothing else. The crawl progress line shows the running spend:
Crawling (cloud-rendered) 34/100 · ~68 credits
Fallback behavior
Rendering is best-effort and degrades gracefully:
- Single page fails or times out - that page falls back to plain HTTP; the crawl continues rendering the rest.
- Out of credits, auth error, or service outage - the crawler switches permanently to plain HTTP for the remainder of the crawl, prints a one-line warning, and notes the fallback in the report metadata.
A render failure never fails the audit.
When to use it
| Site | Recommendation |
|---|---|
| Server-rendered (most CMS, SSR frameworks, static sites) | Plain HTTP (default) - rendering adds cost, not accuracy |
| Client-side SPA (React/Vue/Angular without SSR) | Browser rendering |
| Mixed - mostly SSR with a few JS-dependent pages | Try plain HTTP first; if content rules report thin/missing content on pages you know have content, switch |
A quick tell: run squirrel audit normally, and if word counts or headings look implausibly low on pages that render fine in your browser, the site needs rendering.