JavaScript rendering is the process of running a page's JavaScript so the browser turns code into the final content a user actually sees. It is often called client-side rendering, because the work happens in your browser after the page arrives.
This matters because JavaScript is everywhere. According to W3Techs, 98.9% of websites use JavaScript as a client-side programming language, so most pages depend on it to build what you read.
Here is the catch: a page's raw HTML and its finished version can look completely different. The file the server sends is often a near-empty shell, and JavaScript fills in the rest once it runs.
How the Browser Turns JavaScript Into a Page
When a page loads, the browser handles its JavaScript in three steps: parse, compile, and execute. First it reads the code, then it prepares it to run, then it runs it.
Running the code lets JavaScript change the page through the Document Object Model (DOM). The DOM is the live, in-memory structure of the page, and JavaScript can add, remove, or update it after the first load.
A simple example makes this clear. A product page might arrive with no reviews in its HTML, then load them from a server and insert them into the DOM a second later, or only after you click "Show reviews."
Raw HTML vs. the Rendered Page
Right-click a page and choose "View Page Source," and you see the raw HTML the server sent before any JavaScript ran. Choose "Inspect" instead, and you see the rendered DOM after JavaScript finished.
That is why "View Page Source" can look nearly empty while "Inspect" shows the full page. The source is pre-JavaScript, and the rendered DOM is post-JavaScript.
Key point: anything that reads a page automatically, like a search crawler, a scraper, or an AI bot, may only get the raw HTML. If the content lives in the rendered DOM, those tools can miss it entirely.
The 3 JavaScript Rendering Methods: CSR, SSR, and SSG
There are three common ways JavaScript content gets rendered, and the choice shapes a site's speed, SEO, and security. Each one decides where and when the page is built.
The table below sums up the differences before we look at each method in detail.
| Method | Where it renders | When it renders | Best for |
|---|---|---|---|
| CSR (client-side) | In the user's browser | After the page loads | Highly interactive apps and dashboards |
| SSR (server-side) | On the server | On each request | SEO-sensitive, always-fresh pages |
| SSG (static site generation) | On the server | At build time | Fast, mostly unchanging content |
Client-Side Rendering (CSR)
With client-side rendering, the browser downloads a near-empty HTML shell plus a bundle of JavaScript, then builds the page in the browser. The server does little of the assembly work.
Pros: fast page-to-page transitions, rich interactivity, and lighter server load. Cons: the first load can be slow, crawlers may see an empty page, and performance depends on the user's device.
Server-Side Rendering (SSR)
With server-side rendering, the server builds the full HTML for each request and sends a complete page. The browser receives content that is ready to show.
Pros: better crawlability and SEO, a faster first paint, and more logic kept safely on the server. Cons: page transitions can feel slower, and the server works harder on every request.
Static Site Generation (SSG)
With static site generation, pages are rendered once at build time and served as ready-made static files, often from a CDN. This approach is a form of prerendering, since the HTML exists before anyone visits.
Pros: the fastest loads, strong SEO, and low cost. Cons: content can go stale, and you must rebuild the site to publish changes.
JavaScript Rendering and SEO
Search engines can run JavaScript, but they do it in stages. Google follows Google's JavaScript SEO basics and processes pages in three phases, crawling, rendering, and indexing, running the code with an evergreen version of Chromium.
The problem is timing. Rendering can be delayed until Google has resources to spare, so client-side content may sit unindexed while the raw HTML gets crawled first.
That is why CSR carries SEO risk, while SSR and SSG are safer bets: they hand search engines finished HTML. When a site must stay client-side, teams sometimes use dynamic rendering or prerendering, which serves a pre-built HTML version to crawlers as a workaround.
Why AI Crawlers Struggle With JavaScript
AI search is the newest wrinkle. LLM crawlers, the bots behind tools like ChatGPT and Perplexity, largely read raw HTML and skip the rendering step that browsers perform.
A Vercel/MERJ analysis in late 2024 found that AI crawlers don't render JavaScript: none of the major AI crawlers currently render JavaScript. That means client-side content can be invisible to them.
This is a growing concern as more people search through AI tools. The practical fix is the same as good SEO hygiene: put critical content in the initial HTML, or serve a fully rendered version so machines can read it.
Capturing JavaScript-Rendered Content for Scraping and AI
A plain HTTP request only returns the initial HTML, so anything built by JavaScript is missing. To capture that content, you need something that executes the page like a real browser does.
The overhead is also rising. Per the HTTP Archive Web Almanac 2024, in 2024 the median JavaScript payload rose 14%, reaching 558 KB on mobile and 613 KB on desktop, so pages lean on JavaScript more each year.
Headless Browsers (Puppeteer, Playwright, Selenium)
A headless browser is a real browser that runs without a visible window, controlled by code. Tools like Puppeteer, Playwright, and Selenium use one to execute JavaScript exactly as a normal browser would.
The trade-offs are real. Headless browsers are slower and resource-heavy, anti-bot systems can detect them, and you must wait for elements to render before you read the page. If you are weighing tools, see Puppeteer vs Selenium.
Scraping Single-Page Applications (SPAs)
A single-page application (SPA) is a site built with frameworks like React, Vue, or Angular that ships minimal HTML and renders almost everything client-side. The first response is nearly empty by design.
To read an SPA, a scraper must execute the JavaScript, wait for async data and client-side routing to finish, then extract the rendered DOM. For a deeper walkthrough, see scraping single-page applications.
Waiting, Timing, and Anti-Bot Challenges
Timing is the hard part. You have to wait until the DOM stabilizes and the network settles, and explicit waits for specific elements beat fixed delays that guess how long a page needs.
Detection adds another layer, since anti-bot systems fingerprint headless browsers and can block them. See more on handling dynamic content before you build.
Key point: running and maintaining a fleet of headless browsers at scale is costly, both in infrastructure and in engineering time.
A Managed Alternative: Rendering Without Your Own Browser Fleet
If you just want the rendered content, a web data API runs the browsers for you. Olostep executes JS rendering by default on every scrape, so JavaScript-built content is captured without extra setup.
It also handles the operational work, managing waiting and timing, rotating premium residential proxies for anti-bot reliability, and maintaining the browser infrastructure. This is the core of JavaScript rendering in web scraping: turning a live, JS-heavy page into usable data.
You send a URL to Olostep's Scrapes endpoint and get the rendered page back as clean Markdown, HTML, PDF, screenshots, or schema-defined JSON. There is no fleet to run, so your team ships the pipeline instead of maintaining scrapers.
Frequently Asked Questions
What is the difference between client-side and server-side rendering?
Client-side rendering builds the page in the user's browser after JavaScript runs, while server-side rendering builds the full HTML on the server and sends a finished page on each request.
Is JavaScript rendering bad for SEO?
It is not bad by itself, but heavy client-side rendering can delay or block indexing because search engines render JavaScript in a later stage, so SSR or SSG is safer for SEO-critical pages.
Can you scrape a website that uses JavaScript?
Yes, but a plain HTTP request only returns the raw HTML, so you need a headless browser or a web data API that executes the JavaScript and reads the rendered DOM.
Why does "View Page Source" not show the content I see on screen?
"View Page Source" shows the raw HTML the server sent before any JavaScript ran, while the content on screen lives in the rendered DOM that JavaScript built afterward.
Do AI crawlers like ChatGPT render JavaScript?
Most major AI crawlers do not render JavaScript today, so client-side content can be invisible to them unless it is in the initial HTML or served pre-rendered.
What is dynamic rendering?
Dynamic rendering is a workaround that detects crawlers and serves them a pre-built HTML version of a page, while regular users still get the normal client-side experience.
