WebPerfLab – JavaScript Optimizations – LoadStorm
Would you be surprised if we could DOUBLE THE SPEED of perceived page response by simple tweaking of script references? How about if we could make the browser work more efficiently to download more images in parallel, thereby reducing the page load time to about 3/4 of its original – would you find that exciting? If not, you’re not a performance geek, and you should be reading someone else’s blog. Since you are a perf geek, read on for the cool data.
For our optimization experiments, we tested two changes concerning the usage of JavaScript in our WordPress site that should speed up page load times:
- Moving JavaScript calls to the footer of each page
- Combining all JavaScript into a single file
Please note: these lab experiments did NOT require us to write any JavaScript code. Nor did we actually modify any of the logic. The changes were much easier than that.
Performance Results from the Optimizations
First, we took a look at what happens when we move our JavaScript requests to the bottom of the page, and the results are exciting. The page can start rendering 45% faster! See the graph below. Notice that the Time to Start Render drops from 1.12 seconds to 0.61 seconds.
Why will the user perceive the page loading so much faster? Because all visual elements are loaded before the Javascript files. The faster the page starts to render, the faster a user perceives the page to be loading, even if the total load is exactly the same speed as before.
But the overall load time did not remain the same – it improved by 24%. Why? Because many more page resources could now be loaded in parallel instead of stopping to wait for several JavaScript files to come through one at a time. Normally, a browser will allow parallel downloading of files:
- Chrome – 6 concurrent connections per host
- Firefox – 8 concurrent connections per host
- IE – 6 concurrent connections per host
Our research found several posts by experts such as Steve Souders (Google) that mention the HTTP/1.1 specification as the reason browsers block parallel downloads when script files are downloading. We don’t understand the benefit of the blocking or the reason the spec would dictate it. However, we accept that the browser won’t start any other downloads and essentially runs single-thread upon encountering script references. By calling those scripts last in sequence, the images and stylesheets will already be retrieved and rendering started.
This graph shows the benefit of maximizing the browser’s concurrent connections by putting script references at the bottom of the page body.
Due to some complications with WordPress, we weren’t able to get all of our JavaScript files combined into one. That said, we managed to reduce the number of script files on our home page alone from 11 to 6. Overall, this lowered the total number of requests made by 14%.
Let’s see what this did to load time.
From a purely functional standpoint, nothing has changed. All the JavaScript code is exactly the same, it’s just all in the same file now. By combining 6 JavaScript files, we reduced load time by 14%.
How We Did It
The idea behind combining JavaScript files is simple: fewer files means fewer requests sent to the server. So to combine JavaScript functions, just copy/paste the contents of each file into a single file and load that file instead of the smaller ones. You’re making a much larger file, but it’s only a single file that needs to be downloaded. One large file tends to download much faster than many smaller files.
Moving JavaScript calls to the footer requires a bit more explanation. If, like me, you were taught in school that tags must live in the part of HTML, you were taught wrong. The W3C recommendations on this state that can live in either the or the , so calls can be safely moved to the very bottom of an HTML document with no repercussions.
Why is this important? When a web browser makes a request to download a JavaScript file, it stops more requests from being made until it finishes with the JavaScript download. This causes a web page to render slowly, since graphical elements have stopped downloading while we wait for the script to finish. Deferring all JavaScript to the bottom of the page, however, solves this problem. Pictures, graphics, and stylesheets don’t need to sit and twiddle their thumbs while JavaScript finishes loading, so the browser can finish rendering the page much sooner. So, the user sees more of the page sooner.
On WordPress, moving JavaScript to the bottom of the page is a bit trickier than moving around tags. All pages are dynamically generated using PHP coding. The specific set of PHP programs and CSS you are using in your WordPress blog is known as your theme. Within your theme’s “functions.php” file, add the following code to the bottom of the page:
remove_action('wp_head', 'wp_print_scripts'); remove_action('wp_head', 'wp_print_head_scripts', 9); remove_action('wp_head', 'wp_enqueue_scripts', 1); add_action('wp_footer', 'wp_print_scripts', 5); add_action('wp_footer', 'wp_enqueue_scripts', 5);
add_action('wp_footer', 'wp_print_head_scripts', 5);
This tells WordPress to wait until it starts loading the footer of the page to start requesting all JavaScript files. If you have a version of WordPress greater than 2.8 (and you probably do, since version 3.6 is the current version as of this writing), you can do it right in each wp_enqueue_script() function by setting the last parameter, “in_footer”, to “true”.
wp_enqueue_script('jquery','','','',true);
This doesn’t work for some files and you may need to implement a slightly more complicated workaround for scripts that are integrated into WordPress.
We took a different approach, though. In our theme, we took the following code out of “header.php” and pasted it into “footer.php”:
document.documentElement.className += 'js-ready';