IT.COM

Eliminate Render Blocking Resources

Spaceship Spaceship
Watch

Gustavo-Woltmann

Restricted (50-70%)
Impact
40
I run an affiliate site and my homepage has a low-performance score in Google PageSpeed Insights (42).

I used Elementor to design my homepage. Now I can save about 4 seconds of load time by eliminating render-blocking resources. But I have no idea how to do that. Does it require changing some code?
Can anyone take a quick look and help me?

Gustavo Woltmann.
 
0
•••
The views expressed on this page by users and staff are their own, not those of NamePros.
Render blockers are javascripts. Scripts block displaying the first paint until they are fully loaded and processed. Add "async" or "defer" to your "<script ... >" tags
 
Last edited:
0
•••
If it's not html5 async and defer will not work. In that case, move your javascripts to the footer.
 
0
•••
I run an affiliate site and my homepage has a low-performance score in Google PageSpeed Insights (42).

I used Elementor to design my homepage. Now I can save about 4 seconds of load time by eliminating render-blocking resources. But I have no idea how to do that. Does it require changing some code?
Can anyone take a quick look and help me?

Gustavo Woltmann.
If the pages are static, you may consider cache ( Cache_Lite, for example) to speed load time. Just an idea, based on the scanty info you've provided.
Also consider code optimization. As mentioned above, move js scripts and/or css files to the footer.
 
Last edited:
0
•••
There are other render blockers as well. But javascripts are the most serious ones.
Avoid using third party fonts. Avoid using resources hosted by third party servers and cdn's.
Move heavy visual page elements (ads, images, videos, etc) to below the fold.
Move css to somewhere near top in your html codes order. Load css before js. So browsers will start paint as soon as css is loaded.
use html/2 on your server
 
Last edited:
1
•••
I mean http/2, not html/2 sorry for the typo.

http/2 allows parallel loading which greatly speeds up page load. It doesn't solve rendering blocking issue directly. But it lowers the need for solving it.

Sometimes after I solve render blocking issue look or functionality of my web pages change in a way that I don't like. In such cases I ignore all warnings about render blocking. Because if pages already load very fast with http/2, render blocking doesn't make a huge difference in the speed.
 
0
•••
As mentioned above, move js scripts and/or css files to the footer.

Only js scripts should be moved to the footer. Css files and inline css codes must stay somewhere near to the top and before any script file/code. Otherwise pages will be flashing on browsers and painting will delay. You sholdn't move css files to the footer.
 
0
•••
Only js scripts should be moved to the footer. Css files and inline css codes must stay somewhere near to the top and before any script file/code. Otherwise pages will be flashing on browsers and painting will delay. You sholdn't move css files to the footer.
It depends on what the css codes do. I've in my projects most secondary, non-essential css codes located on the footer part.
Also remember that there are inline styles - when you add the style attribute to the relevant element - which you can come across anywhere on the page.
Further, execution of some js scripts (regardless of location on the page) could altogether be delayed until the main document has been fully loaded (document ready functions). Again, it all depends.
 
Last edited:
0
•••
It depends on what the css codes do. I've in my projects most secondary, non-essential css codes located on the footer part.
Also remember that there are inline styles - when you add the style attribute to the relevant element - which you can come across anywhere on the page.
Further, execution of some js scripts (regardless of location on the page) could altogether be delayed until the main document has been fully loaded (document ready functions). Again, it all depends.

I mean main css file that shapes the page (html and body in particular) in width, margin, font family&color, background, etc.
>most secondary, non-essential css codes located on the footer part.
I agree inline css or smaller css files for minor parts of the page (comment box, minor design details of sidebar, footer etc) can be anywhere before body and html tags are closed. Main css has to be on the top in html, before header tag is closed. Otherwise browsers will usually shape the page immediately based on their default settings and will shape the page again based on the main css if it's not located on the top. The second shaping will usually cause flashing, delay and bad user experience as flashing will likely trigger a sense in ordinary visitors on something can be wrong with the site (i.e., site or their device may have virus, etc). Flashing will likely be consistent in visiting other pages by the same visitor. Even if the browser has a cached version of main css, main css will still load later, thus the flashing will be persistent. Because browsers process html sequentially
 
Last edited:
0
•••
Back