Remove Render-Blocking JavaScript

rbj3
Keeps the page load quickly Removing Render Blocking JavaScript?  When Page Speed Insights detects that your HTML references a blocking external JavaScript file in the above-the-fold portion of your page. If something is render-blocking, it means that it is keeping the page from loading as quickly as it could. Not CSS (which is an entirely different thing). Actually, Render Blocking JavaScript and CSS mean, A JavaScript or CSS file That keeping the page from loading. If you know about Google page Speed analyzer, Then you might also know that, Google recommends webmasters to remove render blocking JavaScript and CSS from above the fold of the webpage. Google takes it seriously. Well-known SEO guy and WordPress SEO Plugin Author wrote an article titled Google Panda 4, and blocking your CSS & JS. Where he has reported that, Render Blocking JavaScript and CSS can be a result of Penalty. Another reason we should remove Render Blocking JavaScript and CSS is, Web Page loading speed is a matter. It’s proven and officially announced by Google that, Decreasing page load time can rank your webpage better in search engine and Improve user experience. It also increases revenue as well.

Before the browser can render a page it has to build the DOM tree by parsing the HTML markup. During this process, whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML. In the case of an external script the parser is also forced to wait for the resource to download, which may incur one or more network roundtrips and delay the time to first render of the page. See Adding Interactivity with JavaScript to learn more about how JavaScript affects the critical rendering path.

Google recommends to remove or defer javascripts that interfere with loading the above the fold content of your web pages.

Above the fold means what a user sees initially on their screen. That screen might be a phone, ipad, desktop or whatever the user is using to see your webpage. This practice has long been used by people who are into page speed. You do care about your ranking in Google. Your ranking in Google is at risk if you don’t optimize for this. Specifically, if Google sees that your webpage does not load well for certain devices (phones, ipads, etc.) they won’t include you in the results because Google doesn’t want to send users to slow pages or pages that cause the user to wait too long for the content.

To get the specific files that are currently blocking rendering you should use the Google pagespeed insights tool. This tool will tell you the exact files that are blocking a particular page.

rbj1

How do’s remove render-blocking Javascripts

If you are already using W3 Total cache to accelerate your WordPress, You needn’t worry about this. Because W3 Total Cache has built in functionality to remove Render Blocking JavaScript & CSS from WordPress. It’s just need a little configuration. I recommend you to configure W3 Total Cache with recommended settings. Once you have configured W3 Total Cache properly with recommended settings now follow the instructions below:

First Scan your WordPress through Google Page Speed Insight and note down all the Render-blocking JavaScript and CSS file URL listed by Google. Now, Login to your WordPress admin panel and visit “Performance>Minify“.

Now scroll down to JS and CSS section By clicking Add a script button, A field will appear where you can paste the Scripts URLas shown below….

After pasting all the render-blocking JS click the “Save all settings button”. You have just finished removing render-blocking JS. Now it’s time to remove Render-blocking CSS. Do the same things you have done in JS, just make sure that, you have added the render-blocking CSS file URL instead of JS.

Now “Empty All Caches” and check your WordPress site through Google Page Speedinsight. Wow! There is no Render-Blocking JavaScript and CSS.

Hope above these methods works great for you,

 

USING ASYNC JS AND CSS PLUGIN

In this method, We are going to use a plugin which called Async JS and CSS. It’s a free plugin and you can download it from WordPress Plugin Directory. First download Async JS and CSS and install to your WordPress. Once you have installed the plugin to your WordPress, It will start eliminating render blocking Java & CSS from your WordPress.

It’s as easy as I wrote here. It can also minify Java and CSS to your WordPress. To minify JaveScript and CSS using Async JS and CSS plugin you will have to enable it through “Settings>Async Settings” menu. Now check your WordPress through Google Page Speed insight. Wow! ZERO Render blocking JavaScript and CSS.

However, I recommend everyone to using W3 Total Cache.

 

