{"id":1104,"date":"2025-04-15T17:47:15","date_gmt":"2025-04-15T09:47:15","guid":{"rendered":"https:\/\/cloudnewoffer.com\/?p=1104"},"modified":"2025-04-15T17:47:15","modified_gmt":"2025-04-15T09:47:15","slug":"how-to-eliminate-render-blocking-resources","status":"publish","type":"post","link":"https:\/\/cloudnewoffer.com\/?p=1104","title":{"rendered":"How To Eliminate Render-blocking Resources"},"content":{"rendered":"
\n
\n
\n

Development<\/p>\n

\u2022<\/span><\/p>\n

Speed<\/p>\n

\u2022<\/span><\/p>\n

WordPress<\/p>\n

\u2022<\/span><\/div>\n

How To Eliminate Render-blocking Resources<\/h1>\n

\n Mar 20, 2025
\n <\/span>\u2022<\/span>
\n 8 min read <\/span>\u2022<\/span>Aleksandar Kolev<\/span><\/div>\n<\/div>\n
\"Why<\/div>\n
\n
    \n
  • \n
    \n

    \n Table of Contents <\/p>\n<\/div>\n

    \n
      \n
    • What are Render-Blocking Resources?<\/li>\n
    • Why Should You Eliminate Render-Blocking Resources?<\/li>\n
    • How To Identify Render-Blocking Resources on Your Website?<\/li>\n
    • How To Eliminate Render-Blocking Resources<\/li>\n
    • How to Reduce Render-Blocking Resources in WordPress with SiteGround Speed Optimizer<\/li>\n
    • Checklist for Eliminating Render-Blocking Resources<\/li>\n<\/ul>\n<\/div>\n<\/li>\n<\/ul>\n<\/div>\n
      \n

      This article was originally written and published on March 28th, 2022, by Cal Evans. It has been updated on March 20th, 2025, to reflect the latest developments in techniques for eliminating render-blocking resources. <\/p>\n<\/div>\n

      In the early days of the web, the first web pages were built in a simplified version of XML called HTML. White with black text. If you saw a phrase with a blue underline you knew you could click it. If it was purple you knew you had already clicked it.<\/p>\n

      Life was simple.<\/p>\n

      These days the HTML is usually the smallest part of any web page. When a browser requests a page, it gets the HTML but then has to part it and download the resources.<\/p>\n

        \n
      • CSS<\/li>\n
      • JavaScript<\/li>\n
      • Images<\/li>\n
      • Fonts<\/li>\n
      • \u2026and other external files needed to provide the user experience<\/li>\n<\/ul>\n

        Not all resources are created equal. Some resources that have to be loaded can actually slow down the display of the web page. <\/p>\n

        These resources are called \u201cRender Blocking Resources\u201d<\/strong> and this article will show you a few tactics you can use to reduce the number of render blocking resources on your website<\/strong> and how to apply them manually or using the SiteGround Speed Optimizer plugin.<\/p>\n

        What are Render-Blocking Resources?<\/strong><\/strong><\/h2>\n

        \u201cRender\u201d is the technical term for \u201cdisplay\u201d. In this article, whenever we talk about rendering, we mean the process of displaying your website on a screen.\u00a0<\/p>\n

        Every resource that is loaded into your website has the potential to be a render blocking resource. This includes:<\/p>\n

          \n
        • Large images<\/li>\n
        • JavaScript code that has to execute in the <head> of your page<\/li>\n
        • Large CSS that your page can\u2019t display until it is all loaded<\/li>\n
        • Any resource from another site that is slower than yours<\/li>\n
        • Plugins that each have their own CSS and JavaScript files<\/li>\n<\/ul>\n

          In short, anything that you have in your HTML to be loaded is potentially a render-blocking resource.<\/strong><\/p>\n

          Why Should You Eliminate Render-Blocking Resources?<\/strong><\/strong><\/h2>\n

          When a visitor lands on your website, their browser wants to show them the page as quickly as possible. But if there are too many render-blocking resources, the browser has to hit the brakes and wait for those files to download and process before showing anything useful.<\/p>\n

          This creates what we call a \u201cslow first paint\u201d \u2013 that awkward pause where users stare at a blank or half-loaded page. Not ideal, right?<\/p>\n

          Here\u2019s why it matters:<\/p>\n

            \n
          • Better User Experience<\/strong> \u2013 Fast-loading pages feel smooth and polished. A slow-loading page, on the other hand, can frustrate visitors and make them leave before they even see your content.<\/li>\n
          • Improved <\/strong>SEO<\/strong> \u2013 Google and other search engines consider page speed as a primary ranking factor. If your pages are slow because of render-blocking resources, it will hurt your position in search results.<\/li>\n
          • Higher Conversions<\/strong> \u2013 Whether you\u2019re running an online store, a blog, or a portfolio site, faster-loading pages often mean higher conversion rates. A snappy page helps keep people engaged.<\/li>\n
          • More Efficient Use of Resources<\/strong> \u2013 Eliminating unnecessary or poorly optimized assets reduces bandwidth usage and server load, which can save you money and reduce strain on your hosting environment.<\/li>\n<\/ul>\n

            .post-page__colored-blocks.post-page__colored-blocks–update p {
            \n margin: 15px 0px;
            \n}<\/p>\n

            \n

            With Interaction to Next Paint (INP)<\/strong> replacing First Input Delay (FID)<\/strong> as a core web vitals<\/strong> metric, it\u2019s even more important to reduce render-blocking resources.\u00a0<\/p>\n

            Optimizing how quickly users can interact with your page will not only improve perceived performance but also positively impact your web vitals score.<\/p>\n<\/div>\n

            At the end of the day, your website\u2019s goal is to communicate something quickly and clearly. Render-blocking resources get in the way of that by delaying when visitors can actually start interacting with your content.<\/p>\n

            Now that you know the \u201cwhy,\u201d let\u2019s dig into how to spot these slowpokes and streamline your website\u2019s loading process.<\/p>\n

            How To Identify Render-Blocking Resources on Your Website?<\/strong><\/strong><\/h2>\n

            There are plenty of tools to help you see how your website loads. We suggest these options for identifying render-blocking resources:<\/p>\n

            Using Browser DevTools<\/strong><\/h3>\n

            This is one of the tools that can show you a \u201cwaterfall\u201d view of how a page loads. All modern browsers include this feature.<\/p>\n

            Right-click anywhere on your webpage, select \u201cInspect\u201d<\/strong>, then head to the \u201cNetwork\u201d<\/strong> tab.<\/p>\n

            Reload the page, and you\u2019ll see something like this:<\/p>\n

            \"Inspect<\/figure>\n

            On the right side, you\u2019ll spot the waterfall chart. The colored bars show how long each resource takes to load. The thin blue line marks when the page starts rendering.<\/p>\n

            If you notice a lot of resources loading before that line, it could mean there\u2019s room for improvement.\u00a0<\/p>\n

            This built-in view is great for quick checks, but it only tells you how the page performs on your current setup. If you\u2019re developing locally, results might be faster than real-world conditions.<\/p>\n

            For deeper insights, you can turn to online tools like WebPageTest.<\/p>\n

            WebPageTest & Other Performance Testing Tools<\/strong><\/strong><\/h3>\n

            WebPageTest gives you a clearer picture of how your site performs globally. Plus, you can customize tests to match real-world conditions.<\/p>\n

            \n

            Pro tip<\/strong>: If you want a quicker overview, tools like PageSpeed Insights<\/strong> also flag render-blocking resources.<\/p>\n<\/div>\n

            The typical method is:<\/p>\n

              \n
            • Start with a desktop test<\/li>\n
            • Pick a server location that\u2019s distant from your website\u2019s host<\/li>\n
            • Stick with Chrome unless you have a reason to choose another browser<\/li>\n<\/ul>\n

              You can adjust these under the \u201cAdvanced Configuration\u201d<\/strong> tab.<\/p>\n

              \"WebpageTest<\/figure>\n

              Hit \u201cStart Test\u201d<\/strong> and review the results.<\/p>\n

              \"WebPageTest<\/figure>\n

              You\u2019ll now see a more detailed waterfall chart. Clicking it opens a full-sized version where you can spot render-blocking JavaScript and CSS files.<\/p>\n

              \"waterfall<\/figure>\n

              In this example, there are 32 render-blocking resources\u2014mostly CSS files, with a few JavaScript files mixed in.<\/p>\n

              It\u2019s easy to see why JavaScript can block rendering, but CSS can do the same. The browser can\u2019t fully display the page until it has all the styles it needs. If an important CSS rule loads late, your page might pause until it\u2019s ready.<\/p>\n

              This is why streamlining CSS and JS delivery is key, and exactly what we\u2019ll cover next.<\/p>\n

              How To Eliminate Render-Blocking Resources<\/strong><\/strong><\/h2>\n

              Over time, web developers have experimented with various methods to reduce or eliminate render-blocking resources. Today, there are several reliable techniques you can use to speed up page rendering.<\/p>\n

              1. Optimizing JavaScript Loading<\/strong><\/strong><\/h3>\n

              JavaScript is one of the most common culprits when it comes to render-blocking. Luckily, there are several techniques to control how and when your scripts load, so your page can display faster.<\/p>\n

              1.1. Understanding Async vs. Defer<\/strong><\/h4>\n

              To prevent JavaScript files from blocking page rendering, you should use the DEFER<\/em><\/strong> or ASYNC<\/em><\/strong> attributes in your script tags.<\/p>\n

              <script defer src=\"https:\/\/example.com\/script.js\"><\/script><\/code><\/pre>\n
                \n
              • DEFER<\/strong> downloads the script while the page is rendering and executes it only after the HTML is fully parsed. It preserves the order of scripts.<\/li>\n
              • ASYNC<\/strong> downloads and executes the script as soon as it\u2019s ready, regardless of the page\u2019s rendering state. This can cause scripts to execute out of order.<\/li>\n<\/ul>\n
                Generally, DEFER<\/strong> is the better choice, especially when your scripts depend on each other or on the DOM. It allows the browser to focus on painting the page before running scripts.<\/p>\n
                1.2. Handling Third-Party Scripts Efficiently<\/strong><\/h4>\n
                Third-party scripts, like analytics or social sharing widgets, are common render-blockers. If possible, load these scripts using DEFER<\/strong> or ASYNC<\/strong>.\u00a0<\/p>\n
                Some non-essential third-party scripts can also be moved to load after the page has finished rendering entirely, using event listeners like window.onload<\/em>.<\/p>\n
                1.3. Lazy Loading Non-Critical Scripts with IntersectionObserver<\/strong><\/h4>\n
                For scripts that are only needed once a user interacts or scrolls to a certain section (e.g., chat widgets or embedded videos), you can lazy-load them using the IntersectionObserver API.\u00a0<\/p>\n
                const observer = new IntersectionObserver((entries) => {\n  if (entries[0].isIntersecting) {\n    \/\/ Dynamically load script here\n  }\n});\nobserver.observe(document.querySelector('#lazy-element'));<\/code><\/pre>\n
                This tells the browser to load these scripts only when the related elements come into view, reducing the upfront workload for the browser.<\/p>\n
                2. Optimizing CSS for Faster Rendering<\/strong><\/strong><\/h3>\n
                CSS tells your browser how to style your page, but it can also slow down how fast that page shows up. Let\u2019s look at how to make your CSS work with you\u2014not against you\u2014when it comes to performance.<\/p>\n
                2.1. Inlining Critical CSS for Above-the-Fold Content<\/strong><\/h4>\n
                Browsers block rendering until they\u2019ve processed CSS. To speed up the first paint, Google suggests identifying your \u201ccritical CSS<\/strong>\u201d (the styles needed for the above-the-fold content) and inlining them directly into your HTML.<\/p>\n
                <style>\/* Critical CSS goes here *\/<\/style><\/code><\/pre>\n
                This eliminates the need for the browser to wait for external stylesheets before displaying content above the fold.\u00a0<\/p>\n
                The easiest way to identify and inline critical CSS is by using tools like the Chrome Coverage Tool to see what styles load during initial rendering.<\/p>\n
                \"Chrome<\/figure>\n
                It will show you the CSS that you are loading that is non-critical (red bar) and critical (green bar).<\/p>\n
                By pulling the critical CSS out and placing it inline, you can remove the CSS as a render-blocking resource.<\/p>\n
                2.2. Deferring Non-Critical CSS<\/strong><\/h4>\n
                For non-essential styles, such as those affecting the footer or elements below the fold, you can defer loading by using the media attribute with a value like print and switching it back to all after the page loads:<\/p>\n
                <link rel=\"stylesheet\" href=\"non-critical.css\" media=\"print\" onload=\"this.media='all'\"><\/code><\/pre>\n
                This trick allows the browser to prioritize critical resources and load the rest after the page is visually complete.<\/p>\n
                2.3. Preloading Key CSS Files<\/strong><\/h4>\n
                Another tactic is preloading CSS files you know are crucial but don\u2019t want to inline. Preloading helps the browser discover these resources earlier in the rendering process:<\/p>\n
                <link rel=\"preload\" href=\"important.css\" as=\"style\" onload=\"this.rel='stylesheet'\"><\/code><\/pre>\n
                It\u2019s useful for important stylesheets that impact the look and feel of above-the-fold content but are too large or complex to inline.<\/p>\n
                3. Progressive Rendering Techniques<\/strong><\/h3>\n
                Beyond scripts and stylesheets, there are some additional strategies you can use to progressively load content and speed up your website\u2019s first paint.<\/p>\n
                3.1. Server-Side Rendering (SSR) and Static Generation<\/strong><\/h4>\n
                Server-Side Rendering (SSR) and static generation can help deliver fully-formed HTML to the browser, reducing the reliance on client-side scripts for initial rendering.\u00a0<\/p>\n
                This means content becomes visible sooner because the browser doesn\u2019t have to wait for JavaScript to build the page structure.<\/p>\n
                Frameworks like Next.js or Gatsby make SSR and static generation easier to implement.<\/p>\n
                3.2. Optimizing Fonts and Images to Improve Load Times<\/strong><\/h4>\n
                Fonts and images can also block rendering if not handled correctly. To optimize them:<\/p>\n
                  \n
                • Use the font-display: swap CSS property to prevent font files from blocking the first paint.<\/li>\n
                • Lazy-load images below the fold using the loading=\u201dlazy\u201d<\/em> attribute.<\/li>\n
                • Preload key fonts or hero images with the <link rel=\u201dpreload\u201d><\/em> tag to prioritize them.<\/li>\n<\/ul>\n
                  Together, these strategies improve your site\u2019s performance by letting browsers display content as early as possible while loading non-essential assets in the background.<\/p>\n
                  How to Reduce Render-Blocking Resources in WordPress with SiteGround Speed Optimizer<\/strong><\/h2>\n
                  If you\u2019re using WordPress, the SiteGround Speed Optimizer<\/strong> plugin offers an easy way to reduce render-blocking resources without touching your code.<\/p>\n
                  Even if you don\u2019t host with SiteGround, this plugin can still help optimize your website\u2019s performance.<\/p>\n
                   .post-page__colored-blocks.post-page__colored-blocks–update p {
                  \n    margin: 15px 0px;
                  \n}<\/p>\n
                  \n
                  Warning<\/strong>:\u00a0<\/p>\n
                  When making these changes, it\u2019s important to proceed carefully. We recommend adjusting one setting at a time and then checking your site in a different browser to make sure everything is still working correctly.\u00a0<\/p>\n
                  This way, you can identify any potential issues and fix them immediately before moving on to the next optimization.<\/p>\n<\/div>\n
                  1. Optimizing JavaScript<\/strong><\/h3>\n
                  First, go to the JavaScript<\/strong> settings in the plugin. Here are the key optimizations:<\/p>\n
                  \"Screenshot<\/figure>\n
                    \n
                  • Minify JavaScript Files:<\/strong> This removes unnecessary characters from your JavaScript code. This makes it smaller and faster to load.<\/li>\n
                  • Combine JavaScript Files:<\/strong> Combining JavaScript files reduces the number of requests the browser needs to make, speeding up the load time.<\/li>\n
                  • Defer Render-blocking JavaScript:<\/strong> This important option adds the DEFER attribute to your JavaScript files, allowing the page to render before executing JavaScript.<\/li>\n<\/ul>\n
                    2. Optimizing CSS<\/strong><\/h3>\n
                    Next, head to the CSS<\/strong> settings:<\/p>\n
                    \"Screenshot<\/figure>\n
                      \n
                    • Preload Combined CSS:<\/strong> This setting makes sure that your combined CSS file is loaded early in the process, so it\u2019s available when the page starts rendering.<\/li>\n
                    • Minify CSS Files:<\/strong> This removes spaces, new lines, and comments from your CSS, shrinking the file size and improving load times.<\/li>\n
                    • Combine CSS Files:<\/strong> Combining CSS files helps reduce render-blocking by lowering the number of HTTP requests.<\/li>\n<\/ul>\n
                      By applying these optimizations, you can significantly reduce render-blocking resources on your WordPress site and make it faster.<\/p>\n
                      \n
                      If you want to dive deeper into WordPress optimizations, check out our video on How to Speed up Your WordPress Website Like a Pro.<\/strong><\/p>\n<\/div>\n\n
                      After going through all these steps on our test site, we are down to 24 render-blocking resources from 32. That\u2019s a really good start.<\/p>\n
                      \"\"<\/figure>\n
                      The next step is to locate all critical CSS and in-line it. Then defer all other CSS and apply the other optimization techniques we discussed above. That will remove almost all of the remaining render-blockers.\u00a0<\/strong><\/p>\n
                      Now, let\u2019s go over a final checklist of all the techniques we\u2019ve explored.<\/p>\n
                      Checklist for Eliminating Render-Blocking Resources<\/strong><\/h2>\n
                      By now, you\u2019ve learned that render-blocking resources don\u2019t just slow things down\u2014they can directly impact user experience, SEO, and conversions.\u00a0<\/p>\n
                      To help you put everything into action, here\u2019s a checklist you can follow:<\/p>\n
                        \n
                      • \u2705 Identify render-blocking resources using browser DevTools or tools like WebPageTest.<\/li>\n
                      • \u2705 Add defer<\/strong> or async<\/strong> attributes to non-critical JavaScript files.<\/li>\n
                      • \u2705 Optimize third-party scripts by loading them asynchronously or deferring them when possible.<\/li>\n
                      • \u2705 Use IntersectionObserver<\/strong> to lazy load scripts that aren\u2019t needed immediately.<\/li>\n
                      • \u2705 Inline your critical CSS (above-the-fold styles) directly into your HTML.<\/li>\n
                      • \u2705 Defer non-critical CSS or load it asynchronously, and remove unused CSS.<\/li>\n
                      • \u2705 Preload important CSS files to give the browser a head start.<\/li>\n
                      • \u2705 Implement progressive rendering techniques like Server-Side Rendering (SSR) or static generation where it makes sense.<\/li>\n
                      • \u2705 Optimize fonts and images to remove hidden bottlenecks.<\/li>\n
                      • \u2705 Use performance optimization plugins like the SiteGround Speed Optimizer to automate many of these tasks easily.<\/li>\n<\/ul>\n
                        Eliminating render-blocking resources may feel like fine-tuning. Each of these steps chips away at those frustrating pauses during page loads. Apply them consistently, and you\u2019ll create a faster, smoother experience for your visitors.<\/p>\n
                        From improving user experience to boosting SEO, every optimization counts. When your pages load quickly, visitors stick around longer and search engines take notice of that.\u00a0<\/p>\n
                        The best part? With \u0430 tool like the SiteGround Speed Optimizer, you can automate a lot of these steps and get faster results without much hassle and coding knowledge.<\/p>\n
                        In the long run, every little improvement adds up\u2014and that\u2019s what keeps your website fast, reliable, and ready to perform.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
                        Development \u2022 Speed \u2022 WordPress \u2022 How To Eliminate Render-blocking Resources Mar 20, 2025 \u2022 8 min read \u2022Aleksandar Kolev Table of Contents What are Render-Blocking Resources? Why Should You Eliminate Render-Blocking Resources? How To Identify Render-Blocking Resources on Your Website? How To Eliminate Render-Blocking Resources How to Reduce Render-Blocking Resources in WordPress with SiteGround …<\/p>\n","protected":false},"author":1,"featured_media":1105,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[31,32,33],"class_list":["post-1104","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-message","tag-development","tag-speed","tag-wordpress"],"_links":{"self":[{"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=\/wp\/v2\/posts\/1104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1104"}],"version-history":[{"count":0,"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=\/wp\/v2\/posts\/1104\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=\/wp\/v2\/media\/1105"}],"wp:attachment":[{"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudnewoffer.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}