WebPerf WordPress Performance – Breaking It Down by HTTP Requests

WordPress can be a tricky beast as they say when it comes to web performance. Especially if you are comparing it against others running static sites. Because WordPress is based on PHP and most of the content is dynamically generated, it means you need to find other ways to optimize. In today’s post, we are going to dive into a fresh WordPress install and take it apart piece by piece, or rather by HTTP requests, to hopefully help you gain a better understanding of WordPress performance. WordPress can load a lot faster than what some people might lead you to believe!


Breaking Down WordPress Performance


In this post, we are going to first tear down a fresh install and then afterwards make some improvements to it. Make sure to also check out our speed up WordPress guide for additional tips on improving WordPress performance. In this case study, we are running on NGINX, over HTTPS and HTTP/2. If you are starting a new website, we encourage you to take advantage of HTTP/2 right off the bat. Or check out our HTTP to HTTPS migration guide.

Understanding the basics when it comes to web performance makes it easier to apply advanced methods later.
​

Our fresh WordPress site is using the default Twenty Sixteen theme.

Let’s first take a look at each HTTP request that is generated out of the box, as there are a couple you can probably get rid of. So by default, we have a site with 15 HTTP requests at a page size of 135 KB. And a decent load time. Remember, as you add media and content to your site your load time will only increase, so it is better to optimize your site as much as possible first, and then add content. Also, if you are starting with a different base theme, you can apply almost everything we do below as well, although it might vary slightly.



Step 1. Disable Emojis


The first one is the wp-emoji-release.min.js file. This file is used for showing emoji characters in WordPress, since version 4.2. Unless you absolutely can’t live without emojis, we recommend this is the first thing to get rid of on a fresh install. To disable emojis you have the following to options:

1. Disable Emojis with Code


The first way to disable emojis is you can put the following code into your functions.php file.

---

