Whether you’re currently working on your first WordPress site or your fiftieth, you’ve no doubt encountered that its greatest strength can sometimes become its greatest weakness. Its incredible capacity to be extended means it can do more than any other CMS, but the downside is that it can become over-extended and slide into atrociously slow loading speeds.
Fast load time becomes more important year by year as we see Google continue to factor it further into their ranking processes, and we learn more about the cost of slow sites in terms of lost visitors and revenues. It is critical that WordPress sites aren’t allowed to slip into lagging load times–they can and should all be optimized into snappy performers.
In this article we’ll be taking a deep dive into exactly:
- What load speeds you should be achieving
- The reasons WordPress sites become slow
- How to comprehensively diagnose why your WordPress site is slow
- How to fix the problems you discover through simple accessible methods
I’ve been working with WordPress professionally for 12 years, and in that time I’ve seen a lot to do with what can make a site load blazingly fast or crushingly slow. In this article I’ll be sharing everything I know.
Let’s start with how to set the right goals for speeding up your WordPress site.
Speed Up WordPress, but to What?
Exactly how slow is “slow” for a WordPress site? And how fast is “fast”? How do we account for the variation in connectivity speeds? A 3 second load time on high speed internet could be 30 seconds on a slow mobile connection.
Let’s start by figuring out exactly how “fast” we need our WordPress sites to get.
Round Up From Hobo Web
Hobo Web wrote an excellent article collecting several resources and sets of information regarding the load speed we should target. I’m not going to rehash the entire piece, but what I do want to do is pull out some key points:
Every Extra Second Increases Bounce Rates
“The probability of bounce increases 32% as page load time goes from 1 second to 3 seconds”
About Half of Visitors Leave After 3 Seconds
“Slow loading sites frustrate users and negatively impact publishers. In our new study, “The Need for Mobile Speed”, we found that 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load.”
Loading in Under 5 Seconds Doubles Ad Revenue
“While there are several factors that impact revenue, our model projects that publishers whose mobile sites load in 5 seconds earn up to 2x more mobile ad revenue than those whose sites load in 19 seconds.”
Google Says: Ready for Interaction in < 5 Seconds on Slow 3G
According to Google, your site’s content should load and be ready for interaction in less than 5 seconds on a slow 3G connection:
It’s important to point out this doesn’t mean that every single resource on a page needs to be loaded within 5 seconds. That is a very difficult goal to reach on a slow 3G connection, even on resource light sites.
What it does mean is that a visitor needs enough resources to be loaded in that time that they can start interacting with the site, even while the rest of the resources continue to load in the background.
Goal: 3 - 5 Seconds on Mobile
We can summarize the above by saying a general rule of thumb is your site should load within 3 - 5 seconds on a mobile connection, and the faster the better. If you can get your load time to 2 seconds or 1 second or even 500ms, you’ll gain benefit from every moment saved.
Note that you should always focus on getting your load speeds up to par on mobile because:
- Catering to mobile visitors is essential
- A site that loads fast on mobile will also load fast on desktop as a result
So, now that we know our load speed goal is less than 3 - 5 seconds on a mobile connection, let’s talk about how to speed up a WordPress site to that goal time.
Why is WordPress So Slow? 7 Problems
There’s a very good chance that without proper optimization your WordPress site is loading slower than the 3 - 5 second goal. In order to remedy this you need to understand the most common problems that cause a WordPress site to load slowly.
There are seven primary problems that occur; let’s quickly define each one before we move onto how you can deal with them.
1. Loading Files Too Early
When a visitor is reading the top part of an article there is no need to load images that won’t be seen until they reach the bottom of the article.
2. Loading Too Many Separate Files
Load the minimum possible number of separate files. It’s better to have a single file that’s 100kb than 10 files at 10kb each.
3. Loading Unnecessary Data
It’s very common in WordPress to have plugins, (or even core WordPress itself), loading files that aren’t being used, or only partially used. Every bit of unnecessary data adds to load time.
4. File Sizes Too Large
When site files such as CSS, JS and images are too large it can drastically increase load times.
5. Hosting Service Too Slow
If a hosting services has insufficient hardware being used, such as low powered CPUs / insufficient RAM, or doesn’t employ proper optimization processes, it can cause your WordPress site to lag.
6. Not Using Caching
If WordPress has to do too much processing on the server it can cause a significant delay before content is ready to be loaded. Caching can alleviate this problem.
7. Not Using CDN
If your visitor and your WordPress site are located on opposite sides of the planet this can cause a substantial delay in load time. A content delivery network, or CDN, can solve this problem.
But Why is My WordPress Site So Slow? Diagnosing Problems Step by Step
Now you know what the problems are that can cause a slow loading site, but you still need to know specifically which of these problems your own site is experiencing in order to apply solutions correctly.
We’ll be looking at how to test for problems 1 through 4, as described in the previous section. We’re focusing on these four problems first because they may or may not be an issue on any given site.
Problems 5 through 7 should be addressed on every site by using a fast host, caching and CDN, which we will discuss later.
As we go through these steps I’ll be putting my money where my mouth is and showing you the test results from my own personal website. (It’s not a WordPress site but the optimization methods are the same).
In comparison I’ll be showing you the results from the demo page of a very popular WordPress theme. (The theme will remain nameless as the goal is not to call anybody out, but rather to show how out of control load speed can get on WordPress sites without proper optimization).
Browser Based Testing Tools
There are several websites you can use to test the speed of your sites, but at this point they are no longer really necessary as the tools that come built into browsers are excellent. I’ll be taking you through using some tools included in Chromium based browsers and Firefox.
Note: Chromium based browsers are pretty much every browser except Firefox, e.g. ungoogled-chromium, Vivaldi, the latest Edge, Opera etc. As such you should be fine to use your browser of choice to access these tools.
A quick point to be aware of while testing:
- Use a “Private Window” or “Incognito Mode” to ensure extensions are disabled, as they might effect load speed.
Step 1: Test “Slow 3G” Load Speed
We’re going to do a couple of speed tests to see how close we are to having an interaction ready site in under 5 seconds on slow 3G.
In a Chromium based browser open and “Incognito Mode” window, by going to the menu seen in the image below, then load up your website.
Now open up Developer Tools by going up to this menu at the top right of the browser:
Once the tools are open go to the Network tab, check the box labelled Disable cache, and change the drop-down list at the right end of the toolbar to Slow 3G. This emulates a first time visit from someone on a pretty poor mobile connection. The settings should look like this:
Refresh the page and watch the panel keep track of loading all your site’s resources.
We are looking for, once the page load is complete, the numbers at the bottom of the panel, in particular the blue number and the red number. Without getting into technicalities, the blue number is when the base resources like text have loaded, and the red number is when the more visual resources like styles and images have loaded. The point at which a site can be interacted with will typically be somewhere in between the blue number and the red number.
These are the numbers from my personal site:
As you can see I’ve just snuck in under the 5 second load time on the red number, though in actual fact the point at which you can start interacting with my site would be nearer to the blue number.
And these are the numbers from the popular WordPress theme demo site:
26 seconds on the blue number and over a minute on the red number. Ouch. Not even close to the 5 second load time we’re looking for. In fact, somewhere between 5 to 14 times slower than the goal.
It’s pretty clear this site is missing the mark on load speed, so the next question is why? To answer that question we’ll start checking which of the problems we outlined above might be making impacts.
Step 2: Check Firefox Performance Analysis
Open your website in a private window in Firefox:
Open the “Network Tools” by going to the top right menu of Firefox, selecting Web Developer, then Network:
Once the network tools appear, click the little button at the bottom right corner that looks like a stopwatch:
This will initiate a performance analysis that will evaluate what happens during a first time visit (no cached resources) or a subsequent visit (some cached resources).
Here are the results from my personal site:
The bottom pie chart and table represents a first time load, and the top chart & table represent a subsequent load when a visitor has some resources cached in their browser.
There are a couple of things to note here that will become relevant shortly:
- You’ll see I have only 1 JS file and 0 CSS files - my CSS is inline in the HTML
- You’ll also see only two images are loaded - this page actually has 6 images but I only load them when needed
- I have a total of only 4 page requests
- Total transferred size is 183.04 KB
And the results from the theme demo site:
These results are a little different:
- 11 JS files and 5 CSS files
- 41 images
- A total of 59 page requests
- Total transferred size is 5,237.26 KB
These results are starting to form a picture of where the problems are, and sure enough they line up with problems 1 through 4 we outlined earlier:
1. Loading Files Too Early
Images are loaded before they are needed; I counted 14 that were visible in the viewport size I was using, meaning the remaining 27 could be loaded later.
2. Loading Too Many Separate Files
There are too many JS and CSS files; 11 JS and 5 CSS, when typically you should only ever need one of each.
This, plus the early loading of images, results in 41 unnecessary page requests.
3. Loading Unnecessary Data
We can’t tell yet for certain, but with 59 page requests and over 5 MB of transfer there’s a pretty good chance some data is being loaded that isn’t really needed.
4. File Sizes Too Large
The total amount of transferred data is 28 times greater than my site. This is certainly a more complex site than mine, but by no means is it even close to 28 times more complex, meaning there is a lot of unnecessary data being transferred.
In the performance analysis results we can see 2,783.51 KB is images, which is a little over half the total data. With 40 images that’s an average of about 68 KB per image, which is fine on face value, so we’ll wait for more information in the next step before deciding if the files are too large.
The next thing we can look at is that there is 2,282.71 KB worth of JS files, 207 KB per file. To contrast, each one of those files is 29 times larger than all the JS on my entire site. The total amount of JS is 326 times more than on my entire site. As I mentioned, the theme demo site is certainly more complex than my own, but in no way is it 326 times more complex. There is major room for decreasing JS file size.
The analysis also shows us that the theme demo site has 1,233.16 KB of CSS, though only 148.18 KB of it is transferred. My personal site has its CSS inline in the HTML which is why it doesn’t appear on the analysis, but for contrast it has a file size of 9.5 KB before processing. Again, the theme demo site is more complex, but it is not 129 times more complex. There is also major room for decreasing CSS file size.
Step 3: Lighthouse Performance Audit
Next up we’re going to use a second performance audit to confirm the information we have so far and help give us more specific direction on the areas that need attention.
Chromium browsers come with a website auditing tool called “Lighthouse”. This is the same tool that powers the Google Page Speed website, but is available directly in the browser.
To access it, with your site still open in an incognito window, go to the Audits tab in the developer tools. Set Device to Mobile, uncheck all the audits except Performance, leave Throttling set to Simulated Fast 3G, 4x CPU Slowdown, and leave Clear storage checked. Click the Run audits button to commence the performance audit:
These are the audit results from my personal page:
As you can see, careful optimization has led to a 100 out of 100 score, with all audits passed. Importantly, note the Time to Interactive value is 1.9 seconds. This audit is on simulated fast 3G rather than slow 3G, but is well below Google’s recommended speed of 5 seconds.
These are the audit results from the theme demo page (identifying info removed):
This is a pretty rough result. The Time to Interactive speed is 12.4 seconds, and without even being on emulated slow 3G it misses Google’s recommended speed by 7.4 seconds.
The Opportunities and Diagnostics sections give us something of a task list to complete, and as expected the tasks line up with the problems we identified in the last section. Each of these sections can be expanded to show more detail on what should be done to speed up the site. We’ll be talking about ways to take action in the next section, but for now let’s take a closer look at a few of the highest priority points in this audit.
Images Load Too Early
First, you’ll see at the top of the opportunities list is Defer offscreen images. This means image files are being loaded before they’re needed, and hence the audit supports what we determined in the last section. It estimates loading images later could save a whopping 10 seconds of load time. Therefore this one optimization alone could potentially bring the Time to Interactive measure down below the 5 second target.
Expanding the section shows that 31 images are being loaded before they are needed, even more than my initial guess of 27. The estimated data that could potentially be saved totals 2,021 KB. That’s huge. (Identifying info removed):
Some Image Files Too Large
The next highest priority opportunity listed estimates that 2.4 seconds of load time could be saved if the site were to “Properly size images”. In the last section we saw that the total file size of all the page’s image was quite substantial, but we couldn’t determine if any individual images were too large. Expanding this section of the audit tells us that in fact 9 images are too large and could be significantly optimized, potentially saving 487 KB (identifying info removed):
Unused CSS Being Loaded
We mentioned earlier it was likely some unnecessary data was being loaded and here we see that’s the case. The audit estimates 0.75 seconds could be saved by deferring, i.e. not loading, unused CSS. Expanding the section shows there are four CSS files not being used either in whole or in part, and 135 KB of data (identifying info removed):
Problem 5, Not a Problem–Passed Audit on Server Speed
I also want to point out something that is working in this theme demo site’s favor, and that is the server it is hosted on is snappy. Note item 6 in the passed audits highlights that the server took only 350ms to respond and start sending back data.
For contrast, here’s an example of a site that failed this audit with its server costing the site an extra half second due to slow response time:
This metric doesn’t give us exact feedback on the quality of a host’s servers. Getting a response in the red doesn’t mean the host is bad, because it can be a configuration option that causes the slow response. However, getting a result in the green rules out that the host is bad, because if it were it wouldn’t be capable of generating an audit passing response time.
Summary of Why That WordPress Site is Slow
Now that we’ve gone through our step-by-step evaluation process, we can identify some of the most prominent reasons the theme demo site we’ve been examining is so slow, categorizing them under the problems 1 through 4 we defined earlier:
1. Loading Files Too Early
31 images are loaded too early, causing a wait for over 2 MB of transfer.
2. Loading Too Many Separate Files
11 JS files and 5 CSS files instead of one of each.
3. Loading Unnecessary Files
135 KB of unused CSS is being loaded.
4. File Sizes Too Large
9 of the 41 images are too large, an excess of 487 KB.
Additional Points
We saw from the TTFB metric in the performance audit that this site’s server responds quickly, so Problem 5 of slow hosting is not an issue for this site. The slow loading was due to other issues.
As to whether caching and a CDN is in use, Problem 6 and Problem 7, that doesn’t need to be a part of an evaluation process because you will already know whether or not you have set up caching and a CDN. (More on these in the next section).
How to Speed Up WordPress: 7 Solutions
Alright, now we’re ready to get into the practical bit where we actually solve the kinds of problems you’ve seen occurring on the theme demo site we’ve been examining. Unfortunately, that site is not mine to fix, but if and when you see the same issues popping up in WordPress sites of your own, here’s what you should do about it.
There are several plugins available that can handle most of the solutions I’m about to lay out. However as it happens there is a free plugin made by SiteGround, the sponsors of this post, that when used in conjunction with their WordPress hosting service, can implement every single one of the following solutions.
See more details about what they offer and get up to 70% off their managed WordPress hosting through Themeforest:
The plugin is named SG Optimizer and can be downloaded from wordpress.org.
Note: to use this plugin you need to be using SiteGround as your host, because it interfaces with WordPress specific configuration and optimization SiteGround performs on their servers.
You can of course use any combination of plugins you like to implement each of the following solutions, but as SG Optimizer can take care of them all I will use it to provide examples.
1. Loading Files Too Early
Solution: Always Lazy Load
Lazy loading is a site optimization technique whereby only the images that are in the visible area of the page, as well as those about to be scrolled to, are loaded right away. We saw in our earlier example that lazy loading can have a huge impact, and can be the difference between a site that loads at the required speed and one that lags in a damaging way.
Lazy loading can be baked right into a theme, but in WordPress it is more typically enabled by way of a plugin.
In the SG Optimizer plugin it can be activated in the Image Optimization section by flicking on these switches:
It’s worth reiterating: if our theme demo page had installed this plugin and flipped those switches, they’d have saved over 2 MB and 10 seconds of loading and quite possibly met the Google recommended time.
2. Loading Too Many Separate Files
Solution: Combine JS and CSS Files
The reason there is no need to have more than one JS file or CSS file is you can take all the separate files and combine them into one through an automated process. This is typically also done with a plugin so that as you add and remove things from your site your CSS and JS can be re-combined as required.
In SG Optimizer you can activate combining in the Frontend Optimization section by flipping the Minify JavaScript Files and Minify CSS Files switches:
3. Loading Unnecessary Data
Solution: Turn Off All But the Essentials
Plugins being active when they aren’t critical to a site’s operation is one of the leading ways to load a whole bunch of CSS and JS files you really don’t need.
Be severe with culling plugins out of your setup. If there is a way you can run your site without a given plugin, do so. Even if they have no associated CSS or JS files to load, every plugin adds processing load to your server. The benefit of each plugin has to be clear and significant, otherwise cut it loose.
Additionally, go through the settings of the plugins you need to keep and see if there are configuration options that allow you to load fewer resources. For example, if a plugin has sub-modules deactivate as many as you can. If it offers custom styles try to avoid them. Be as spartan as possible, remembering that every extra second of load time causes lost visitors.
One additional point is that WordPress itself will automatically load files that add emoji images to your site. This, for most sites, falls squarely into the unnecessary data category. To prevent WordPress loading emojis you can go to SG Optimizer’s Frontend Optimizations area and activate the Disable Emojis option:
4. File Sizes Too Large
Solution Part 1: Minify HTML, JS and CSS
At this point you’ll have reduced the amount of HTML, JS and CSS to a minimum, and combined your JS and CSS into single files. Now you’re ready to make sure those files as as small in size as possible by doing something called minifying.
Minifying text based files like HTML, JS and CSS removes all the white space and line breaks. Doing this can reduce files down to half their former size.
As with combining, minifying for WordPress is done via a plugin so files can be re-minified as required.
In the SG Optimizer plugin this is done in the Frontend Optimization area with the same switches that activate combining. Turn all three on:
Solution Part 2: Compress Images
We saw in our theme demo site examination that 487 KB could have been saved with further image compression.
Generally speaking, images should be properly optimized and compressed before they are added to a site, but sometimes you don’t get the opportunity and have to optimize images as you go.
SG Optimizer can optimize existing and new images via the Image Optimization section. Activate the first switch, and if you need to optimize existing images click the Start optimization button:
Solution Part 3: Use GZIP Compression
I’m sure you will have had the experience of downloading files that have been zipped, i.e. compressed so they are smaller and faster to transfer. Well, effectively the same thing can be done to your site via GZIP, allowing it too to become smaller and faster.
As with many of our solutions so far, on WordPress enabling GZIP is done via a plugin.
In SG Optimizer go to the Environment Controls section and flip this switch:
5. Hosting Service Too Slow
Solution: Choose a Fast, Optimized Host
When you are evaluating hosts try to find the page on their site that gives information about their data centers and technology stack. This is a bit more difficult a topic to pin down than the others we’ve discussed so far, but see what the company has to say about how they ensure their servers deliver sites fast. Do they own their own data center? If so, where is it, and how reliable is it? If not, which company’s data centers are they running on top of? Google Cloud? AWS? How reputable are said data centers?
Something easier to evaluate about a host for WordPress though is whether or not they offer system optimizations made explicitly for WordPress sites. For example, you’ve already seen in the solutions we covered above how SiteGround offers the SG Optimizer plugin to interface with servers that are configured to help optimize WordPress sites. Try to find a host that knows WordPress, and undertakes special measures to cater for it.
6. Not Using Caching
Solution: Use Multiple Layers of Caching
Caching, that is storing of data for faster delivery, can be controlled at multiple levels with a WordPress site. As with many of the solutions above, caching is implemented in WordPress by way of a plugin, and with some hosts there will be control panel settings that need to be activated as well.
Browser Caching
The first of those levels is in the browser itself. Rules can be communicated to the browser about how long it should store files from your site. In SG Optimizer, under the Environment Optimization section, you can flip the Browser Caching switch to extend the duration cached resources are stored in the browser:
You can also have SG Optimizer remove the strings that get added to the end of file names by WordPress by default, which will further assist browser caching. This is done in the Frontend Optimization section:
Server Caching
Depending on the host and caching plugin you are using there will be various kinds of caching that can happen on the server.
By default, every time a person visits a webpage the whole thing has to be generated by WordPress, through combining content from the database in with information from your theme and plugin files. Caching on the server stores a copy of what gets generated so that the next person can just load that stored copy instead of waiting for the page to get created from scratch again.
In the case of using SiteGround hosting plus SG Optimizer you get access to Dynamic Caching and Memcached. (Each of them have to be enabled in the hosting account control panel prior to use with WordPress).
Both are activated in the SG Optimizer plugin’s Super Cacher area, by activating the Dynamic caching switch:
And the Memcached switch:
7. Not Using a CDN
Solution: Use a CDN!
Even if your site loads super quickly for you, that doesn’t necessarily mean it will load as fast for someone further from the server than you are. In order to ensure everyone gets a fast loading experience of your site, the best thing to do is use a CDN, or content delivery network.
A CDN is a network of additional servers all around the world that your website will be duplicated to. Then instead of loading your site from its original data center, a visitor will load it from the nearest CDN point instead.
To illustrate how this can work, the following image depicts both SiteGround’s own data centers, in orange, and the CDN points they integrate with, in blue:
Notice how much closer the CDN servers are to people in Oceania, South America, Africa, and much of Europe & Asia.
In my experience most hosts do not include access to a CDN and it has to be organized separately, or if they do have an integrated CDN there is an additional price to use it. In the case of SiteGround though, use of the integrated CDN (Cloudflare) is included at no extra charge.
One Bonus Solution
Sometimes, after you’ve done all the above, you might find that your site is still too slow, and the reason could be that you just have a badly engineered theme. If the developer of your theme was not conscientious in how they created the code that runs your site, there’s not much that can be done without them doing a full optimization overhaul.
If you think your theme might be the biggest culprit behind your slow site, try temporarily switching out a few different themes and seeing how much of a variance it makes. If changing up themes causes major acceleration in load speed you’ll know you unfortunately got a dud, and it’s time to get a new theme that’s better built for fast loading.
Now You’re Ready to Go Fast
I’ve shared absolutely everything I know from my 12 years of experience on making WordPress sites load super fast, and now all you need to do is implement the evaluation steps and solutions I laid out for you.
Site load speed is still shockingly overlooked given the potentially high costs of poor optimization. It’s critically important and is something every website admin should task themselves with learning intimately and mastering.
Aim for that 100 out of 100 performance audit score, get your visitors enjoying your website in less than a few seconds, then watch your site’s success increase.
Thanks to SiteGround for sponsoring this post–don’t forget you can get up to 70% off their managed WordPress hosting through Themeforest!
No comments:
Post a Comment