You should avoid and minimize the use of blocking JavaScript, especially external scripts that must be fetched before they can be executed. Scripts that are necessary to render page content can be inlined to avoid extra network requests, however the inlined content needs to be small and must execute quickly to deliver good performance. Scripts that are not critical to initial render should be made asynchronous or deferred until after the first render. Please keep in mind that for this to improve your loading time, you must also optimize CSS delivery.

 

rbj2

Inline JavaScript

External blocking scripts force the browser to wait for the JavaScript to be fetched, which may add one or more network roundtrips before the page can be rendered. If the external scripts are small, you can inline their contents directly into the HTML document and avoid the network request latency. For example, if the HTML document looks like this:

<html>
<head>
<script type=”text/javascript” src=”small.js”></script>
</head>
<body>
<div>
Hello, world!
</div>
</body>
</html>

And the resource small.js is like this:

/* contents of a small JavaScript file */

Then you can inline the script as follows:

<html>
<head>
<script type=”text/javascript”>
/* contents of a small JavaScript file */
</script>
</head>
<body>
<div>
Hello, world!
</div>
</body>
</html>

Inlining the script contents eliminate the external request for small.js and allow the browser to deliver a faster time to first render. However, note that inlining also increases the size of the HTML document and that the same script contents may need to be inlined across multiple pages. As a result, you should only inline small scripts to deliver best performance.

 

Make JavaScript Asynchronous

By default JavaScript blocks DOM construction and thus delays the time to first render. To prevent JavaScript from blocking the parser we recommend using the HTML async attribute on external scripts. For example:

<script async src=”my.js”>

See Parser Blocking vs. Asynchronous JavaScript to learn more about asynchronous scripts. Note that asynchronous scripts are not guaranteed to execute in specified order and should not use document.write. Scripts that depend on execution order or need to access or modify the DOM or CSSOM of the page may need to be rewritten to account for these constraints.

Defer loading of JavaScript

The loading and execution of scripts that are not necessary for the initial page render may be deferred until after the initial render or other critical parts of the page have finished loading. Doing so can help reduce resource contention and improve performance.

Using a JavaScript library such as jQuery?

Many JavaScript libraries, such as JQuery, are used to enhance the page to add additional interactivity, animations, and other effects. However, many of these behaviors can be safely added after the above-the-fold content is rendered. Investigate making such JavaScript asynchronous or defer its loading.

Using a JavaScript framework to construct the page?

If the content of the page is constructed by client-side JavaScript, then you should investigate inlining the relevant JavaScript modules to avoid extra network roundtrips. Similarly, leveraging server-side rendering can significantly improve first page load performance: render JavaScript templates on the server to deliver fast first render, and then use client-side templating once the page is loaded. For more information on server-side rendering, see http://youtu.be/VKTWdaupft0?t=14m28s.

Source

 Optimize CSS Delivery

When  Page Speed Insights detects that a page includes render blocking external stylesheets, which delay the time to first render.

Before the browser can render content it must process all the style and layout information for the current page. As a result, the browser will block rendering until external stylesheets are downloaded and processed, which may require multiple roundtrips and delay the time to first render. See render-tree construction, layout, and paint to learn more about the critical rendering path, and render blocking CSS for tips on how to unblock rendering and improve CSS delivery.

Do’s

If the external CSS resources are small, you can insert those directly into the HTML document, which is called inlining. Inlining small CSS in this way allows the browser to proceed with rendering the page. Keep in mind if the CSS file is large, completely inlining the CSS may cause PageSpeed Insights to warn that the above-the-fold portion of your page is too large via Prioritize Visible Content. In the case of a large CSS file, you will need to identify and inline the CSS necessary for rendering the above-the-fold content and defer loading the remaining styles until after the above-the-fold content.

Example of inlining a small CSS file

If the HTML document looks like this:

