Eliminate Render-Blocking CSS with W3 Total Cache Pro (original) (raw)

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.

Speed Up Your WordPress Website.

A Difference of Just 100ms in Page Load Speeds Can Cause a Visitor to Prefer Your Competitor’s Website.

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.

Let’s take a look at what render-blocking CSS may cause your website to look like on a slow web connection. Here are two images of the WordPress Dashboard, one without CSS, and one with CSS:
wordpress dashboard loaded without css styles appliedwordpress dashboard with css styles loaded correctly.

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.

-94.86% Potential Savings
from Render Blocking
Resources

In one of our newest PageSpeed Experiments, moving our CSS to the HTTP body reduced our Potential Savings From Render-Blocking Resources by over 94% loading nearly 2 seconds faster on mobile devices! Check out our test results to see how we did it!

Upgrade to W3 Total Cache Pro and improve your PageSpeed Scores today!

  1. Navigate to the Performance — General Settings menu and enable Minify. Try Automatic mode first.
    minify control enabled in the w3 total cache general settings
  2. 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
    css minification enabled along with the eliminate render blocking css control under the minify controls section.

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.

  1. First, disable the setting and purge all caches
    eliminate render-blocking css control disabled. save settings and purge cache button highlighted.
  2. 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.
    css filter selected under the network tab in the browser developer tools. only css files are listed.
  3. 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.
    css filter selected in the developer network tab. no css files are shown in the list.
  4. Switch over to the Elements tab of your developer tools, and note that all of your stylesheets have been minified and added to the element of your DOM.
    page source html view showing all of the css style files loaded in the website head section.

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.

  1. Examine your site’s source HTML, and perform a CTRL-F search for all instances of the string rel=“stylesheet”.
  2. 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.
  3. Navigate to the Minify settings menu, and add each stylesheet that applies to all media to the list of minified files.
  4. 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.

-56.59% LCP Score

In one of our recent tests, Eliminating render blocking CSS improved our Largest Contentful Paint time by over 56% loading nearly 4 seconds faster on mobile devices! Check out the results to see how we did it!

Upgrade to W3 Total Cache Pro and improve your PageSpeed Scores today!

FAQ

What are resources?

In the context of web development, “resources” refer to the various components needed to load and display a web page properly. These include HTML, CSS, and JavaScript files, as well as images, videos, fonts, and other media or data files. Each resource is fetched from the server and processed by the browser to render the web page as intended by its design.

How does a browser “render” a web page?

The browser rendering process involves several detailed steps:

  1. 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.
  2. 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.
  3. Render Tree Construction: The browser combines the DOM and CSSOM to create the render tree, which includes only visible page elements and their styles.
  4. 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.
  5. Painting: The browser fills in pixels for the elements, applying text, colors, images, etc., according to the render tree.
  6. 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).

During this process, the browser identifies all the elements, attributes, and text within the HTML file, creating a tree-like structure that represents the hierarchy and organization of the webpage. This structured representation allows the browser to render the page visually and enables JavaScript to interact with the page’s content through the DOM API.

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?

“Render-blocking resources” refers to elements, typically CSS and JavaScript files, that must be loaded before a web page can be displayed to the user.

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?

Other resources, like images or fonts, do not block HTML parsing but can affect the speed at which a page becomes visually complete. While images and fonts are critical for visual rendering, they are typically not considered render-blocking in the same sense as CSS and JavaScript because the browser can continue parsing and laying out the page while these resources are being loaded. The primary concern with render-blocking revolves around CSS and JavaScript, which must be processed before the page can render and become interactive.

What is the opposite of render-blocking?

The opposite of “render-blocking” is often referred to as “non-blocking” or “asynchronous” loading. This approach involves loading resources such as JavaScript or CSS in a way that does not interfere with the initial rendering of the page. Techniques include using the async and defer attributes for scripts, which allow the browser to continue parsing and rendering the HTML while scripts are being downloaded in the background, thereby improving page load times and user experience.

How can css and styles be made non-blocking?

CSS and styles can be made non-blocking through several techniques:

  1. 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.
  2. 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.
  3. Load CSS Asynchronously: Use JavaScript to load CSS files asynchronously. This can be done by dynamically creating a <link> element in the DOM via JavaScript or using libraries that facilitate asynchronous loading.
  4. Use 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?

JavaScript and scripts can be made non-blocking through several methods to improve page load times:

  1. Use the async Attribute: Adding async to 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.
  2. Use the defer Attribute: The defer attribute (<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.
  3. Dynamically Load Scripts: JavaScript can be used to dynamically load other scripts on demand. This involves creating <script> elements via JavaScript and appending them to the DOM, which allows for more control over when and how scripts are loaded and executed.
  4. Move Scripts to the Bottom: Although less effective than async or defer, moving <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.

Each of these methods can help minimize the performance impact of JavaScript, making web pages faster and more responsive.

What is the difference between Async and Defer?

The async and defer attributes are used in