Improve site speed: remove render


Editor’s note: This article was updated on 28 January 2022 to lớn include information about the release of Google’s chip core Web Vitals.

Bạn đang xem: Improve site speed: remove render

What are render blocking resources?

Render blocking resources are static files, such as fonts, HTML, CSS, and JavaScript files, that are vital khổng lồ the process of rendering a website page. When the browser encounters a render blocking resource, it stops downloading the rest of the resources until these critical files are processed. In the meantime, the entire rendering process is put on hold.

On the other hand, non-render blocking resources don’t postpone the rendering of the page. The browser can safely download them in the background after the initial page render.

However, not all resources that the browser deems render blocking are essential for the first paint; it all depends on the individual characteristics of the page. There are best practices you can use to lớn turn these noncritical render blocking resources into non-render blocking ones. Besides, you can also decrease the number and/or kích cỡ of render blocking resources that are still critical & can’t be eliminated.

In this article, I will nhận xét nine tips và tricks to eliminate render blocking resources. They are:

Why eliminate render blocking resources?

If you reduce the number of render blocking resources, you can shorten the critical rendering path & reduce page load times, thus improving the user experience and search engine optimization.

There are three ways to lớn reduce the number and impact of render blocking resources:

Make them non-render blocking resources by deferring their downloadDecrease the total number of render blocking resources using techniques such as bundling (this also means fewer HTTP requests)Reduce the kích thước of a resource via minification so that the page has fewer bytes lớn load

Render blocking resources & Core website Vitals

Even though the elimination of render blocking resources has always been an important performance optimization technique, the introduction of vi xử lý core Web Vitals, Google’s new performance metrics, has made it even more important.

As vi xử lý core Web Vitals are included in Google’s tìm kiếm algorithm, you simply can’t ignore them if you want your site to lớn rank high in Google. Render blocking resources can negatively impact one of the three core Web Vitals: the Largest Contentful Paint (LCP).


LCP measures the rendering time of the largest image or text block that’s visible in the user’s viewport. If your critical rendering path is too long (you have too many render blocking resources, or the files are too large), the largest nội dung element will take longer to load. So, for a better LCP score, it’s recommended to keep the number & weight of your render blocking resources in check.


Learn more →

Types of render blocking resources

As a rule of thumb, the browser treats everything it finds in the section of an HTML page as render blocking. This includes:

CSS stylesheetsJavaScript files added in the sectionFonts added from either CDN or a local server

Images, media files, and Deferred scripts follow the document order, just lượt thích nondeferred, mặc định scripts. For example, in the above example, script01.js will be executed first, irrespective of which script loads first. You can’t địa chỉ cửa hàng defer lớn inline scripts; it only works with external scripts that specify the script’s location using the src attribute.

On the other hand, the async attribute informs the browser that a script is completely independent of the page. It will tải về in the background as a non-render blocking resource, just like deferred scripts. However, unlike deferred scripts, async scripts don’t follow the document order, so they will execute whenever they finish downloading — which can happen at any time.

For instance, in the below example, we can’t be sure which script will run first; it solely depends on which downloads faster (usually the smaller one). Remember, async scripts are independent of both the document và each other, so the document order won’t impact them in any way.

The defer attribute is recommended for scripts that need the DOM, but you want to lớn begin to download them before the document loads, without making them a render blocking resource. You should also use defer rather than async if the document order is important — for instance, when consecutive scripts depend on each other.

The async attribute is recommended for independent third-party scripts, such as ads, trackers, & analytics scripts. For example, google analytics recommends adding the async attribute to support asynchronous loading in modern browsers.

6. Find và remove unused CSS and JavaScript

Apart from deferring non-critical CSS và JavaScript, it’s also recommended to kiểm tra if you have any unused CSS or JavaScript on your site. You can vì so with the help of code analysis tools such as PurgeCSS that checks your CSS code & removes any unused selectors from it, including the ones added by third-party libraries or frameworks such as Bootstrap.

Finding và removing unused JavaScript is a bit more tricky as you’ll need khổng lồ analyze your code manually. You can perform a code analysis using Chrome DevTools’ Coverage tab (see the detailed instructions) that will highlight your unused code in red. Even though I only recommend this technique if you are good at JavaScript và know what you’re removing, it can also be a great way to locate third-party libraries that you barely use. If you find an asset lượt thích that, you can consider removing it from your site entirely.

Xem thêm: Cách Gửi Mail Bằng Outlook Chỉ Với 8 Bước, Tạo Và Gửi Email Trong Outlook


Popular content management systems such as WordPress also have cleanup plugins that let you remove your unused CSS and JavaScript automatically.

7. Split code into smaller bundles

You can use module bundlers such as Webpack, Rollup, and Parcel to split your code into smaller bundles và load each bundle on demand and even in parallel. Many of these smaller bundles are non-essential resources that can be safely lazy-loaded after the website page has been rendered. You might also have code that you only need to lớn load if the user wants khổng lồ use a specific part or feature of your page.