<html>
<head>
<link rel=”stylesheet” href=”small.css”>
</head>
<body>
<div class=”blue”>
Hello, world!
</div>
</body>
</html>

And the resource small.css is like this:

.yellow {background-color: yellow;}
.blue {color: blue;}
.big { font-size: 8em; }
.bold { font-weight: bold; }

Then you can inline critical CSS as follows:

<html>
<head>
<style>
.blue{color:blue;}
</style>
</head>
<body>
<div class=”blue”>
Hello, world!
</div>
<noscript id=”deferred-styles”>
<link rel=”stylesheet” type=”text/css” href=”small.css”/>
</noscript>
<script>
var load Deferred Styles = function() {
var add Styles Node = document. Get Element By Id(“deferred-styles”);
var replacement = document. Create Element(“div”);
replacement. Inner HTML = add Styles Node .text Content;
document. body. Append Child(replacement)
add Styles Node .parent Element. remove Child(add Styles Node);
};
var raf = request Animation Frame || moz Request Animation Frame ||
web kit Request Animation Frame || ms Request Animation Frame;
if (raf) raf(function() { window.set Timeout (load Deferred Styles, 0); });
else window.add Event Listener(‘load’, load Deferred Styles);
</script>
</body>
</html>

This transformation, including the determination of critical/non-critical CSS, inlining of the critical CSS, and deferred loading of the non-critical CSS, can be made automatically by the PageSpeed Optimization modules for nginx, apache, IIS, ATS, and Open Lightspeed, when you enable the prioritize_critical_css filter.

See also the loadCSS function to help load CSS asynchronously, which can work with Critical, a tool to extract the critical CSS from a web page.

The critical styles needed to style the above-the-fold content are inlined and applied to the document immediately. The full small.css is loaded after initial painting of the page. Its styles are applied to the page once it finishes loading, without blocking the initial render of the critical content.

Note that the web platform will soon support loading stylesheets in a non-render-blocking manner, without having to resort to using JavaScript, using HTML Imports.

Don’t inline large data URIs

Be careful when inlining data URIs in CSS files. While selective use of small data URIs in your CSS may make sense, inlining large data URIs can cause the size of your above-the-fold CSS to be larger, which will slow down page render time.

Don’t inline CSS attributes

Inlining CSS attributes on HTML elements (e.g., <p style=…>) should be avoided where possible, as this often leads to unnecessary code duplication. Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP).

Source

 Inline CSS

Modern browsers block on external CSS before painting content to the screen. This incurs additional network latency and increases the time it takes to display content to the screen. To optimize the time to render, if the external CSS resources are small, you can insert those directly into the HTML document. Inlining small CSS in this way allows the browser to proceed with rendering the page.

Note: Avoid inlining CSS attributes on HTML elements (e.g., < p style=…>) should be avoided where possible, as they often lead to unnecessary code duplication, and are blocked by default with Content Security Policy (CSP) (disabled via “unsafe inline” on “style-src”).

For example, if the HTML document looks like this:

<html>
<head>
<link rel=”stylesheet” href=”small.css”>
</head>
<body>
<div class=”blue yellow big bold”>
Hello, world!
</div>
</body>
</html>

And the resource small.css is like this:

.yellow {background-color: yellow;}
.blue {color: blue;}
.big { font-size: 8em; }
.bold { font-weight: bold; }

Then you can inline the CSS as follows:

<html>
<head>
<style>
.yellow {background-color: yellow;}
.blue {color: blue;}
.big { font-size: 8em; }
.bold { font-weight: bold; }
</style>
</head>
<body>
<div class=”blue yellow big bold”>
Hello, world!
</div>
</body>
</html>

This eliminates the browser request to small.css by placing its contents inline in the HTML document.

Source

Author: howtodonwherefrom

Blogger, Author, Internet Marketer. Working Online Part Or Full Time from Home. Practicing SEO, Microsoft Office & Related everything. What I learn are trying to deliver who needs.