Critical Rendering Path: How Browsers Show Pages
The critical rendering path is the sequence of steps a browser takes to render pixels.
Critical Rendering Path
The critical rendering path is the sequence of steps a browser must complete before it can show anything on screen. Optimising this path is one of the most effective ways to improve First Contentful Paint and Largest Contentful Paint scores, and to make pages feel fast for real users on real devices.
What Is the Critical Rendering Path
When a browser navigates to a page, it performs a series of sequential steps to convert your HTML, CSS, and JavaScript into visible pixels. Each step depends on the one before it, which means a delay at any stage pushes back everything that follows. The time from the moment the user types a URL to the moment they see content on screen is determined entirely by how quickly the browser can complete this sequence.
The goal of critical rendering path optimisation is to reduce the number and size of resources that must be processed before the browser can paint anything at all. Every kilobyte of render-blocking CSS and every parser-blocking script adds directly to the time users spend staring at a blank screen.
The Steps in Order
| Step | What Happens | Output |
|---|---|---|
| 1. HTML Download | The browser sends an HTTP request and fetches the HTML document from the server | Raw HTML bytes |
| 2. HTML Parse | The browser reads the HTML from top to bottom and builds a tree of nodes | DOM (Document Object Model) |
| 3. CSS Download | The browser fetches all linked stylesheets referenced in the document | CSS bytes, blocks rendering until complete |
| 4. CSS Parse | The browser processes all CSS rules and resolves which styles apply to which elements | CSSOM (CSS Object Model) |
| 5. Render Tree | The DOM and CSSOM are combined into a single tree containing only visible nodes with their computed styles | Render Tree |
| 6. JS Execution | Blocking scripts are fetched and executed, potentially modifying the DOM or CSSOM before rendering continues | Updated DOM and CSSOM |
| 7. Layout | The browser calculates the exact position and size of every element in the render tree relative to the viewport | Layout geometry |
| 8. Paint | The browser draws the visual representation of each element onto layers in memory | Painted layers |
| 9. Composite | The individual painted layers are combined in the correct stacking order and displayed on screen | Visible page |
What Blocks the Critical Rendering Path
Not all resources block the critical rendering path equally. Some halt the browser completely until they are downloaded and processed. Others cause partial delays or can be deferred safely. Identifying which resources are blocking and addressing them in priority order is the core task of critical path optimisation.
| Resource | Blocks Rendering? | Recommended Fix |
|---|---|---|
CSS in <head> | Yes, render-blocking. The browser will not paint until the full CSSOM is built. | Inline critical above-the-fold CSS in a <style> tag. Load non-critical CSS asynchronously. |
Regular <script> | Yes, parser-blocking. HTML parsing stops until the script is fetched and executed. | Add defer or async attribute, or move the script to the end of <body>. |
<script defer> | No. Downloads in parallel with HTML parsing and executes after parsing is complete. | Use for scripts that depend on the DOM being fully parsed. |
<script async> | Partial. Downloads in parallel but executes immediately when ready, briefly pausing the parser. | Use for independent scripts like analytics where execution order does not matter. |
| Images | No. Images do not block parsing or the initial render. | Use loading="lazy" for below-the-fold images to reduce initial page weight. |
| Web Fonts | Partial. Can cause Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT) while loading. | Use font-display: swap and preload critical font files with <link rel="preload">. |
Key Optimisation Techniques
Most critical rendering path improvements fall into one of three categories: removing unnecessary blocking resources, reducing the size of necessary ones, and loading non-critical resources later. The techniques below address all three.
- Inline critical CSS: Extract the CSS rules needed to render above-the-fold content and place them directly in a
<style>tag in the<head>. This eliminates the render-blocking stylesheet request for the initial paint. Load the full stylesheet separately after the page is visible. - Defer all non-critical JavaScript: Add the
deferattribute to any script that does not need to run before the page is rendered. Deferred scripts download in the background and execute only after HTML parsing is complete, removing them from the critical path entirely. - Preload critical resources: Use
<link rel="preload">in the<head>to instruct the browser to fetch high-priority resources such as hero images, critical fonts, or key JavaScript files as early as possible, before the parser would normally discover them. - Minimise DOM size: Larger DOMs take longer to parse, style, and lay out. Remove unused HTML elements, flatten deeply nested structures where possible, and avoid inserting large amounts of hidden content that still needs to be processed.
- Compress CSS and JavaScript: Enable Gzip or Brotli compression on your server for text-based assets. Brotli typically achieves 15 to 25 percent better compression than Gzip for CSS and JavaScript files, reducing download time directly.
- Reduce server response time: The critical rendering path begins the moment the browser sends its request. A slow Time to First Byte delays every subsequent step. Use a CDN, optimise database queries, and enable HTTP caching to keep server response times low.
- Use resource hints: Beyond preload,
rel="dns-prefetch"andrel="preconnect"allow the browser to resolve DNS and establish connections to third-party origins before they are needed, reducing the overhead of fetching cross-origin resources.
Measuring the Critical Rendering Path
Several tools help you identify which resources are on the critical path and how much time each step takes. Using these tools before and after making changes lets you confirm that your optimisations are having the intended effect.
- Chrome DevTools Performance panel: Records a detailed timeline of every step in the rendering pipeline, showing exactly which resources blocked rendering and for how long.
- Chrome DevTools Network panel: The waterfall view shows when each resource starts downloading, how long it takes, and whether it is on the critical path. Look for long bars early in the waterfall.
- Lighthouse: Available in Chrome DevTools and as a command-line tool, Lighthouse audits your page and flags render-blocking resources, unused CSS, and unoptimised images with specific recommendations.
- PageSpeed Insights: Google's online tool runs Lighthouse against your URL and provides both lab data and real-world field data from the Chrome User Experience Report.
- WebPageTest: Provides a detailed filmstrip view showing exactly when content first appears, along with a waterfall chart that identifies blocking resources across multiple connection types and locations.
Frequently Asked Questions
- What is First Contentful Paint?
First Contentful Paint (FCP) measures the time from navigation start to when the browser renders the first piece of DOM content, whether that is text, an image, or a canvas element. It is the first visible signal to the user that the page is actually loading. A good FCP is under 1.8 seconds. Render-blocking CSS and parser-blocking JavaScript are the most common causes of a slow FCP. - What is Largest Contentful Paint?
Largest Contentful Paint (LCP) measures when the largest visible content element on the page, usually a hero image or a main heading, finishes rendering. Google uses LCP as one of the Core Web Vitals metrics. The target is under 2.5 seconds. Slow server response times, render-blocking resources, and unoptimised images are the most common causes of a poor LCP score. - Does server response time affect the critical rendering path?
Yes, directly. The critical rendering path begins the moment the browser sends its request, not when it starts receiving data. A slow server response, measured as Time to First Byte (TTFB), delays the HTML download, which delays DOM parsing, which delays CSS and JavaScript discovery, which delays everything else. Reducing TTFB through server optimisation or CDN placement is often the single highest-impact improvement you can make. - What is the difference between render-blocking and parser-blocking?
A render-blocking resource prevents the browser from painting anything to the screen until it is fully downloaded and processed. CSS in the head is render-blocking because the browser needs the complete CSSOM before it can build the render tree. A parser-blocking resource stops the browser from reading further into the HTML document. Regular script tags are parser-blocking because the browser must stop, fetch, and execute the script before it can continue parsing the HTML below it. - Should I inline all my CSS to eliminate render-blocking stylesheets?
Only critical CSS, which is the CSS needed to render above-the-fold content, should be inlined. Inlining your entire stylesheet increases the size of the HTML document, prevents the CSS from being cached separately, and provides diminishing returns. The recommended approach is to inline only the styles needed for the initial viewport, then load the full stylesheet asynchronously so it is ready for subsequent interactions and page loads.
Conclusion
The critical rendering path is the sequence of events between a browser request and the first painted pixels on screen. Shortening this path requires removing or deferring render-blocking resources, inlining critical CSS, compressing assets, and ensuring your server responds quickly. Each improvement reduces the time users spend waiting and has a measurable impact on Core Web Vitals scores. Even modest gains in path efficiency translate directly into a faster, more responsive experience for real users. See also browser rendering, DOM, and lazy loading to continue building your performance toolkit.