In this article:
- Why Do I Need to Eliminate Render-Blocking CSS?
- What is “Moving to the HTTP Body?”
- How do I Eliminate Render-Blocking CSS with W3 Total Cache Pro?
- How Do I Tell If It’s Working?
- How Do I Make It Even Faster?
- What Types of Stylesheets Are Actually Render-Blocking?
- What are resources?
- How does a browser “render” a web page?
- What does it mean when an html document has been fully parsed?
- What are render-blocking resources?
- What is an example of a render-blocking resource?
- Are only scripts and styles render blocking?
- What is the opposite of render-blocking?
- How can css and styles be made non-blocking?
- How can JS and Scripts Be Made Non-Blocking?
- What is the difference between Async and Defer?
- What types of scripts should be render-blocking?
- What types of scripts should load async?
- What types of scripts should load with defer?
- Can CSS use Async or Defer?
- async and defer vs. placement of scripts in the head and body
- What does it mean when a web page is interactive?
- What happens if a user tries to interact with a page that hasn’t rendered?
There are two major things that must load before your website can be “rendered,” the Document Object Model (DOM) and the CSSOM (Cascading Style Sheet Object Model).
The DOM contains all of the markups for your website, and the CSSOM contains all of the styling to display it correctly.
In WordPress, most CSS files, or stylesheets, are loaded as separate files as enqueued by your theme, plugins, and other site assets, and this leads to numerous network requests that are considered “render-blocking.” In this guide, you’ll learn how to eliminate render-blocking CSS by moving it to the HTML body with W3 Total Cache Pro.
Why Do I Need to Eliminate Render-Blocking CSS?
If a site’s markup is loaded without CSS, it can cause a “Flash of Unstyled Content,” (FOUC) which will contribute to the Cumulative Layout Shift (CLS) Core Web Vital metric. It may also lead to longer First Contentful Paint (FCP) metrics, and overall cause a poorer user experience and Core Web Vitals score.
On a slower connection, a user might briefly see the first image, and only see the styled content after the stylesheets load.
What is “Moving to the HTTP Body?”
When you use W3 Total Cache Pro to eliminate render-blocking CSS, your stylesheets are first minified, then combined, and finally inserted into the top of the DOM as an inline style, rather than a separate network request.
This means that your visitors will receive all of the necessary styles at the same time that they receive the rest of your site’s markup, and therefore eliminate any Layout Shift caused by CSS and further delays in rendering the First Contentful Paint.
How do I Eliminate Render-Blocking CSS with W3 Total Cache Pro?
- Navigate to the Performance — General Settings menu and enable Minify. Try Automatic mode first.
- Navigate to the Minify settings menu, and scroll down to the CSS section. Ensure that minify is enabled, and select Eliminate render-blocking CSS by moving it to HTTP body
That’s it! Your CSS stylesheets will now be automatically minified and moved to the top of your main DOM (HTTP Body).
How Do I Tell If It’s Working?
Most of the time, you’ll be able to tell simply by running Google’s PageSpeed Insights tool, or by running the Lighthouse tool in your browser’s developer tools. However, if you’d like to check out how it works under the hood, follow these steps.
- First, disable the setting and purge all caches
- Load your site in an Incognito, or Private Browsing Window and open your browser’s developer tools, and check out the Network tab. In Chrome, the shortcut for this is Ctrl-Shift-i. In Firefox, use Ctrl-Shift-e. For simplification, use the CSS filter to show only the relevant requests. Take note of the various minified CSS files you can see.
- Go back to your Dashboard, and re-enable the option to eliminate render-blocking css in the Minify settings menu, then reload your site in the private browsing window. (Hint: delete the network requests history with the Clear button). Note that there are no longer any separate network requests for stylesheets.
- Switch over to the Elements tab of your developer tools, and note that all of your stylesheets have been minified and added to the <head> element of your DOM.
How Do I Make It Even Faster?
Eliminating render-blocking CSS via the automatic method will almost always improve your PageSpeed Insights score, but you may choose to optimize even further. The following steps will take some development skills, but you should feel encouraged to dive deeper to get even better results.
What Types of Stylesheets Are Actually Render-Blocking?
Stylesheets are only considered Render-Blocking if they apply to All Media Types. By using Auto-Minify, you’ll be minifying and combining all of your stylesheets into the HTTP Body. This may have a negative impact on sites with a lot of plugins, or complicated themes, because the DOM request filesize may become larger than ideal.
Instead, you may choose to use Manual Minify mode to further optimize your CSS. Using manual, you can select the specific files to combine, minify, and move to the HTTP body.
- Examine your site’s source HTML, and perform a CTRL-F search for all instances of the string rel=“stylesheet”.
- Using this search, locate any stylesheets that do not specify a media type, or use media=“all” . These are the stylesheets that are considered render-blocking.
- Navigate to the Minify settings menu, and add each stylesheet that applies to all media to the list of minified files.
- Save your settings, check that your site renders correctly, and perform a new PageSpeed Insights report to ensure that you didn’t miss any render-blocking stylesheets.
What are resources?
How does a browser “render” a web page?
The browser rendering process involves several detailed steps:
Parsing HTML to Build the DOM: The browser reads the HTML code and creates the DOM (Document Object Model), a tree-like structure representing all page elements.
Creating the CSSOM: For every CSS style encountered (inline, embedded, or external), the browser constructs the CSS Object Model (CSSOM), detailing how elements should be styled.
Render Tree Construction: The browser combines the DOM and CSSOM to create the render tree, which includes only visible page elements and their styles.
Layout (Reflow): The browser calculates the position and size of each element within the viewport, considering the current window size and the computed styles for each element.
Painting: The browser fills in pixels for the elements, applying text, colors, images, etc., according to the render tree.
Compositing: The browser draws elements onto the screen in the correct order, ensuring that elements that overlap are displayed properly.
This complex process transforms the code into the visual and interactive experience users see on their screens.
To learn more, we recommend starting out with Critical rendering path.
What does it mean when an html document has been fully parsed?
When an HTML document has been fully parsed, it means that the browser has read through the entire HTML code, converting it into a structured, in-memory representation known as the Document Object Model (DOM).
A fully parsed document is ready for further processing, including the execution of scripts that were deferred (using the
defer attribute) until this point, ensuring they interact with a fully constructed DOM.
What are render-blocking resources?
These resources are considered “blocking” because browsers must pause the rendering of the page until these files are fully downloaded and processed. This can significantly delay the time it takes for a page to become visible and interactive, affecting user experience and potentially impacting a site’s performance metrics and search engine rankings.
What is an example of a render-blocking resource?
A common example of a render-blocking resource is a CSS file linked in the HTML head. For instance, if a website’s HTML includes a link to a stylesheet like:
<link href="styles.css" rel="stylesheet">
… the browser must download and process this CSS file before it can render the page content. This means the site won’t be visible to the user until “styles.css” is fully loaded, potentially delaying how quickly the page can be displayed.
Are only scripts and styles render blocking?
What is the opposite of render-blocking?
How can css and styles be made non-blocking?
CSS and styles can be made non-blocking through several techniques:
Use Media Queries: Specify media types or queries on
<link>elements to load stylesheets conditionally, ensuring they are only loaded when needed. For example, print stylesheets don’t need to block rendering of the page on screen.
Critical CSS: Inline the critical CSS directly in the HTML document. This is the minimal set of styles needed to render the above-the-fold content, allowing the page to display content quickly before additional styles are loaded.
rel="preload": Mark non-critical CSS files with
rel="preload"as a hint to the browser that these resources are important but do not need to block rendering. They can be downloaded asynchronously and applied once loaded.
Implementing these strategies helps improve the rendering performance of web pages by reducing the impact of CSS files on the critical rendering path.
How can JS and Scripts Be Made Non-Blocking?
asyncto a script tag (
<script async src="...">) allows the script to be downloaded in the background. The browser can continue parsing and rendering the HTML page while the script is being fetched. The script will be executed as soon as it’s downloaded, without waiting for the parsing to complete.
<script defer src="...">) also allows the script to be downloaded asynchronously, but it guarantees that scripts execute in the order they appear in the document and only after the document has been fully parsed. This is particularly useful for scripts that rely on the entire DOM being available.
Move Scripts to the Bottom: Although less effective than
<script>tags to the bottom of the HTML body ensures that the browser can render the rest of the HTML page before it needs to load and execute the scripts. This can improve the time to first render, even though it’s a more dated technique.
What is the difference between Async and Defer?
- When you add async to a script tag, the script is downloaded in the background while the browser continues to parse and render the HTML document.
- Scripts with async are executed as soon as they are downloaded, which means they might run in a different order from how they appear in the HTML. This can lead to problems if the scripts depend on each other.
- async is best used for scripts that do not depend on other scripts and do not modify the DOM immediately upon loading.
<script async src="analytics.js"></script>
This script can be loaded and executed asynchronously without affecting the page’s initial rendering or depending on other scripts.
- Scripts with defer are also downloaded in the background, but they are executed only after the HTML document has been fully parsed.
- defer scripts are executed in the order they appear in the document, making them suitable for scripts that depend on each other or rely on the full HTML document being parsed.
- Use defer for scripts that need the entire DOM but should not block the page from rendering.
<script defer src="app.js"></script>
This script will be executed after the HTML document is parsed, preserving execution order without blocking the initial page render.
- Execution Order: async scripts execute as soon as they’re downloaded, which could be out of order, while defer scripts maintain their order relative to each other and execute after the document is parsed.
- Use Cases: Use async for independent, non-DOM reliant scripts like analytics. Use defer for scripts that need the whole DOM or rely on the execution order.
Choosing between async and defer depends on the specific needs of your scripts and how they interact with the rest of your page.
What types of scripts should be render-blocking?
The goal is typically to avoid render-blocking scripts wherever possible to improve page load times and user experience. However, there are scenarios where scripts might be intentionally made render-blocking due to their critical importance to the page. Here are examples where scripts might be considered necessary to be render-blocking, though modern best practices often aim to minimize these cases:
Early-Stage Feature Detection: Scripts that perform feature detection for older browsers to conditionally load polyfills or alternate stylesheets. These need to run before the rest of the page to ensure compatibility.
Security or Compliance Scripts: Certain scripts related to security, compliance, or cookie consent that must run before any other content is loaded or interacted with by the user.
Minimal, Early UI Setup: Scripts that set up a minimal user interface or critical path CSS before the rest of the page loads. This could be part of a strategy to enhance perceived performance, where a minimal layout is shown to the user as quickly as possible.
While these examples can be situations where scripts are render-blocking by necessity or design choice, the overarching trend in web development is to find strategies that mitigate the need for render-blocking resources.
What types of scripts should load async?
Analytics Scripts: Scripts for analytics platforms (like Google Analytics) are ideal candidates for
asyncloading. They track user behavior and gather data without affecting the page’s initial rendering or functionality. Since these scripts don’t modify the DOM or depend on other scripts, they can be loaded in the background without impacting user experience.
Social Media Sharing Buttons: Many websites include social media sharing buttons that load external scripts (e.g., from Facebook or Twitter) to function. These scripts, often not critical to the primary content, can be loaded asynchronously to prevent them from blocking the page’s main content and functionality from rendering promptly.
Ad Scripts: Advertising scripts that load ads onto a page are perfect for asynchronous loading. Ads are typically not essential to a webpage’s main content, so loading these scripts asynchronously ensures that they do not slow down the access to the content that users came for.
Third-Party Widgets: Widgets from third-party services, such as weather updates, news tickers, or chatbots, should be loaded asynchronously. These elements offer supplementary information or features and should not delay the loading of the core content and functionality of the page.
What types of scripts should load with defer?
defer. This ensures that the entire HTML document is parsed before these critical scripts are executed, maintaining script execution order without blocking the initial rendering.
Document Manipulation Scripts: Scripts that modify the DOM or initialize the UI, assuming they are not needed immediately as the page starts to load, are best loaded with
defer. This ensures that the entire page is available for manipulation once the script runs, preventing errors that could occur if the script tries to modify elements not yet loaded.
Web Application Bootstrap Scripts: For single-page applications (SPAs) or any web application that initializes from a script, using
deferensures that the app’s bootstrap code executes only after the HTML is fully parsed. This is crucial for applications that rely on a complete DOM for initialization.
Custom Analytics or Tracking Scripts: Unlike third-party analytics that can be loaded asynchronously, custom-built analytics or tracking scripts that depend on a fully loaded DOM or need to ensure accurate pageview hits after the page is fully loaded should use
defer. This ensures the tracking code executes in the correct order and context.
Lazy-Loaded Component Scripts: If your site dynamically loads components based on user interaction but these components are not immediately necessary, you can initially load the scripts with
defer. Once the page is fully loaded, these deferred scripts can then take care of loading additional components as needed, ensuring a smooth user experience without compromising initial load performance.
defer for these types of scripts ensures that they are executed in the correct order and only after the HTML document has been fully parsed, facilitating a faster page load time while still enabling complex functionalities and interactions on the webpage.
Can CSS use Async or Defer?
defer attributes are specifically for
<script> tags in HTML and cannot be directly applied to CSS. CSS has its own mechanisms for non-blocking loading, such as using media queries,
async and defer vs. placement of scripts in the head and body
Historical Context – Traditional Placement of Scripts:
- In the Head: Initially, scripts were often placed in the
- At the End of the Body: To mitigate render-blocking issues, developers started moving scripts to the bottom of the
deferattributes were introduced to give developers better control over the loading and execution of scripts without compromising page performance.
async: Allows scripts to be downloaded in the background and executed as soon as they’re downloaded, without waiting for the entire page to be parsed. This is ideal for scripts that are independent of other scripts and don’t modify the DOM immediately.
defer: Enables scripts to be downloaded in parallel with HTML parsing but delays script execution until after the HTML document has been fully parsed. This is useful for scripts that need to interact with the entire DOM and ensures scripts execute in the order they appear in the document.
- Control Over Execution:
deferprovide more precise control over when scripts are loaded and executed relative to the parsing of the HTML document. This contrasts with the more binary choice of placing scripts in the
<head>or at the end of the
<body>, which does not offer the same level of granularity.
- Performance Optimization: By allowing scripts to be loaded asynchronously or deferred until after parsing,
- Modern Web Development Practices: The introduction of
deferreflects a broader shift towards optimizing user experience by improving site speed and interactivity. These attributes are part of modern web development best practices aimed at creating fast, responsive websites.
The evolution from simply placing scripts in specific locations within the HTML document to using
What does it mean when a web page is interactive?
When a web page is interactive, it means that users can engage with the content beyond just reading it. This includes actions like clicking buttons, filling out forms, selecting options from menus, or any other activity where the page responds to user input. An interactive page allows for a dynamic experience, offering personalized features or responses based on how the user interacts with the web elements on the page.
What happens if a user tries to interact with a page that hasn’t rendered?
W3 Total Cache
You haven't seen fast until you've tried PRO
Full Site CDN + Additional Caching Options
Advanced Caching Statistics, Purge Logs and More
Everything you need to scale your WordPress Website and improve your PageSpeed.