Search engine optimization drives the foundation of your site’s traffic, and site speed drives your rankings in the search engine results (all other things being equal). That’s why it’s so important to fix website speed problems when they come up. It’s incredibly important for your rankings as well as your conversion optimization rate. According to the Think With Google site speed benchmark report, visitors are 90% more likely to abandon your site if your page load speed reaches 5 seconds.
That’s a big deal—and also why I wrote this case study.
Achieving a great speed is possible, especially for small and medium business websites. In fact, it might even have an advantage over corporate enterprise sites, since those tend to be weighed down by dozens of plugins and top-heavy tracking codes.
Want to see how I got my own WordPress site down to a 1-second load time even with Divi, a top-heavy visual builder?
Then let’s get to it!
Benchmark Your Site Speed First
I tested out my site speed right after moving my site from Squarespace to WordPress, rebuilding it from the ground up on Divi.
The results ranged from decent to good, but not great: it ranged from 2.5 – 4.5 seconds. I’ve walked into client projects where websites took over 12 seconds to load, so I wasn’t panicking… but there was definitely room for improvement.
You’ll encounter this kind of hurdle with your site too. Here’s how I analyzed it.
Fix Website Speed Problems with Analysis
I used a few different site speed tools (GTmetrix and Pingdom site speed tests) and they both reported consistent numbers:
- The site was 3.48 MB in size
- It took 47 requests to finish loading
- The site took at least 2.5 seconds to load (but sometimes longer)
- Several images weren’t optimized
- There was no content delivery network in place
The site is already running on Divi, which uses a lot of shortcodes to get customizable designs in lieu of lean, purpose-built code (custom coding is expensive and often inaccessible, hence the visual builder). That means it’s a bit slower off the bat in exchange for extensive design control, costing $200 for a lifetime license vs. thousands or tens of thousands of dollars for a custom site without flexibility.
That was a conscious decision for the website. Divi’s shortcodes bring some anticipated extra page loading time, but that can be whittled down to low number by sticking to the fundamentals.
What the Waterfall Report Says
There were a few elements living on the site itself that could be addressed immediately, and that became apparent in the site speed’s waterfall report, which you can find on the free versions of both GTmetrix and Pingdom. The waterfall report tells us:
- What had to be loaded from the site
- How big those elements were
- In which order they were downloaded
That lets us identify specific areas where we need to fix website speed issues instead of just guessing.
And—overall—things are looking pretty good, according to that report. But there are a few images in particular that need optimizing:
- A single large testimonial banner image
- Three feature blog images
The testimonial image was a known entity to me; I was afraid of over-optimizing it (which would result in extreme pixelation) and was keeping an eye on it. But the three blog images came as a surprise.
It turns out that even though these feature images appeared as thumbnails on the homepage as previews for my three latest blog posts, the site loaded them at full size before shrinking them down again. One of the images was also 1.1MB, which is nuts. This image just hadn’t been compressed like the rest.
This caused a tangible choke point in the site’s ability to load. It’s also an easy fix, so I tackled it first.
Optimize Images to Fix Website Speed
Optimizing images is one of the most obvious factors for site speed, but sometimes a few unoptimized ones can sneak past your attention, like the 1.1MB image above. As long as check in on your website now and again, you’ll find find these and fix them without issues.
I once witnessed an agency create a page with an 11MB image. Run away if you see someone do that to your site!
Anyway, after optimizing just the 3 thumbnails on the homepage, the total size of the page dropped from 3.4MB to 2.1MB. A full third of the page no longer had to be loaded, boosting the site’s speed by that much—from a range of 2.5 or 3 seconds to the range of 1.2 to 1.8 seconds.
Even the Google site speed test gave the homepage a score of 97%. Now that’s what I’m talking about.
But the testimonial image also needed optimizing. It wasn’t a high-quality image in the first place, so I had to be careful about compressing it beyond a reasonable limit. Common go-to compression tools have been known to over-do it now and again, and it wouldn’t do to fix website speed at the expense of the website looking unprofessional.
So my options were to optimize the image appropriately, or to find a new one and optimize that one. It was 800KB all on its own, and it needed to be no more than 250KB—hopefully 200KB or fewer. What happened when I optimized the giant testimonial image? It pushed my site speed from 1.2-1.8 seconds down to a range of 1.1-1.5 seconds—a marginal but meaningful improvement, since it’s on the homepage.
We’ll revisit image optimization for mobile layouts, but simple image optimization has taken us down by at least a whole second of load time, which is fantastic. It just goes to show that minding the fundamentals can generate excellent results.
Utilizing Performance Plugins
We need to take a moment to talk about performance-enhancing plugins for WordPress.
… Sorry. Couldn’t resist.
Anyway, there are a few core things that most speed tests will tell you to do:
- Enable Gzip compression
- Optimize images
We’ve covered the last one on that list, but the other three are a bit trickier. In fact, they usually require straight-up developer work. I’m not a developer, and the odds are pretty good that you aren’t either.
There are plenty of plugins out there that can help you fix website speed issues 80% of the time. Plugins aren’t purpose-built for your website and might not operate at 100% performance when compared directly with purpose-built code, but they can definitely get the job done—and many of them are free.
But here’s the rub: plugins require site memory to run as well, even though these ones are supposed to help with site speed performance. It’s better to keep plugins to as few as possible to keep your website lean. Plugin data loads every time someone visits your website; each one adds to your site’s digital mass, so to speak. Too many plugins make websites slow and cumbersome.
That’s why it’s super important to test your site’s speed every time you activate one such plugin: you need to make sure the plugin’s own weight doesn’t cancel out the speed improvement it creates. We’ll cover which ones are worth checking out below.
Useful Performance Plugins
Try out these plugins. Many of them will make a decent improvement to your site, which should create a noticeable effect in aggregate.
- BJ Lazy Load
- WP Super Cache
- WP Smushit
- Autoptomize or Better WordPress Minify
- Enable Gzip Compression
We need performance plugins to improve site speed, but we also need to be careful about how many of them we install on the site—or else the sheer weight of them could cancel out the benefits.
So how do you strike the right balance?
Testing, in a word. Test your site speed before and after flipping the switch on each plugin, and test your speed with all of them active to make sure that they don’t conflict with each other. Try not to install more than 15, but keep it to even fewer if you can. Be ruthless about it.
Hosting Can Fix Website Speed More Often Than Not
Striking the right balance with performance plugins can be tricky. But there might be another way, depending on your provider. There was for me.
As it turns out, my hosting provider installs a single performance optimization plugin on its own with every WordPress setup. This is the SiteGround Optimizer plugin, and it only works with websites using the SiteGround hosting service (which offers good prices and good service).
This particular plugin accomplished most of what I needed, including:
- Gzip compression
The reason why it became my plugin of choice was because it did achieved 80% of the results that a collection of performance plugins could while only requiring a fraction of the “weight.” A single plugin pulling quadruple duty won’t bog down the website as much as 4 different plugins would if they ran at the same time. Using one plugin drastically cut down the chance of experiencing a conflict between plugins, which is a common experience for WordPress users around the world.
Since the SiteGround Optimizer’s performance was only so-so on Gzip compression, I tested out the site with that plugin running everything else, activating a specialty plugin for Gzip compression instead.
The results were good—it shaved an extra 0.3 seconds off the page load time. That was the sweet spot.
Installing two performance plugins instead of five or six was the most efficient way to fix website speed problems, clearly. Even though the SiteGround Optimizer might not get 100% of the results in for each specific function, the trade-off of getting 80% of their efficiency without the weight of another 5 plugins was better for the site’s overall speed.
The lesson learned? Plugins can nudge your site toward better speeds, but picking a good hosting provider will move it by a mile.
Concluding the Site Speed Case Study + FAQ
Site speed is an integral part of SEO, and every part of your website factors into that end result. These are the key points you should take away to improve your own website:
- Picking the right hosting service is critical. It might be worth upgrading to a new one.
- Always review your images for optimization, but don’t make them too pixelated.
- Create separate, dedicated mobile versions of your website if possible.
- Use performance-enhancing plugins, but not too many.
- Websites made with visual builders can still be fast (as you’ve seen here).
Stick to those lessons and you’ll be well on your way to speeding up your website in no time!
Having said all that, I did leave out a few things: mobile speed and content delivery networks. I’ve explained why in the two sections below.
I hope this has been a useful read. It’s not a comprehensive textbook, but I hope it shows you how to approach site speed improvement with practicality in mind, especially if you’re not a software developer or a particularly technical marketer.
FAQ #1: Why Aren’t You Looking at the Mobile Site?
Great question. Unfortunately the tools at my disposal don’t test mobile connections very well. In reality, my mobile site takes about 1.5-1.7 seconds to load, but tests like GTmetrix, Think With Google, and Pingdom don’t reflect that reality.
- Most speed tests try to emulate a 3G connection instead of a 4G or 5G connection, which artificially doubles or triples the actual measurable load time on test results.
- Most Canadians use their mobile devices over wi-fi connections anyway because their data plans are overpriced and punitive. It’s even faster than a 4G connection.
- Most importantly, my site runs on the HTTP/2 protocol instead of HTTP/1.1. The difference is that my site can load faster by sending multiple streams of data to the user’s device to cut load times in half (at least), but the speed tests I’ve used don’t seem to reflect that, despite real-world tests with emptied caches. There shouldn’t be any “compatibility” issues there, but there were at the time of testing.
In combination, those factors create misleading numbers for mobile speed tests. I spent hours making optimizations to my mobile site—cutting it down to less than 1MB of memory—before realizing that I was just spinning my wheels.
FAQ #2: Why Aren’t You Looking at Content Delivery Networks?
I’m not going to implement GTmetrix’s suggestion to implement a content delivery network because they serve content from a different IP address than your actual server.
On free CDN services like Cloudflare’s entry-level plan, the IP address changes frequently—perhaps even more than once per day. That’s a substantial “spam signal” in Google’s eyes, and it could destroy your hard-won rankings as a result. I’m not saying it definitely will, but I didn’t feel like taking the risk at the time of testing.
Paid subscriptions should give you a dedicated IP address, but your site could still drop significantly—even dramatically—for several weeks or months while search engines begin to trust those new IP addresses the content delivery network. Heaven forbid the IP addresses change again any time soon after that, either.
I hope you feel more confident about trying to fix website speed issues for yourself! Every website will present different challenges, but feel free to return to this page to get some ideas on where to look next.