Web Page Rendering

Key Takeaways

• Rendering is the browser process that converts HTML, CSS, JavaScript, images, and other resources into a visual, interactive webpage.
• The Critical Rendering Path parses HTML and CSS, processes JavaScript, builds the render tree, calculates layout, paints, and composites the page.
• JavaScript rendering can create or modify visible content after initial HTML delivery, enabling dynamic interactions but potentially delaying important content.
• CSR, SSR, and SSG differ in where rendering occurs, but SEO depends primarily on accessible content, reliable rendering, and strong performance.

Web page rendering is the process through which a browser converts HTML, CSS, JavaScript, images, and other resources into the visual, interactive webpage displayed on a screen. The web server may generate or send HTML and other resources, while the browser performs the final visual rendering that turns those resources into what appears on the screen.

In terms such as server-side rendering, ‘rendering’ can also refer to generating HTML before it reaches the browser. For example, a server can generate a product page’s HTML in response to a request and send that populated HTML to the browser, which then performs the final visual rendering on the screen.

A central part of this process is the Document Object Model (DOM), the browser’s in-memory representation of an HTML document. The DOM organizes the document as a hierarchical tree of nodes that scripts can access and modify.

For example, consider this simple HTML:

<!DOCTYPE html>
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <p>Welcome to my site.</p>
  </body>
</html>

A simplified DOM representation would look like:

Each HTML element and piece of text becomes part of the DOM as a node. The DOM describes the document’s structure and content, while CSS is processed separately into the CSS Object Model (CSSOM) to describe how those elements should look. JavaScript can then read or modify the DOM and styling information, allowing the page to change after the initial HTML has loaded.

How a Browser Renders a Page

The Critical Rendering Path is the sequence of work a browser performs to turn downloaded page resources into pixels visible on the screen.

1. Parse HTML and Build the DOM

The browser reads the HTML document and converts its elements and text into the hierarchical DOM tree. Parent and child relationships allow the browser and JavaScript to understand how different parts of the page relate to one another.

2. Parse CSS and Build the CSSOM

The browser processes CSS rules and creates the CSSOM, which represents the styling information required for the page. It determines properties such as fonts, colors, dimensions, spacing, and visibility.

3. Process Relevant JavaScript

JavaScript can add, remove, or change DOM elements and modify styles. Scripts that require significant processing or block HTML parsing can delay how quickly important content becomes visible.

4. Build the Render Tree

The browser combines relevant information from the DOM and CSSOM to determine which elements need to be displayed and how they should appear. Elements hidden with rules such as display: none are not included in the visible render tree.

5. Calculate Layout

The browser calculates the size and position of each visible element within the viewport. This determines where headings, paragraphs, images, buttons, and other elements will appear.

6. Paint and Composite the Page

The browser paints text, backgrounds, borders, images, shadows, and other visual details. The Critical Rendering Path is the sequence of work a browser performs to turn downloaded page resources into pixels visible on the screen.

Rendering does not necessarily happen only once. As images, fonts, scripts, or new content become available, parts of the rendering process may run again to update what appears on the screen.

Cumulative Layout Shift (CLS) and Visual Stability

Rendering also affects how stable a page appears while it loads. If images, videos, advertisements, embeds, or dynamically inserted elements do not have enough space reserved before they appear, they can unexpectedly move content that has already been displayed.

These movements contribute to Cumulative Layout Shift (CLS), a Core Web Vital that measures visual stability. Google recommends a CLS score of less than 0.1 to provide a good user experience.

Common causes include images without dimensions, advertisements or embeds without reserved space, dynamically inserted content, and some font changes. Providing image width and height attributes or otherwise reserving the correct aspect ratio allows the browser to calculate the required space earlier.

CLS is part of Google’s Core Web Vitals. Google says Core Web Vitals are used by its ranking systems, although good scores alone do not guarantee top rankings.

Three Common Approaches for Web Page Rendering

Websites can generate and deliver content in different ways depending on whether most of the work happens on the server, in the browser, or before a visitor makes a request.

Client-Side Rendering (CSR)

With Client-Side Rendering, the server typically sends minimal or partially populated HTML along with JavaScript. The browser executes the JavaScript, retrieves any additional data it needs, and builds or updates much of the visible content on the user’s device.

Frameworks such as React, Vue, and Angular can use client-side rendering, although they can also support other rendering approaches.

CSR can create highly interactive applications, but important content may depend on successful JavaScript execution before it becomes visible.

Server-Side Rendering (SSR)

