Having a website, online shop or blog that’s fast is a must nowadays. A fast website doesn’t only give your visitors a much better experience, but it also helps your website to rank. Sending fewer HTTP requests to the server can improve the loading times of your website. But why is that?
What are HTTP requests?
HTTP requests are requests that get sent to the server whenever someone visits your website. These requests can contain a variety of information for the server to process and act upon. The most important part of such a request is the URL. Based on this information, the server will try to return a valid response, such as a file. The first stable implementation of HTTP, HTTP/1.0, does these requests in series. This means that a group of requests needs to be finished before the next group is sent. Obviously, this means that pages with a lot of external files will suffer from longer loading times, making your website slow.
Speeding up initial loading times
As described in the previous section, loading a lot of files one after another will result in longer loading times. Now you might be wondering “How do I speed this process up?”. Luckily, there are a few techniques and advancements in browser technology that can help you with this.
Browser pipelining
Since the introduction of HTTP/1.1, it has been possible to use a feature called “browser pipelining”. This feature allows the browser to fetch multiple files in rapid succession, without waiting for a previous request to finish. This means that the browser doesn’t have to wait as long to send off the next request.
In theory, this would be a very handy feature to have enabled by default. Sadly, in practice, this system still has some flaws. Due to its asynchronous nature, it’s possible that files load in the wrong order.
Let’s take a custom jQuery plugin as an example of how browser pipelining could do more harm than good. As your custom plugin depends on jQuery, the jQuery library needs to be fully loaded before your plugin can properly run. You might already see where this could go wrong; because browser pipelining doesn’t wait for previous requests, your plugin could load before jQuery. The result? JavaScript errors.
This problem with load order can also easily occur with something like images. In the case of images, it’s possible that the order in which the images get displayed differs from the actual order in your HTML.
HOL blocking
Another phenomenon that sometimes occurs when using browser pipelining is Head-of-line blocking (HOL blocking). What this means is that a particular packet (a part of a file) is keeping another packet of the same file from successfully completing. Other packets can only continue on their way once the delivery of the first package to the browser ends.
Due to the issues mentioned, most browsers disable HTTP pipelining by default. In the latest version of HTTP, aptly named HTTP/2, the issues with pipelining are addressed by using a technique called multiplexing which sends multiple HTTP requests over a single TCP connection. If you want to use this technique, make sure your server and your audience’s browsers, properly support HTTP/2.
Move JavaScript files out of the head section
There’s another way to make your website to load faster without much extra hassle. But first a brief history lesson!
Placing all the required CSS and JavaScript in your <head> section used to be considered common practice. However, the problem with this technique is that the rest of your HTML won’t display because these files block its rendering. This results in your visitors looking at a blank page for a couple of seconds.
As early as 2007, a new best practice surfaced. This best practice recommends moving all the JavaScript from your <head> section to the bottom of your page, just before the </body> tag. Why? Because JavaScript blocks any further rendering of a page until it has loaded all its files. By moving the JavaScript, the page’s HTML renders first instead of last. Sometimes it’s possible that you want the rendering of the page to wait until a particular JavaScript file loads. This would be the only exception when it comes to moving files out of the <head> section of your HTML.
Moving CSS to the bottom of the page is not recommended, as it stops the browser from correctly displaying and formatting your content. This impacts the overall user experience. Nobody wants to visit a website where text jumps around the screen because a stylesheet doesn’t load until the very end. Although moving your JavaScript to the bottom of your page doesn’t reduce the number of HTTP requests, it does help improve the overall experience.
Reduce the number of files
Another option to speed up your website is by limiting the number of files that load. This is because for every file you try to load, your browser sends a separate HTTP request to the server. Fewer files mean fewer requests and therefore a faster website.
Most commonly, JavaScript, CSS, and images are the main culprits when it comes to slow loading pages. To combat this, you can use a few techniques, namely:
Minifying and concatenating your JavaScript and CSS files.
By minifying and concatenating assets such as CSS and JavaScript, you not only reduce the overall file size, but you also minimize the number of files that need to load. A good rule-of-thumb is to group files based on their respective functions; if you have multiple files that do something with image manipulation, it might be a good idea to concatenate those.
Additionally, by limiting the number of CSS files that load initially, you reduce the overall loading time. In that case, minification and concatenation can help as well. After the initial loading of CSS files, your browser caches it so subsequent requests shouldn’t take up as much time. You can imagine that having a single file with all the relevant CSS, plus the caching, can significantly improve the overall experience.
If you have CSS that is very specific for a particular page, you’re better off loading that file separately. As a result, you won’t unnecessarily ship specific CSS rules that aren’t used elsewhere in your HTML.
There are plenty of online tools to help you with minification and concatenation during development. You can also use a plugin, such as WP Rocket, to help you out with this.
Optimizing images
Some themes are heavily dependent on pictures. Because images are also separate files themselves, they too fall victim to the limitations of HTTP. To get around this, it is possible to make use of a technique called CSS spriting. This technique allows you to take multiple images (usually of a similar size) and reduce them into a single image. Then with some smart CSS techniques, you manipulate the sprite and only display a specific part of it. There are a couple of online tools that can help with this. It’s unnecessary to create sprites for _all_ your images, but it’s worth putting in the extra effort for things like backgrounds and social media icons.
Lazy loading
Another way to ensure images won’t make your pages slow is using a “lazy loading” plugin. Lazy loading is a technique where some JavaScript looks at the current viewport of the visitor and only loads images that are (almost) within view. A good plugin for this is the Lazy Load plugin which delays loading of images until the user starts scrolling down the page.
Bonus tip: use a CDN
Finally, here’s an extra tip. Content Delivery Networks, or CDNs, are a network of optimized servers across the globe that guarantee fast delivery of static content such as images, CSS and JavaScript. The main advantage of using a CDN is that you’re retrieving content from a separate server. This overcomes one of the HTTP restrictions which limits sending a large number of requests to a single server in one go. By overcoming this restriction, you can achieve shorter loading times! Another advantage of these CDN’s is that the data comes from a server closest to your visitor’s physical location. Shorter distances to the server means faster data retrieval. It’s possible to use more than one CDN, which means your browser can deal with even more HTTP requests at the same time.
Here at Yoast, we use MaxCDN (affiliate link), but with the rising popularity of CDN’s, there are plenty others to choose from. Once you’ve found a CDN provider of your liking, using a caching plugin like WP Rocket can help you to configure your CDN for your website.
Conclusion: Reduce those HTTP requests
As you can see, plenty of techniques are available to decrease the loading time of your website. By far, the biggest improvement you can make is reducing the amount of HTTP requests you send to the server. Additionally, making the files smaller through minification can also help speed things up.
So, go forth and optimize your CSS and JavaScript! Lower those HTTP requests! Your visitors and servers will thank you for it.
Jimmy Comack is Developer Relations Advocate at Yoast by day, gamer and film addict by night. He's a big proponent of open source software and tries to contribute to the OS community when possible.
September 10 - 11, 2024
Team Yoast is at Attending SMX Advanced Europe 2024! Click through to see who will be there, what we will do, and more!
See where you can find us next »
13 August 2024
Learn how to start your SEO journey the right way with our free webinar. Get practical tips and answers to all your questions in the live Q&A!
All Yoast SEO webinars »
24 Responses to How to reduce HTTP requests to speed up your WordPress site
Jessie • 8 years ago
As a beginner, this article has helped me in reducing the HTTP requests. Thanks for the valuable share..!
kenny Williamson • 8 years ago
I actually agree with Ben Brausen above. You can easily spend ages playing around and getting your google page speed to the late 90’s.
However, the process he mentions is correct. Change to https, get a lets encrypt certificate, then begin playing… in fact use a free cloudflare ssl and cdn (I am commenting, but I haven’t used this yet… as the use of free can be complicated when on ssl). Reason, the cdn can do a lot of the minification etc., which means you will have no need. I will write a post about what I did and let all know. It is time consuming and takes long to read about all techniques… so I think a summarised story would be good value for all.
Apex Web Firm • 8 years ago
You guys mention CDN. What do you guys think about cloudflare?
Sebastian • 8 years ago
I used MaxCDN once and was pretty confused with using it. To be fair – that was some years ago.
I used Cloudflare for some time and it’s pretty easy to setup but I don’t use any CDN at all anymore.
Why?
CDNs do also have some drawbacks (just google it) and for my geographic location and target audience a CDN just doesn’t make sense. I do not target the english speaking audience so my content doesn’t need to be available fast everywhere in the world, just in my region.
And a CDN can make things worse if I were to use it in my case. That’s why I stopped using them, but would consider if I need some security layers and have a worldwide audience and a high traffic site.
In other words: CDNs are great – if you really are in need of one. And you might be not in need of one. But feel free to test it out for yourself.
^ Post author
Jimmy Comack • 8 years ago
I personally have no experience with CloudFlare, but I’ve heard some very good stories from people. It could be worth looking at what they offer!
Marcin • 8 years ago
Moving your js files to the bottom is not always the right solution. In many cases the page style depends in those files in same way as on css files. You might be adding/removing classes etc with jquery, so you end up with same downside as moving css to the bottom. Good CDN would be a better solution.
Ben Brausen • 8 years ago
I would be aware that many of the changes people are making to minimize load times right now will cause a lot of extra work to undo them when they make the move to HTTP/2.
Because of this and the huge additional advantages of HTTP/2, it’s worth exploring making the move in that direction now. All major browsers plus Google bots support it, and HTTP/2 brings with it multiple other advantages (security, speed, etc) over the current HTTP/1.1 Why not reap those benefits and the search benefits they’ll bring, now before others make the move?
Vicky Excell • 8 years ago
Its easy to offload assets to a CDN and combine JS and CSS on the fly, but this wont solve the biggest bottleneck with WordPress and that’s the database.
An easy technique to immediately reduce the amount of DB requests is to use a decent cache, but for content which has to be dynamic in nature this does not work. So in these situations you can look to optimise the use of get_bloginfo. With a normal theme you will see get_bloginfo sprinkled through each file, this php is used to query the db to bring back data like the blog name and relative path. By setting get_bloginfo to a static string, it means you are only calling the db once no matter how many times its used..
Teri • 8 years ago
I’m so confused. I mean, I understand every third word of this, and I appreciate the article. But I’m a food blogger newb, and I think my site speed might suck.
Best advice? buythiscookthat.com
Trisha Cupra • 8 years ago
The simplest solution would be to invest in WP Rocket [wp-rocket.me] and to make sure you at least use the free version of WP Smush [or equivalent] plugin to make your images load faster.
Imoveis de Luxo • 8 years ago
very good article. I also do some combinations with super cache Wp and minify plugin that helps a lot.
Erez • 8 years ago
good article overall.
There are good extensions for chrome to measure speed, and report performance.
Ronald Heijnes • 8 years ago
I have been using Autoptimize now for several years, to reduce the number of HTTP-requests. I like it a lot, althought not all CSS and JavaScript can be combined into one file. But the difference is huge, if you have it properly set up. On top of that I use the free plan of Cloudflare. The average load time of my homepage: 1.2 seconds!
And what Luke said!
clasificados cuba • 8 years ago
Great Post I’ll improve muy website performance based on this post. Ohhh, Google is a tedious career.
Brian • 8 years ago
Yeah! I do agree with Luke
Luke Cavanagh • 8 years ago
Other easy ways to reduce the number of HTTP requests on load are, disable emoji and disable embeds. As well as disabling Gravatar in the discussions setting of WP admin. You can minify CSS and JS assets CDN side as well.
You are correct. Reducing the amount of JavaScript files to a single file is not recommended as this could mean you’re loading in a lot of code that has no added value on most pages.
If you look at various parts of your JavaScript, you could split it up in multiple files. For example, you could have one file that handles the logic for your sliders, one that manages some search bar events and a more generic file containing JavaScript for code that is available on nearly every page.
Stefano Lissa • 8 years ago
I think it’s a rather complex subject. “Parallelization” is good if getting that single file from that single server is slower than start few connections… but is is it the case? Those techniques work when the files are distributed over different servers with less output bandwidth than your input bandwidth. This is why a CDN is better than a single server, because usually they have a balancer in front of different servers.
Best thing is to test both the conditions directly in your site and then compare the results.
Mike • 8 years ago
I though the exact same thing reading this, curious what Jimmy thinks. Wondering if that method works best along with how WP Rocket works, but not necessarily overall.
As a beginner, this article has helped me in reducing the HTTP requests. Thanks for the valuable share..!
I actually agree with Ben Brausen above. You can easily spend ages playing around and getting your google page speed to the late 90’s.
However, the process he mentions is correct. Change to https, get a lets encrypt certificate, then begin playing… in fact use a free cloudflare ssl and cdn (I am commenting, but I haven’t used this yet… as the use of free can be complicated when on ssl). Reason, the cdn can do a lot of the minification etc., which means you will have no need. I will write a post about what I did and let all know. It is time consuming and takes long to read about all techniques… so I think a summarised story would be good value for all.
You guys mention CDN. What do you guys think about cloudflare?
I used MaxCDN once and was pretty confused with using it. To be fair – that was some years ago.
I used Cloudflare for some time and it’s pretty easy to setup but I don’t use any CDN at all anymore.
Why?
CDNs do also have some drawbacks (just google it) and for my geographic location and target audience a CDN just doesn’t make sense. I do not target the english speaking audience so my content doesn’t need to be available fast everywhere in the world, just in my region.
And a CDN can make things worse if I were to use it in my case. That’s why I stopped using them, but would consider if I need some security layers and have a worldwide audience and a high traffic site.
In other words: CDNs are great – if you really are in need of one. And you might be not in need of one. But feel free to test it out for yourself.
I personally have no experience with CloudFlare, but I’ve heard some very good stories from people. It could be worth looking at what they offer!
Moving your js files to the bottom is not always the right solution. In many cases the page style depends in those files in same way as on css files. You might be adding/removing classes etc with jquery, so you end up with same downside as moving css to the bottom. Good CDN would be a better solution.
I would be aware that many of the changes people are making to minimize load times right now will cause a lot of extra work to undo them when they make the move to HTTP/2.
Because of this and the huge additional advantages of HTTP/2, it’s worth exploring making the move in that direction now. All major browsers plus Google bots support it, and HTTP/2 brings with it multiple other advantages (security, speed, etc) over the current HTTP/1.1 Why not reap those benefits and the search benefits they’ll bring, now before others make the move?
Its easy to offload assets to a CDN and combine JS and CSS on the fly, but this wont solve the biggest bottleneck with WordPress and that’s the database.
An easy technique to immediately reduce the amount of DB requests is to use a decent cache, but for content which has to be dynamic in nature this does not work. So in these situations you can look to optimise the use of get_bloginfo. With a normal theme you will see get_bloginfo sprinkled through each file, this php is used to query the db to bring back data like the blog name and relative path. By setting get_bloginfo to a static string, it means you are only calling the db once no matter how many times its used..
I’m so confused. I mean, I understand every third word of this, and I appreciate the article. But I’m a food blogger newb, and I think my site speed might suck.
Best advice? buythiscookthat.com
The simplest solution would be to invest in WP Rocket [wp-rocket.me] and to make sure you at least use the free version of WP Smush [or equivalent] plugin to make your images load faster.
very good article. I also do some combinations with super cache Wp and minify plugin that helps a lot.
good article overall.
There are good extensions for chrome to measure speed, and report performance.
I have been using Autoptimize now for several years, to reduce the number of HTTP-requests. I like it a lot, althought not all CSS and JavaScript can be combined into one file. But the difference is huge, if you have it properly set up. On top of that I use the free plan of Cloudflare. The average load time of my homepage: 1.2 seconds!
And what Luke said!
Great Post I’ll improve muy website performance based on this post. Ohhh, Google is a tedious career.
Yeah! I do agree with Luke
Other easy ways to reduce the number of HTTP requests on load are, disable emoji and disable embeds. As well as disabling Gravatar in the discussions setting of WP admin. You can minify CSS and JS assets CDN side as well.
Add to functions.php for disable emojis
function disable_wp_emojicons() {
// all actions related to emojis
remove_action( ‘admin_print_styles’, ‘print_emoji_styles’ );
remove_action( ‘wp_head’, ‘print_emoji_detection_script’, 7 );
remove_action( ‘admin_print_scripts’, ‘print_emoji_detection_script’ );
remove_action( ‘wp_print_styles’, ‘print_emoji_styles’ );
remove_filter( ‘wp_mail’, ‘wp_staticize_emoji_for_email’ );
remove_filter( ‘the_content_feed’, ‘wp_staticize_emoji’ );
remove_filter( ‘comment_text_rss’, ‘wp_staticize_emoji’ );
// filter to remove TinyMCE emojis
add_filter( ‘tiny_mce_plugins’, ‘disable_emojicons_tinymce’ );
}
add_action( ‘init’, ‘disable_wp_emojicons’ );
Thanks Luke for the tip and Real for the code snippet. Good tip!
This helped a lot. Thank you
Great article. I use most of these tips but definitely learned a few things. It would be cool to see Yoast develop caching and minifying plugins.
Hi
WP Rocket do not recommande to Reduce the number of files (merge into one single big file) : http://d33v4339jhl8k0.cloudfront.net/docs/assets/5415e7bfe4b01e2a68fe8243/images/55b277e4e4b03e788eda6074/file-IgRfWgJ8ni.jpg
> http://docs.wp-rocket.me/article/17-reducing-the-number-of-minified-files
So who is right…?
You are correct. Reducing the amount of JavaScript files to a single file is not recommended as this could mean you’re loading in a lot of code that has no added value on most pages.
If you look at various parts of your JavaScript, you could split it up in multiple files. For example, you could have one file that handles the logic for your sliders, one that manages some search bar events and a more generic file containing JavaScript for code that is available on nearly every page.
I think it’s a rather complex subject. “Parallelization” is good if getting that single file from that single server is slower than start few connections… but is is it the case? Those techniques work when the files are distributed over different servers with less output bandwidth than your input bandwidth. This is why a CDN is better than a single server, because usually they have a balancer in front of different servers.
Best thing is to test both the conditions directly in your site and then compare the results.
I though the exact same thing reading this, curious what Jimmy thinks. Wondering if that method works best along with how WP Rocket works, but not necessarily overall.