/**
* Disable the emoji's
*/
function disable_emojis() {
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_action( 'admin_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
add_filter( 'tiny_mce_plugins', 'disable_emojis_tinymce' );
}
add_action( 'init', 'disable_emojis' );

/**
* Filter function used to remove the tinymce emoji plugin.
*
* @param array $plugins
* @return array Difference betwen the two arrays
*/
function disable_emojis_tinymce( $plugins ) {
if ( is_array( $plugins ) ) {
return array_diff( $plugins, array( 'wpemoji' ) );
} else {
return array();
}
}
2. Disable Emojis with Plugin


If you prefer to use a free lightweight plugin, Ryan Hellyer has created a great “Disable Emojis” plugin for WordPress. The total size of the plugin is only 9 KB.



Remember, with plugins it isn’t always bad to have a lot of them running. It is more about quality of the plugin vs quantity. If a plugin is lightweight, it won’t slow your site down. Essentially all this plugin is doing is running the code we shared above. After doing this we are now left with 14 HTTP requests at a total size of 129 KB.



Step 2. Disable Embeds


Next, we will look at the wp-embed.min.js script. This has been included in WordPress since version 4.4. This is a script that auto formats pasted content in the visual editor, such as videos, tweets, etc. However, this is not really needed. A big issue with this script is that it loads on every single page, whether it is being used or not. You can still use the default embed code from YouTube and Twitter to included content, even when this script is disabled. Again we have two options:

1. Disable Embeds with Code


The first way to disable embeds is you can put the following code into your functions.php file.

// Remove WP embed script
function speed_stop_loading_wp_embed() {
if (!is_admin()) {
wp_deregister_script('wp-embed');
}
}
add_action('init', 'speed_stop_loading_wp_embed');
2. Disable Embeds with Plugin


If you prefer to use a free lightweight plugin, Pascal Birchler has created a great “Disable Embeds” plugin for WordPress. The total size of the plugin is only 3 KB and features the following:

• Prevents others from embedding your site.
• Prevents you from embedding other non-whitelisted sites.
• Disables all JavaScript related to the feature.

After doing this we are now left with 13 HTTP requests at a total size of 128 KB. You can also see that our DOMContentLoaded and total Load time keeps decreasing as we make these WordPress performance tweaks. We are using Chrome DevTools and have caching disabled.



Step 3. Implement Caching


Notice above in all of our speed tests that the first HTML initial DOC load is quite high. Even when we enable caching in Chrome DevTools it still hovers around 180 ms. So to fix the initial HTML DOC load time, you need to implement a caching mechanism. In this case, we are going to use the free WordPress Cache Enabler plugin from KeyCDN.



Cache Enabler is a lightweight caching plugin for WordPress that makes your website faster by generating static HTML files to disk. This is a very fast method of caching. The plugin also focuses on HTTP/2, meaning you won’t find options for concatenation, as this can hurt HTTP/2 performance. The total size of the plugin is only 15.4 KB.



In the Cache Enabler plugin settings we have pre-compression checked, as well as cache minification of HTML & Inline JS.



Now, lets look at our first HTML initial DOC load again. Simply by enabling Cache Enabler, this has dropped us from 180 ms on average down to 80 ms on average. So it shaved off about 100 ms from our HTML DOC load. This is the power of what a caching plugin will do for your WordPress site. Also, our total page size dropped to 123 KB thanks to minification and again our DOMContentLoaded and total load time is lower.



Step 4. Use a CDN


Now that we have our base fresh install fairly well optimized, now is the time to add a CDN into the mix. By using a CDN you can further decrease the latency by serving up the content closer to your visitors. Also, as we will show later on, there are additional benefits, such as moving towards a single HTTP/2 connection and ignoring query strings for additional caching.

Make sure to check out our in-depth posts on how a CDN works and also our getting started guide. In this post, we are going to assume you already have a CDN up and running. We are going to be using the free WordPress CDN Enabler plugin from KeyCDN to deploy our CDN. The total size of the plugin is only 6.4 KB.



In the CDN Enabler settings we enable HTTPS (as we are using HTTP/2 from KeyCDN) and input our CDN URL.



After we enable the CDN, you can see most of our assets (JavaScript, CSS, etc.) are now loading from our CDN. The total load time drops by about half, and our DOMContentLoaded time also decreases by a large amount. Notice how our waterfall, is getting nicer as we continue to optimize. Not sure what we mean by waterfall? Make sure to check out our in-depth post on waterfall analysis.



Step 5. Remove Query Strings


Next, you notice how every script ends in a version number? Such as ver=1.12.4 or vers=3.4.1. These are called query strings and help determine the version of the script. The problem with query strings like these is that it isn’t very efficient for caching purposes and sometimes prevents caching those assets altogether. So you have a three options here:

1. Remove Query Strings with Code


The first way to remove query strings is you can put the following code into your functions.php file.

function _remove_script_version( $src ){
$parts = explode( '?ver', $src );
return $parts[0];
}
add_filter( 'script_loader_src', '_remove_script_version', 15, 1 );
add_filter( 'style_loader_src', '_remove_script_version', 15, 1 );
2. Remove Query Strings with Plugin


If you prefer to use a free lightweight plugin, Atul Kumar Pandey has created a great “Query Strings Remover” plugin for WordPress. The total size of the plugin is only 1.5 KB.



3. Cache and Ignore Query Strings with a CDN (Recommended)


The third option and this is the recommended method is that if you using KeyCDN, we have an option to actually ignore query strings and cache the assets regardless. This feature is enabled by default on all zones. This means you don’t need to use code or a plugin for this optimization, it is all handled by the CDN. If for some reason you need to disable it, it can be done under the advanced features on your zone.



Step 6. Host Google Fonts


Next, if we look closer we can see there are 4 requests being generated to fonts.gstatic.com. And this is to load Google fonts, which is included in the default WordPress theme. In our example, it is loading different font weights for Merriweather and Montserrat.

It always better to reduce the number of external DNS lookups and also focus on having a single HTTP/2 connection if possible. Every external lookup introduces its own set of latency issues, content download times, TLS negotiations, etc. So what we are going to do is move the Google fonts to our CDN. This way they load from the same place as the rest of our assets.

You can check out our in-depth tutorial on how to migrate Google Fonts to your CDN. This can also be used to simply host them directly on your web server as well, if you aren’t using a CDN. We quickly download the following Google fonts from google webfonts helper and host them on our server in a folder called “fonts.”

merriweather-v13-latin-700.woff
merriweather-v13-latin-700.woff
merriweather-v13-latin-700italic.woff
merriweather-v13-latin-700italic.woff2
merriweather-v13-latin-900.woff
merriweather-v13-latin-900.woff2
merriweather-v13-latin-900italic.woff
merriweather-v13-latin-900italic.woff2
merriweather-v13-latin-italic.woff
merriweather-v13-latin-italic.woff2
merriweather-v13-latin-regular.woff
merriweather-v13-latin-regular.woff2
montserrat-v7-latin-700.woff
montserrat-v7-latin-700.woff2
montserrat-v7-latin-regular.woff
montserrat-v7-latin-regular.woff2

Because we are using the CDN Enabler plugin already, these fonts then are immediately copied to our CDN. To use them, we then have to disable Google fonts in our WordPress theme and apply the styles to our internal CSS stylesheet. This will vary based on whatever theme you are using. If you can’t figure out how to disable Google fonts on your current theme, feel free to ask your theme developer.

As you can see, we are now down 12 HTTP requests since we no longer have to query Google’s stylesheet. And our fonts are now loading from the CDN. You can see that our DOMContentLoaded and total load time also continue to drop. Every optimization we make has a crucial impact on performance.



Step 7. Disable Gravatars


As you can see we are almost down to a single HTTP/2 connection with no external DNS lookups. The only thing left is that call to gravatar.com. Thankfully they are using HTTP/2 now, but unless you really want avatars, you can disable them.



This can easily be remove by un-checking the “show avatars” in the discussion setting of your WordPress dashboard.



By removing the call to gravatar.com we are now down to 11 HTTP requests and are using a single HTTP/2 connection for external assets on our CDN.



And if we un-check the “disable cache” option in Chrome DevTools we can see for repeat visits the website loads very fast!



WordPress Performance – In Summary


As you can see, when you break down a site by individual HTTP requests it helps you to understand better what is causing delays and how you can improve upon WordPress performance. You can then take this knowledge and apply it to bigger sites and more advanced WordPress themes. We have seen these simple techniques mentioned above even help bring WordPress themes like Avada (which is known for being very large) to load times of under 650ms!

Related Articles

• 18 Tips on How to Speed Up WordPress
• Benchmarking Cache Enabler Plugin

The post WordPress Performance – Breaking It Down by HTTP Requests appeared first on KeyCDN Blog.

Continue reading...

 

very true, though just remember the chrome dev tool network reported times are relative to the distance between you and your server/wordpress hosted location

so the above example with ~80ms means the author of the articles browser location and server is very close

if you're testing yourself and you're in say Australia and server is in USA, then times will be much higher than 80ms.

 

For geographical tests best to use webpagetest.org

example for my Wordpress7 site hosted in Fremont, California DigitalOcean 2GB droplet test location from webpagetest.org Los Angeles

• summary WebPagetest Test Result - Los Angeles : la...s7.centminmod.com/ - 10/14/16 03:53:26
• waterfall WebPagetest Test Details - Los Angeles : la...s7.centminmod.com/ - 10/14/16 03:53:26