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).
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!
Where Site Speed and Rankings Start
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 were OK, 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.
Analyzing Site Load Speed
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. That means it’s a bit slower off the bat in exchange for extensive design control.
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 a much more respectable number.
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. The waterfall report tells us:
- What had to be loaded from the site
- How big those elements were
- Which order they were downloaded
That lets us dig into which parts of the website are causing the issues.
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 the 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.
This caused a tangible choke point in the site’s ability to load, which is why I tackled it first.
Optimizing images is one of the most obvious factors on site speed as it pertains to SEO ranking factors, but sometimes a few unoptimized ones can sneak past your attention.
I once witnessed an agency create a page with an 11MB image. Oof.
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. Common go-to compression tools have been known to over-do it now and again.
So our options are to optimize the image appropriately, or to find a new one and optimize that one. Right now it clocks in at over 800KB all on its own, and it needs to be no more than 250KB—hopefully 200KB or fewer.
What happened when I optimized the giant testimonial image? It pushed site speed to sit between 1.1 and 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.
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:
- Enabling Gzip compression
- Optimizing 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 take you 80% of the way there. 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 the plugins as low as possible so that people don’t need to load all of their data with the site (in general). That’s why it’s important to add WordPress plugins that help your site without adding too many, which would make it 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.
Useful Performance Plugins
Try out these plugins. Many of them will make a marginal 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 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.
How My Hosting Provider Solved Desktop Performance (Sort of)
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.
This particular plugin accomplished most of what I needed, taking a look back at the list:
- Gzip compression
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.
Instead of installing 5 or 6 performance plugins, I could make it work with just two. Even though the SiteGround Optimizer might not get 100% of the results in for each specific function, the trade-off of getting 75% 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. The key points you should take away to improve your own website are:
- 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 wifi connections anyway because their data plans are overpriced and punitive, and that’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. There shouldn’t be any “compatibility” issues there.
In combination, those factors create misleading numbers. I spent hours making optimizations to my mobile site—cutting it down to less than 1MB of memory—before realizing it.
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 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 absolutely destroy your hard-won rankings as a result.
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.
So we’ll stay away from that for now, thank you very much.
I hope you feel more confident approaching website improvements after reading this case study. Every website will present different challenges, but feel free to return to this page to get some ideas on where to look next.