Scrapeless Wiki

What Is Client-Side Rendering? – Definition and How It Works

Informational P2 what is client-side rendering

Learn what client-side rendering is, what the served HTML contains, why it breaks plain fetching, and the three ways to reach the content.

Client-side rendering means the server sends a mostly empty document plus JavaScript, and the browser builds the page after fetching data separately. It is the reason so many pages return nothing useful to a plain HTTP request.

1. What the Server Actually Sends

<!doctype html>
<html>
  <head><title>Products</title></head>
  <body>
    <div id="root"></div>
    <script src="/static/bundle.js"></script>
  </body>
</html>

There is no product data in that document. It arrives later, from a separate request the script makes.

2. Why It Is Used

  • Application-like interaction without full page reloads.
  • Reduced server rendering cost, since the server ships data rather than markup.
  • A clean separation between an API and its interface.
  • Rich client-side state for filters, sorting, and navigation.

3. What It Breaks

Consumer Effect
Plain HTTP fetch Receives the empty shell
Simple crawlers Index nothing meaningful
Fetchers without JavaScript Cannot quote content that never rendered
Text-only clients See an empty page

The failure is quiet: the fetch succeeds, the status is 200, and a parser finds nothing. Code that checks only the status stores an empty record.

4. Detecting It

curl -s "https://example.com/products" | grep -c "a value visible in the browser"

Zero matches, with the content plainly visible in a browser, confirms client rendering. Non-zero means the data is present and the parser is the problem.

5. The Three Ways to Reach the Content

  1. Call the endpoint the page calls. Open the network panel, find the request returning the data, and request it directly. Cheapest and most stable.
  2. Read the embedded state. Many frameworks ship the initial data in a script tag so the first render needs no round trip. A single fetch plus JSON parsing gets it.
  3. Render in a browser. Always works, costs the most per page.

Check them in that order. Most teams build the third and later discover the first.

6. Hydration and Server Rendering

Frameworks increasingly render on the server and then attach interactivity in the browser. That produces a document containing real content, which is better for fetchers and for search.

Partial approaches also exist, where a shell is served with content streaming in β€” so "client-side rendered" is now a spectrum rather than a binary.

7. Validate What You Collect

An empty shell parses cleanly. So does a challenge page and an empty-state view. Assert on expected record counts and required fields, so a run that collected nothing fails rather than writing a quiet zero.

8. Summary

Client-side rendering serves a shell and builds the page in the browser from separately fetched data, so plain requests return nothing useful while reporting success.

Detect it by grepping the served HTML, then reach the content through the underlying endpoint, the embedded state, or a browser β€” in that order of preference and cost.