Clearly, there are tremendous benefits to performing this type of optimization process on your site.<\/p>\n
Why Should You Identify Render-Blocking Resources?<\/h2>\n
Identifying and reducing resources responsible for blocking the rendering of your webpage is a critical optimization point that can make or break your page speed.<\/p>\n
It can be so critical that it can pay dividends to your site\u2019s page experience metrics<\/a> (and your user\u2019s satisfaction) as a result.<\/p>\n In 2021, the average time it took to fully render a mobile webpage was 22 seconds<\/a>. In 2018, it was 15 seconds<\/a>.<\/p>\n Clearly, this is a substantially higher number than Google\u2019s recommended time of two to three seconds. It\u2019s also substantially higher than it used to be.<\/p>\n What could be causing these issues with render-blocking resources?<\/p>\n What is driving this increase in overall page render speed?<\/p>\n One interesting trend to note is that there has been an increasing reliance on third-party fonts<\/a> compared to system fonts. Using third-party fonts as a resource tends to interfere<\/a> with the processing and rendering of a page.<\/p>\n With system fonts, the browser does not have to load anything extra, so it doesn\u2019t have that additional processing step as a result.<\/p>\n This reliance across industries is likely to impact this rendering time. Of course, this is not the only cause of this issue with render-blocking resources.<\/p>\n In addition, Google\u2019s own services tend to have a significant impact on rendering time, such as Google Analytics or using a third-party Facebook pixel for tracking purposes.<\/p>\n The desire to rely on such technologies is not necessarily terrible from a marketing perspective.<\/p>\n But from a render-blocking resources perspective, it can cause significant increases in page load time and how Google (and users) perceive your page.<\/p>\n The ideal solution is to ensure your page loads for user interaction as quickly as possible.<\/p>\n It\u2019s also a possibility that poor web development practices in use by web developers today are to blame.<\/p>\n Either way, this is something in every website project that should be addressed as part of your Core Web Vitals audits<\/a>.<\/p>\n Page experience, however, is not just about how fast the entire page loads.<\/p>\n Instead, it\u2019s more about the overall experience of the page as measured by Google\u2019s page experience framework or Core Web Vitals.<\/p>\n This is why you want to work on improving and optimizing your page speed for the critical rendering path throughout the DOM<\/a> or document object model.<\/p>\n The critical rendering path<\/a> refers to all of the steps that it takes to render the entire page, from when the browser first begins receiving data to when it finally compiles the page at the final render.<\/p>\n This is a process that can take only several milliseconds if you optimize it right.<\/p>\n Optimizing for the critical rendering path means making sure that you optimize for the performance of rendering on many different devices.<\/p>\n This is accomplished by optimizing the critical rendering path to get to your first paint as quickly as possible.<\/p>\n Basically, you\u2019re reducing the amount of time users spend looking at a blank white screen to display visual content ASAP (see 0.0s below).<\/p>\n There\u2019s a whole process on how to do this, outlined in Google\u2019s developer guide documentation<\/a>, but I will be focusing on one heavy hitter in particular: reducing render-blocking resources.<\/p>\n The critical rendering path refers to the series of steps a browser takes on its journey to render a page by converting the HTML<\/a>, CSS, and JavaScript<\/a> to actual pixels on the screen.<\/p>\n Essentially, the browser needs to request, receive, and parse all HTML and CSS files (plus some additional work<\/a>) before it will start to render any visual content.<\/p>\n This process occurs within a fraction of a second (in most cases). Users will see a blank white page until the browser completes these steps.<\/p>\n The following is an example of how users may experience how a page loads according to the different stages of the page load process:<\/p>\n Improving the critical rendering path can thus improve the overall page experience, which can help improve performance on Core Web Vitals metrics.<\/p>\n To improve the critical rendering path, you must analyze your render-blocking resources.<\/p>\n Any render-blocking resources may end up blocking the initial rendering of the page and negatively impact your Core Web Vitals scores as a result.<\/p>\n This involves an optimization process of:<\/p>\n By doing this, it\u2019s possible to improve both Core Web Vitals and how your page physically renders to the user.<\/p>\n Before discussing optimization techniques you can use to optimize the critical rendering path, it\u2019s important to discuss the initial browser loading process and why the critical rendering path is so important.<\/p>\n And this process involves:<\/p>\n First, when the page is fetched by the browser from the server, the browser will initially scan and find all page elements to be downloaded. By default, this happens in a process where the browser downloads all elements simultaneously.<\/p>\n But what happens when you have many page elements to download (such as what frequently happens with a WordPress website?) Well, this can bog down server resources, which further increases the page load time.<\/p>\n How do you get around this? By using the preload link to asynchronously download critical files that are blocking the rendering of the page (discussed later on in this article).<\/p>\n Preloading elements is a technique that helps eliminate render-blocking style sheets because it loads critical files needed for the first paint stage of the process before loading all of the other files.<\/p>\n You can preload CSS, JS, Fonts, or Images. Here are examples of how to preload them:<\/p>\n JavaScript Preloading<\/strong><\/p>\n CSS Preloading<\/strong><\/p>\n Fonts Preloading<\/strong><\/p>\n Images Preload<\/strong><\/p>\n This helps speed up the process of the page. However, this is not an ideal method.<\/p>\n The ideal method is to optimize the site to only use two to three plugins, maybe two to three other files, and keep things at their bare minimum for the full page rendering.<\/p>\n Sadly, this is not a realistic endeavor to pursue.<\/p>\n Because WordPress sites do tend to have many plugins and resources that developers just aren\u2019t willing to (or want to) deal with, the easiest path to success is to work on making sure that these resources are properly optimized by using certain plugins.<\/p>\n Critical CSS is a technique that extracts the CSS<\/a> for above-the-fold content to render content to the user as fast as possible.<\/p>\n At the minimum, this usually requires:<\/p>\n Using our earlier example of the page loading all resources simultaneously, inlining critical styles involve using code within the HTML <head> tag itself.<\/p>\n If you check, for example, google.com source code, you will see it inlined critical CSS into the <head> section of the HTML.<\/p>\n There are several tools that can help to extract critical CSS.<\/p>\n By using this method, it\u2019s possible to defer the loading of JavaScript files until after other critical elements of the DOM tree are loaded. However, this comes with a few caveats.<\/p>\n Example of how to defer JavaScript file:<\/p>\n Number one is that you can negatively impact the site\u2019s appearance when deferring the loading of JavaScript files because some of these could be required elements for the page to load completely.<\/p>\n Number two is, if you\u2019re not careful, by deferring the loading of JavaScript files, you could potentially introduce issues with the page\u2019s interactivity (interaction to next paint Core Web Vitals metric).<\/p>\n Number three is that you can also introduce problems with how the site works overall.<\/p>\n The idea is that you have to be careful when you\u2019re working on these types of optimizations, so you don\u2019t inadvertently cause issues elsewhere in the process.<\/p>\n By doing so, you can greatly impact your page speed and how Google sees your site.<\/p>\n The other concern, however, is when you use plugins such as Nitro to defer critical files like CSS and JavaScript.<\/p>\n While this can have a positive impact on page speed, the major issue with this is that the plugin defers all CRITICAL files until after the page has loaded the HTML portion of the document.<\/p>\n What does this mean?<\/strong> This means that Google cannot see the entire document as it is intended to display. This is similar to blocking your CSS files and JavaScript files using robots.txt, which Google does need to determine whether your site is mobile-friendly.<\/p>\n The official Google Developer page says this, as mentioned elsewhere<\/a>:<\/p>\n \u201cFor optimal rendering and indexing, always allow Googlebot access to the JavaScript, CSS, and image files used by your website so that Googlebot can see your site like an average user.<\/p>\n If your site\u2019s robots.txt file disallows crawling of these assets, it directly harms how well our algorithms render and index your content. This can result in suboptimal rankings.\u201d<\/p>\n<\/blockquote>\n If you are deferring critical CSS and JavaScript files for SEO reasons, so long as you ensure that Google can see these files on page load, you should not run into any major issues with how Google can see your site.<\/p>\n Before we can talk about early hints, we need to discuss the process of how the server loads a webpage. Sites have indeed become more sophisticated in recent years.<\/p>\n And thus, so have servers. But, there are limitations. Even though servers can and do perform trivial tasks all day long, it\u2019s still possible for a server to become bogged down by working to overthink how it handles a site\u2019s resources.<\/p>\n So, when this happens, additional latency than otherwise would be experienced occurs \u2013 and this happens before the browser can start rendering the page.<\/p>\n When this latency occurs, you can run into situations where a site could take a couple of seconds before appearing in the browser window.<\/p>\n And making sure your server renders the files properly is an excellent first step toward increasing your page speed.<\/p>\n Here\u2019s an example of what happens when your server does not properly respond and takes too long to process certain resources:<\/p>\n So, how do early hints work?<\/p>\n According to the Google Chrome Developer guide<\/a>, \u201cearly hints are an HTTP status code (103 Early Hints) which is used to send an accurate preliminary HTTP response ahead of a final response.\u201d<\/p>\n What does this accomplish?<\/p>\n This lets a server provide certain types of hints to a browser for certain critical resources (JavaScript files, CSS style sheets, and more) that are likely to be loaded and used by the web page itself.<\/p>\n This process happens in the span of a few milliseconds or less while the server works on rendering the main page resources.<\/p>\n Early Hints are something that \u201chelps a browser along\u201d and expedites server thinking time by working on this loading in advance.<\/p>\n Because of this, this process helps speed up page load time as a result.<\/p>\n Are you not a code master extraordinaire, and you\u2019re unable to work with and optimize code, plugins, and things underneath your website\u2019s hood?<\/p>\n Well, never fear (too much!). There are WordPress plugins available that can help you do just that.<\/p>\n The following includes a list of tools that you can use to help optimize your own critical rendering path for success:<\/p>\n Please note: This author has no financial bias with any of these tools.<\/em><\/p>\n Google\u2019s user behavior data reports that most users abandon a slow site after about three seconds.<\/p>\n In addition to studies that show that reducing page load time and improving the page experience leads to greater user satisfaction, there are also several major Google updates on the horizon that you will want to prepare for.<\/p>\n Identifying and optimizing render-blocking resources will be critical to staying on top of the game when these updates hit.<\/p>\n Google will be implementing page experience on the desktop in 2022<\/a>, beginning their rollout of desktop page experience in February and finishing up in March.<\/p>\n According to Google, the same three Core Web Vitals metrics (LCP, FID, and CLS), along with their associated thresholds, will now be linked to desktop ranking.<\/p>\n Also, Google is working on<\/a> a brand-new, possibly experimental Core Web Vitals metric, taking into account maximum event duration and total event duration.<\/p>\n Their explanation of these factors they are considering are:<\/p>\n Maximum event duration:<\/strong> the interaction latency is equal to the largest single event duration from any event in the interaction group. With many studies<\/a> linking reductions in page load times to improvements in valuable KPIs<\/a> (conversions, bounce rate, time on site), improving site latency has become a top-of-mind business goal for many organizations.<\/p>\n SEO professionals are uniquely positioned to guide this effort, as our role is often to bridge the gap between business goals and web developers\u2019 priorities.<\/p>\n Having the ability to audit a site, analyze results, and identify areas for improvement helps us to work with developers<\/a> to improve performance and translate results to key stakeholders.<\/p>\n One of the primary goals of optimizing the critical rendering path is to make sure that the resources that are needed to render that important, above-the-fold content are loaded as quickly as is humanly possible.<\/p>\n Any render-blocking resources must be deprioritized, and any resources that are preventing the page from rendering quickly.<\/p>\n Each optimization point will contribute to the overall improvement of your page speed, page experience, and Core Web Vitals scores.<\/p>\n Google has said many times that coding is not necessarily important for ranking<\/a>.<\/p>\n But, by the same token, gaining a ranking benefit from page speed optimization improvements can potentially help, depending on the query.<\/p>\n When it comes to CSS files, they are considered to be render-blocking resources.<\/p>\n Why is this?<\/p>\n Even though it happens within a millisecond or less (in most cases), the browser won\u2019t start to render any page content until it can request, receive, and handle all CSS styles.<\/p>\n If a browser renders content that\u2019s not styled properly, all you would get is a bunch of ordinary text and links that are not even styled.<\/p>\n This means that your page will basically be \u201cnaked,\u201d for lack of a better term.<\/p>\n Removing the CSS styles will result in a page that is literally unusable.<\/p>\n The majority of content will need repainting in order to look the least bit palatable for a user.<\/p>\n If we examine the page rendering process, the gray box below represents the browser time needed to get all CSS resources. This way, it can begin constructing the DOM of CSS (or CCSOM tree).<\/p>\n This could take anywhere from a millisecond to several seconds, depending on what your server needs to do to load these resources.<\/p>\n It can also vary, which could depend on the size, along with the quantity, of these CSS files.<\/p>\n The following render tree shows an example of a browser rendering all the files along with CSS within the DOM:<\/p>\n In addition, the following shows an example of the rendering sequence of a page, in which all the files load in a process, from the construction of the DOM to the final painting and compositing of the page, which is known as the critical rendering path.<\/p>\n Because CSS is a render-blocking resource by default, it makes sense to improve CSS to the point where it doesn\u2019t negatively impact the page rendering process.<\/p>\n The official Google recommendation states<\/a> the following:<\/p>\n \u201cCSS is a render-blocking resource. Get it to the client as soon and as quickly as possible to optimize the time to first render.\u201d<\/p>\n<\/blockquote>\n The HTML must be converted into something the browser can work with: the DOM. CSS files are the same way. This must be converted into the CSSOM.<\/p>\n By optimizing the CSS files within the DOM and CSSOM, you can help decrease the time it takes for a browser to render everything, which greatly contributes to an enhanced page experience.<\/p>\n Did you know that loading JavaScript is not always required?<\/p>\n With JavaScript, downloading and parsing all JavaScript resources is not a necessary step for fully rendering a page.<\/p>\n So, this isn\u2019t really a technically required part of page render.<\/p>\n But the caveat to this is: Most modern sites are coded in such a way that JavaScript (for example, the Bootstrap JS framework) is required in order to render the above-the-fold experience.<\/p>\n But if a browser finds JavaScript files before the first render of a page, the rendering process can be stopped until later and after JavaScript files are fully executed.<\/p>\n This can be specified otherwise by deferring JavaScript files for later use.<\/p>\n One example of this is if there are JS functions like an alert that\u2019s built into the HTML. This could stop page rendering until after the execution of this JavaScript code.<\/p>\n JavaScript has the sole power to modify both HTML and CSS styles, so this makes sense.<\/p>\n Parsing and execution of JavaScript could be delayed because of the fact that JavaScript can potentially change the entire page content. This delay is built into the browser by default \u2013 for just such a \u201cjust in case\u201d scenario.<\/p>\n Official Google recommendation<\/a>:<\/p>\n \u201cJavaScript can also block DOM construction and delay when the page is rendered. To deliver optimal performance \u2026 eliminate any unnecessary JavaScript from the critical rendering path.\u201d<\/p>\n<\/blockquote>\n To identify the critical rendering path and analyze critical resources:<\/p>\n Analyze your waterfall view; look for CSS or JavaScript files that are requested before the green \u201cstart render\u201d line but are not critical for loading above-the-fold content.<\/p>\n After identifying a (potentially) render-blocking resource, test removing it to see if above-the-fold content is affected.<\/p>\n In my example, I noticed some JavaScript requests that may be critical.<\/p>\n Even though they are critical, it\u2019s sometimes a good idea to test removing these scripts to test how shifting elements on the site affect the experience.<\/p>\n There are also other ways to improve such resources.<\/p>\n For non-critical JavaScript files, you may want to look into combining the files and deferring them by including these files at the bottom of your page.<\/p>\n For non-critical CSS files, you can also reduce how many CSS files you have by combining them into one file and compressing them.<\/p>\n Improving your coding techniques can also result in a file that\u2019s faster to download and causes less impact on the rendering speed of your page.<\/p>\n Once you determine that a render-blocking resource is not critical for rendering content above the fold, you will want to explore a myriad of methods that are available in order to improve the rendering of your page and defer non-critical resources.<\/p>\n There are many solutions to this problem, from deferring JavaScript and CSS files to reducing the impact that CSS can have.<\/p>\n One possible solution is to not add CSS using the @import rule.<\/p>\n From a performance perspective, even though @import appears to keep your HTML file cleaner, it can actually create issues with performance.<\/p>\n The @import declaration will actually cause the browser to process a CSS file more slowly. Why? Because it is also downloading all of the imported files.<\/p>\n Rendering will be entirely blocked until the process completes.<\/p>\n Indeed, the best solution is to use the standard method of including a CSS stylesheet using the <link rel=\u201dstylesheet\u201d> declaration in the HTML.<\/p>\n If you are on WordPress, using a plugin to minify your CSS and JavaScript files can have a tremendous impact.<\/p>\n The process of minification takes all of the unnecessary spaces within a file and compresses it even further, so you can end up with a nice performance boost.<\/p>\n Also, even if you are not on WordPress, you can use the services of a well-qualified developer to complete the process manually.<\/p>\n This will take more time but can be well worth it.<\/p>\n Minified files are usually much lighter than their former counterparts, which means that initial rendering will complete much faster.<\/p>\n In addition to this, after the minification process, you can also expect the download process to be faster because less time is necessary to download non-render blocking resources.<\/p>\n While third-party fonts may appear to make a site \u201cprettier,\u201d this is not exactly the case.<\/p>\n While it may look amazing on the surface, these third-party font files often take a longer time to load and can contribute to your render-blocking resources problem.<\/p>\n Because of the external files, the browser has to make external requests to download these files to render your page, which may result in significantly higher download times.<\/p>\n If you\u2019re on a team that has less-than-ideal development best practices, then it could stand to reason that you have many third-party font files that are not necessary for rendering your site.<\/p>\n In this case, removing all these unnecessary files can improve your render-blocking resources significantly and contribute to your overall improvement in Core Web Vitals.<\/p>\n Using system fonts, on the other hand, only keeps the processing within the browser without external requests.<\/p>\n Also, there are likely system fonts that may be very similar to the third-party fonts you use.<\/p>\n However, if you absolutely must use third-party fonts, there are two things you want to do to help mitigate issues with certain aspects of third-party fonts.<\/p>\n First, if they are used in conjunction with preload and font-swap<\/a>, the issues with third-party fonts become a non-issue.<\/p>\n The other issue when using third-party fonts is that fonts are invisible until the font itself loads, which negatively impacts Core Web Vitals and the user experience. To avoid this, you can use font-swap CSS<\/a>.<\/p>\n Here\u2019s how it works:<\/strong> The font-swap CSS explains to the browser that text which is using a particular font must be displayed immediately using a system font. Once the custom font is ready, this custom font will then replace the system font. This is the most effective method you can use to avoid invisible fonts during page load.<\/p>\n As of 2020, variable fonts have become widely supported in most browsers. What exactly are variable fonts?<\/p>\n With variable fonts, all of your font styles are contained in a single file. But before variable fonts became commonplace, you would need several separate font files for fonts.<\/p>\n There are also several benefits to using variable fonts, which include:<\/p>\n![\"This](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish.png\")
Screenshot from Web Almanac, November 2022<\/span><\/div>\nWhat Is The Critical Rendering Path?<\/h2>\n
![\"Graphic](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-1.png\")
Screenshot from web.dev, November 2022<\/span><\/div>\nHow Does The Critical Rendering Path Work?<\/h3>\n
![\"An](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-2.png\")
Screenshot from Medium, November 2022<\/span><\/div>\n![\"How](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-3.png\")
Screenshot from web.dev, November 2022<\/span><\/div>\nHow Do I Optimize The Critical Rendering Path?<\/h3>\n
\n
\n
Preloading Page Elements<\/h3>\n
<link rel=\"preload\" as=\"script\" href=\"critical.js\"><\/pre>\n
<link rel=\"preload\" href=\"style.css\" as=\"style\" \/><\/pre>\n
<link rel=\"preload\" href=\"fonts\/webfont.woff2\" as=\"font\" type=\"font\/woff2\" crossorigin \/><\/pre>\n
<link rel=preload href=\"cat.png\" as=image imagesrcset=\"cat.png 1x, cat-2x.png 2x\"><\/pre>\n
Inlining Critical Styles<\/h3>\n
\n
![\"Google.com](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish.jpg\")
Screenshot from Google.com source code, November 2022<\/span><\/div>\nDeferring The Loading Of JavaScript Files<\/h3>\n
<script defer src=\"script.js\"><\/script><\/pre>\n
\n
Using Early Hints For Better Server Optimization<\/h3>\n
![\"Early](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-4.png\")
Screenshot from developer.chrome.com, November 2022<\/span><\/div>\nTools To Help You Optimize Your Critical Rendering Path<\/h3>\n
\n
Why Should I Care?<\/h3>\n
\n
Total event duration:<\/strong> the interaction latency is the sum of all event durations, ignoring any overlap.<\/p>\n<\/blockquote>\nThe Goals Of Optimizing Render-Blocking Resources<\/h2>\n
Why Improve Render-Blocking CSS?<\/h3>\n
![\"How](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-5.png\")
<\/p>\n<\/p>\n![\"DOM](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-6.png\")
Screenshot from Medium, November 2022<\/span><\/div>\n\n
Why Improve Render-Blocking JavaScript?<\/h3>\n
\n
How To Identify Render-Blocking Resources<\/h3>\n
\n
![\"Example](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-7.png\")
Screenshot from WebPageTest, November 2022<\/span><\/div>\n![\"Example](\"https:\/\/marketingnewsbox.com\/wp-content\/uploads\/2022\/12\/how-to-eliminate-render-blocking-resources-via-sejournal-brianharnish-8.png\")
Screenshot from WebPageTest, November 2022<\/span><\/div>\nHow To Reduce Render-Blocking Elements On The Page<\/h2>\n
Make Sure Not To Add CSS Using The @Import Rule<\/h3>\n
Minify Your CSS And JavaScript Files<\/h3>\n
Use System Fonts Instead Of Third-Party Fonts<\/h3>\n
The New Kid On The Block: Variable Fonts<\/h3>\n
\n