With Server-Side Rendering, the server generates populated HTML when a request is made and sends that HTML to the browser. The browser can begin processing meaningful page content without first depending on client-side JavaScript to create it.

Traditional WordPress sites commonly follow a server-rendered model, while modern frameworks such as Next.js can also render pages on the server.

Static Site Generation (SSG)

With Static Site Generation, pages are rendered into HTML before users request them, usually during a build process. The finished files can then sit on a server or CDN ready to be delivered when requested.

SSG is particularly useful for content that does not need to be regenerated individually for every visitor. Modern websites can also use hybrid rendering, combining server-rendered or statically generated HTML with client-side JavaScript where additional interactivity is needed.

Which Web Page Rendering Method Is Best for SEO?

There is no single rendering method that is automatically best for SEO. SSR and SSG make important content available directly in the initial HTML, reducing reliance on crawler-side JavaScript execution.

Google can crawl and render JavaScript-powered pages and uses an evergreen version of Chromium for rendering. Its process broadly involves crawling, rendering, and indexing. However, Google also notes that server-side or pre-rendering remains a good approach because it can improve performance for users and crawlers, and not every bot can execute JavaScript.

CSR is therefore not inherently bad for SEO, and SSR or SSG does not automatically create a ranking advantage. The important considerations are whether critical content is reliably accessible, rendering works correctly, and pages perform well.

How to Improve Web Page Rendering and Page Experience

Rendering should make important content available quickly while maintaining a stable, usable layout across devices and browsers.

Google Search Console’s URL Inspection Tool can be used to test how Google retrieves and renders a page. The rendered HTML can help identify content that is missing because of blocked resources, JavaScript failures, or other rendering problems. Google also recommends using the URL Inspection Tool when diagnosing JavaScript SEO issues.

1. Check Mobile Layouts: Test pages across different mobile screen sizes and real devices where possible. Layouts, menus, images, and interactive elements should remain usable without horizontal scrolling or overlapping content.

2. Compress and Size Images Properly: Reduce unnecessary file weight and serve images at dimensions appropriate for the device and layout.

3. Use Responsive Design: Layouts should adapt appropriately to different viewport sizes instead of relying on one fixed desktop arrangement.

4. Lazy Load Below-the-Fold Media: Lazy loading can defer images and embeds that are not initially visible. Important above-the-fold images, especially the likely Largest Contentful Paint image, should generally not be lazy loaded unnecessarily.

5. Space Interactive Elements Appropriately: Buttons, links, and other controls should provide enough space for comfortable interaction, particularly on touchscreens.

6. Test Across Browsers: Pages should remain functional, readable, and visually consistent in browsers such as Chrome, Safari, Firefox, and Edge.

7. Keep Text Readable: Font sizes, line spacing, contrast, and layout should make content comfortable to read without requiring visitors to zoom.

8. Audit Heavy Third-Party Scripts and Widgets: Advertising scripts, social embeds, live chats, tracking tools, and other third-party resources can add network requests and JavaScript processing that delay rendering.

9. Reduce Render-Blocking Resources: Excessive render-blocking CSS and synchronously loaded JavaScript can delay the initial render. Keep critical CSS lean, and defer or load nonessential scripts asynchronously where appropriate.

Google’s JavaScript guidance emphasizes ensuring that important content remains accessible after rendering and recommends inspecting rendered HTML when troubleshooting problems.

Frequently Asked Questions

Why does a website look different on a phone than on a computer?

Responsive websites adapt their layouts according to factors such as viewport width, CSS media queries, available screen space, and device capabilities. Browsers and operating systems can also render fonts and interface elements slightly differently.

What does “render-blocking” mean in a speed test?

A render-blocking resource delays work the browser needs to complete before important page content can appear. CSS and synchronously loaded JavaScript are common examples, although whether a particular resource is actually blocking depends on how it is loaded and used.

How does lazy loading improve the web page rendering process?

Lazy loading delays downloading certain below-the-fold resources until they are closer to being needed. This reduces unnecessary initial network work, but important above-the-fold or LCP media should generally be loaded promptly.

Can Google read content that relies on JavaScript rendering?

Google generally can. Google Search uses an evergreen Chromium renderer and processes JavaScript pages through crawling, rendering, and indexing, but blocked resources, errors, or incompatible JavaScript can still prevent important content from being rendered correctly.

How can Google’s rendered version of a webpage be checked?

Google Search Console’s URL Inspection Tool can run a live test and expose information from the fetched and rendered page. The rendered HTML can then be reviewed to check whether important content and links are available to Google.