Even though it’s possible to perform code splitting & create smaller bundles manually, automation makes the process straightforward, safe, and fast. These days, most bundling tools come with zero-configuration code splitting functionality that works out of the box, but they also let you tweak the configuration manually if you want to.

8. Minify CSS and JavaScript

In addition lớn code splitting, you can also minify both render blocking and non-render blocking resources. Since minified files are lighter, initial page rendering will finish sooner. Plus, it will also take less time to tải về non-render blocking resources in the background.

There are numerous tools available to lớn help you perform minification according to best practices, including Minify, CSS Minifier, Minify Code, và PostCSS. Build tools, such as Webpack, Parcel, and Rollup, also come with built-in minification functionalities that enable you to quickly reduce the weight of render blocking resources.

9. Load custom fonts locally

Because custom fonts are called from the section of the document, they are also render blocking resources. For instance:

You can reduce the impact of custom fonts on initial page rendering by adding them locally rather than pulling them from a nội dung delivery network such as Google CDN. Phông providers tend to địa chỉ cửa hàng multiple
font-face rules for all the character sets a typeface comes with, such as Latin, Cyrillic, Chinese, Vietnamese, and others. Let’s say, for instance, that the online CSS tệp tin you địa chỉ cửa hàng with the tag includes
font-face rules for seven different character sets, but you only want to use one (e.g., Latin). However, Google Fonts doesn’t tải về the fonts files for all the character sets; they just add many redundant
font-face rules to lớn the CSS file.

If you địa chỉ cửa hàng fonts locally, you can also minify your font-related CSS and bundle it together with the rest of your CSS. You can use the Google website Fonts Helper lớn generate local
font-face rules for Google Fonts quickly. For instance, this is what you need to showroom to include the Lato Regular phông face:

/* lato-regular - latin */
font-face font-family: "Lato"; font-style: normal; font-weight: 400; font-display: swap; src: local("Lato Regular"), local("Lato-Regular"), url("../fonts/lato-v16-latin-regular.woff2") format("woff2"), url("../fonts/lato-v16-latin-regular.woff") format("woff");Note that Google web Fonts Helper doesn’t add the font-display: swap rule; I added it myself lớn the above declaration. This is a descriptor of the
font-face rule that lets you specify how the browser should display the phông face on the page.

By using font-display with the swap value, you instruct the browser to immediately begin to use a system font và swap it with the custom fonts once it downloads (this rule is also added when you pull the font from Google’s CDN). This enables you khổng lồ avoid invisible text on the page while the custom font is still loading.

When you load fonts locally, make sure you serve compressed fonts formats for modern browsers, such as WOFF & WOFF2. Remember that lighter files reduce the impact of render blocking resources too. In addition lớn generating the
font-face rules, Google web Fonts Helper also lets you download a zipped file that contains all the font formats you need.

Why you shouldn’t load custom fonts asynchronously

Some articles about render blocking resources recommend using TypeKit’s Web fonts Loader lớn load custom fonts asynchronously. It was a decent tool once upon a time, but it hasn’t been updated since 2017 và it has many unresolved issues. I wouldn’t recommend using it.

Although loading fonts asynchronously shortens the critical rendering path, you should always do it carefully. If fonts load later than the page content, the page can produce a common UX problem called flash of invisible text (FOIT).

There are various ways lớn handle FOIT, such as using third-party libraries or the aforementioned font-display: swap rule (see browser tư vấn for font-display, and note that using it with the swap value just turns FOIT into FOUT – flash of unstyled text – but doesn’t completely eliminate the issue). Still, you’ll want to lớn spend time considering whether it’s really worth going the async route performance-wise. Think of the weight of extra scripts, potential issues, users with disabled JavaScript (you still need to địa chỉ cửa hàng the static element within tags to tư vấn them), etc.


In this article, we discussed nine strategies to eliminate render blocking resources. Lớn summarize:

Identify your render blocking resourcesDon’t use CSS importsLoad conditional CSS with media attributesDefer non-critical CSSUse the defer và async attributes khổng lồ eliminate render-blocking JavaScriptFind và remove unused CSS and JavaScriptSplit code into smaller bundlesMinify CSS và JavaScript filesLoad custom fonts locally

To improve overall page load times, you can also use resource hints và the preload directive. They don’t eliminate render blocking resources per se, but you can use them lớn improve page load times. Render blocking resources won’t stop the fetching process of preloaded resources, & you can also preconnect khổng lồ Google CDN to make web fonts load faster if you don’t want to lớn load them locally.

For an in-depth guide khổng lồ browser rendering, check out “How browser rendering works — behind the scenes.” proactively surfaces và diagnoses the most important issues in your JavaScript apps.


Thousands of engineering và product teams use to lớn reduce the time it takes to understand the root cause of technical and usability issues in their JS apps. With, you"ll spend less time on back-and-forth conversations with customers và remove the endless troubleshooting process. allows you khổng lồ spend more time building new things and less time fixing bugs.

Chuyên mục: Domain Hosting