While knowing how to speed up your website is a crucial technical competence for any serious webmaster, the new frontier is knowing how to avoid getting a web site to perform poorly after having added third-party widgets, add-ons and plugins. As a matter of fact, as mentioned in Part 1 of this guide, Google has already started using also the speed performance of your web site, to determine a web site ranking in the SERPs. What can you do to speed up your web site so that these technologies, while useful to expand user participation, interaction and engagement, do not slow down your web page load times?
Photo credit: Stanely Hong
In the second part of this guide you will learn how to actually implement the solutions, that after long trials, tests and experimentation, we have found to work best for this type of situation. As a matter of fact the solutions described in detail inside this article, which we have devised to speed up your website by deferring the load of JavaScripts and widgets are the very ones we have adopted and implemented on MasterNewMedia.org.
This guide, while targeted at webmaster and web site technical staff, is written in a simple, non-technical language and can be easily understood by both those who need to coordinate such website performance optimization tasks as well as by those who will actually need to execute them.
Here is all of the info you need on how to speed up your website page load performance by delaying the load of third-party widgets and JavaScript - Part 2 (Part 1):
The reason why website speed is being taken into consideration is making the site more usable to the visitors.
In view of that, who says that we have to load all the stuff at once?
Users, as well as Google spiders want to see the page load as soon as possible. This is good for the user experience.
You click on a link, page loads fast, all feels good. Additional stuff on the page is – well – additional.
We all saw the sites where you rollover the images as you arrive to them in the text of the article. You start the YouTube videos as you arrive to them following the text of the article.
We can load the main content of the article which is what user came looking for in the first place and later on load other items that will “put the cream on top” and enhance the usability and experience.
There is no need to load the comments widget right from the start of the page when the user will take some time to read the article and then have something to comment on.
Same goes for the share button(s). They can all be loaded when the user arrives to them, not necessarily immediately when the page loads. Some of them can be loaded only when user activates them via a link or a button.
The theory behind it is simple.
JavaScript widgets are all running JavasScript functions. These functions can be triggered in a number of ways including user action such as a click or a mouseover but also a simple time delay.
This time delay trick is usually referred to as “deferred JavaScript loading”.
This brings us to the next important issue - how will Google see this approach to deferred loading of widgets.
Will that be seen as a problem? Not at all.
Here is Matt Cutts from Google addressing this topic:
Duration: 3' 12''
In short, Google was already thinking of this solution and implementing it.
The crucial part of this video comes at around 1:25:
To fully understand the solutions of deferred vs. asynchronous loading, it is important to understand where the problem originated in the first place.
I suppose everyone experienced at one point or another that some image in some page loads only partially. You end up seeing only a part of the image and the rest just doesn't show up (unless you hit 'reload').
JavaScript doesn't get that because it is set up to get a confirmation from the server that the script has fully loaded and is finished before browser can continue loading the page.
This is what turns JavaScript into a problem. Essentially it's a prima donna. It doesn't let other elements load until it is loaded and finished.
Asynchronous JavaScript does not wait for a response from the server before allowing the page to continue loading.
Deferred loading waits for the page to finish loading and then after X seconds (whichever number of seconds you specify) runs the JavaScript, so that it doesn't interfere with the page load.
Turning any widget or script from JavaScript into asynchronous JavaScript can be as easy as putting:
So your script tag would start with:
On the other hand, the deferred JavaScript is there for a reason: it completely gets the JavaScript out of the way while your page is loading. For the purposes such as comment widgets, share buttons, etc., this can be a good solution because it lets the page load just as if there was no external JavaScript files being loaded. Then, while your visitor reads the page, the comments and the share button are quietly started at the bottom of the article.
Speaking from MasterNewMedia experience, we performed some testing to see which widgets we can adjust and how much speed we can gain by it.
The results were unquestionable.
We took one page and made three versions of it. The only difference was how the comments widget is loaded.
Applying the same set of solutions to all JavaScript in the page, in some cases we were able to shave off as much as seven seconds off of page load time, although on average this number was lower especially during the traffic peak times. As mentioned earlier, when the net is more congested with high number of visitors, the servers get more busy and it just takes longer time for everything to load as opposed to the time periods when there are less people on the net. Still, the results were very encouraging and the page really felt much better. You click a link, page loads very fast, as you read through the article you don't even notice that 10 seconds into your reading of the article, the Apture Bar gets activated and the comments section turns on along with the share button. This definitely improves the user experience. All we did was applying the deferred loading to five scripts and widgets and the page speed analyzers showed that we went from 131 external requests to 81 with three to seven seconds speed improvement per page. I hear you say: “Wait, 50 external requests less? From just five scripts and widgets being deferred?” Yes. When you load scripts and widgets you never get only one. They all have includes or call other scripts, and then includes frequently have more includes. Based on what we saw in our experiments, comment scripts are some of the heaviest load burdens you can have on the pages. Some of them have 20 or more external calls. For the user this means that page will take a while to load even though the content of the widgets will be shown at the bottom of the article. On the other hand, with the deferred load, you can achieve the effect that when you arrive to the page it will feel pretty much like an instant load, and while you are reading through the content, JavasScript will be working in the background preparing the additional content. Properly executed, your users will notice nothing except the pleasant experience of pages being loaded fast. As Matt mentioned in the above video, Google Analytics already uses asynchronous loading and this is a good solution that will satisfy most webmasters. Many other services don't have this feature in their widgets. Those scripts and widgets need some custom coding. Most of them require remarkably little of it, while some need a bit more work.
Photo credit: Stanely Hong
In the second part of this guide you will learn how to actually implement the solutions, that after long trials, tests and experimentation, we have found to work best for this type of situation. As a matter of fact the solutions described in detail inside this article, which we have devised to speed up your website by deferring the load of JavaScripts and widgets are the very ones we have adopted and implemented on MasterNewMedia.org.
This guide, while targeted at webmaster and web site technical staff, is written in a simple, non-technical language and can be easily understood by both those who need to coordinate such website performance optimization tasks as well as by those who will actually need to execute them.
Here is all of the info you need on how to speed up your website page load performance by delaying the load of third-party widgets and JavaScript - Part 2 (Part 1):
How To Speed Up Your Website Page Load Performance by Delaying The Load of JavaScript and Widgets - Part 2
The reason why website speed is being taken into consideration is making the site more usable to the visitors.
In view of that, who says that we have to load all the stuff at once?
Users, as well as Google spiders want to see the page load as soon as possible. This is good for the user experience.
You click on a link, page loads fast, all feels good. Additional stuff on the page is – well – additional.
We all saw the sites where you rollover the images as you arrive to them in the text of the article. You start the YouTube videos as you arrive to them following the text of the article.
We can load the main content of the article which is what user came looking for in the first place and later on load other items that will “put the cream on top” and enhance the usability and experience.
There is no need to load the comments widget right from the start of the page when the user will take some time to read the article and then have something to comment on.
Same goes for the share button(s). They can all be loaded when the user arrives to them, not necessarily immediately when the page loads. Some of them can be loaded only when user activates them via a link or a button.
The theory behind it is simple.
JavaScript widgets are all running JavasScript functions. These functions can be triggered in a number of ways including user action such as a click or a mouseover but also a simple time delay.
This time delay trick is usually referred to as “deferred JavaScript loading”.
This brings us to the next important issue - how will Google see this approach to deferred loading of widgets.
Will that be seen as a problem? Not at all.
Here is Matt Cutts from Google addressing this topic:
Duration: 3' 12''
In short, Google was already thinking of this solution and implementing it.
The crucial part of this video comes at around 1:25:
"...So I wouldn't recommend getting rid od widgets whether they be from Facebook or whether they be ads or whatever just because the server that you are remote talking to is a little bit slower. There are plenty of ways that you can do things that are what we call asynchronous. So for example, we might look at the time that it takes until you reach the onload event, but that doesn't mean that the JavaScript can't keep happening after the onload event. So Google Analytics for example now provides a new snippet of JavaScript code that will not affect the load time in any significant way and that is also good for user experience."Now that we know that Google approves of this solution, lets go to the next stage – implementation. The problem is that none of the widgets out there – at least at this time – are made to defer the loading. They are made to run right away as the page loads. This means that we will have to make some custom adjustments to the code of the widgets.
Deferred Loading Vs. Asynchronous Loading
To fully understand the solutions of deferred vs. asynchronous loading, it is important to understand where the problem originated in the first place.
I suppose everyone experienced at one point or another that some image in some page loads only partially. You end up seeing only a part of the image and the rest just doesn't show up (unless you hit 'reload').
JavaScript doesn't get that because it is set up to get a confirmation from the server that the script has fully loaded and is finished before browser can continue loading the page.
This is what turns JavaScript into a problem. Essentially it's a prima donna. It doesn't let other elements load until it is loaded and finished.
Asynchronous JavaScript does not wait for a response from the server before allowing the page to continue loading.
Deferred loading waits for the page to finish loading and then after X seconds (whichever number of seconds you specify) runs the JavaScript, so that it doesn't interfere with the page load.
Turning any widget or script from JavaScript into asynchronous JavaScript can be as easy as putting:
into a script tag.async="true"
So your script tag would start with:
On the other hand, the deferred JavaScript is there for a reason: it completely gets the JavaScript out of the way while your page is loading. For the purposes such as comment widgets, share buttons, etc., this can be a good solution because it lets the page load just as if there was no external JavaScript files being loaded. Then, while your visitor reads the page, the comments and the share button are quietly started at the bottom of the article.
What Sort of Improvement Can You Expect?
Speaking from MasterNewMedia experience, we performed some testing to see which widgets we can adjust and how much speed we can gain by it.
The results were unquestionable.
We took one page and made three versions of it. The only difference was how the comments widget is loaded.
- One version was intact, as-is, with “normal” JavaScript load.
- Second was the asynchronous load.
- Third was the 10 second deferred load.
Applying the same set of solutions to all JavaScript in the page, in some cases we were able to shave off as much as seven seconds off of page load time, although on average this number was lower especially during the traffic peak times. As mentioned earlier, when the net is more congested with high number of visitors, the servers get more busy and it just takes longer time for everything to load as opposed to the time periods when there are less people on the net. Still, the results were very encouraging and the page really felt much better. You click a link, page loads very fast, as you read through the article you don't even notice that 10 seconds into your reading of the article, the Apture Bar gets activated and the comments section turns on along with the share button. This definitely improves the user experience. All we did was applying the deferred loading to five scripts and widgets and the page speed analyzers showed that we went from 131 external requests to 81 with three to seven seconds speed improvement per page. I hear you say: “Wait, 50 external requests less? From just five scripts and widgets being deferred?” Yes. When you load scripts and widgets you never get only one. They all have includes or call other scripts, and then includes frequently have more includes. Based on what we saw in our experiments, comment scripts are some of the heaviest load burdens you can have on the pages. Some of them have 20 or more external calls. For the user this means that page will take a while to load even though the content of the widgets will be shown at the bottom of the article. On the other hand, with the deferred load, you can achieve the effect that when you arrive to the page it will feel pretty much like an instant load, and while you are reading through the content, JavasScript will be working in the background preparing the additional content. Properly executed, your users will notice nothing except the pleasant experience of pages being loaded fast. As Matt mentioned in the above video, Google Analytics already uses asynchronous loading and this is a good solution that will satisfy most webmasters. Many other services don't have this feature in their widgets. Those scripts and widgets need some custom coding. Most of them require remarkably little of it, while some need a bit more work.
Widgets Speedup Examples
Apture Bar
The Apture Bar is one of the easy widgets to adjust for deferred loading. Old:
New (with 10 seconds delayed loading):
AddThis Button
Old:
New:
Disqus
When it comes to Disqus comments widget the story gets a bit more complex. At the moment this article is being written, Disqus is working on a new version of the Disqus plugin for Movable Type, so in due time the new plugin will be available to load Disqus asynchronously. However, we wanted to know what can we do in the meantime and if there is something we can do that will be even better than waiting for the new plugin. Disqus (at least for the Movable Type implementation) is not a piece of code that you paste into your page, it is a CGI plugin in Movable Type which then generates the JavaScript in all pages when they are being built. We have two options to speed it up.
1) Hack the Disqus Plugin for Movable Type
In the disqus.pl file, simply delete this line:
and then just before the
Taxonomy upgrade extras
