In January 2020, the average load time for a page of my main site, The Broke Backpacker, was 12.5 seconds. One year later, the average load time for the same site was 1.5 seconds.
That’s an improvement of 718% for load times, which is a shockingly high number!
So how did I do it? How did I take a website that was slower than a herd of turtles stampeding through peanut butter and turn it into a sexy racecar? That’s exactly what I’m going to share today.
Over the course of this case study, I’m going to talk about the entire process of optimizing The Broke Backpacker’s site speed, from auditing the site to finding the right developers to the final launch.
I will also be sharing some actual gains the site made in the rankings following the optimisations. SPOILER ALERT: we did very well in the December Core Update.
By the end of this case study, you will have a good idea of what it takes to get performance boosts like I did and how those convert seamlessly into new traffic.
Speed is more important than ever in 2021! Come with me on an epic journey and I’ll show you why, amigos.
How Was the Site Before?
I’m not going to sugar coat this part folks: The Broke Backpacker was
slow excruciating. According to Google Analytics’ Page Speed report, the average page load time was 12.5 seconds on January 1st, 2020.
Let me put that number into context…
A healthy 35-year-old male can do the 100-meter dash in around 13 seconds.
It takes 10 seconds to tie a tie.
The world record for solving a rubix cube is 5.66 seconds. (Ok, that one is a bit irrelevant I know.)
Point being: 12.5 seconds is a ridiculous amount of time for a page to load.
The site speed was obviously causing problems as well. Much of our flagship content (our super detailed backpacking guides) were taking ages to load because they were over 15,000 words long and contained enormous images. TTI, which stands for “Time to Interactive,” was sometimes over 20 seconds; that means it took OVER 20 SECONDS for a page to become responsive and for users to be able to make inputs.
Don’t even get me started on mobile either. Mobile, notorious for being prone to site speed issues due to smaller processors, was embarrassingly bad. If a friend wanted to see my site, I would have to open the page, put the phone down, and then wait.
TL;DR: Site speed was a shitshow. Something had to be done about it.
Why Site Speed Matters
It’s one thing for my friends to be less-than-impressed when my site doesn’t load on my phone; it’s a completely different story though if Google is also disappointed.
And guess what: Google does notice these things. If your site loads slowly, Google will take note and will judge it severely.
Let’s go back to my earlier story about me and my mates. Let’s say I’m trying to show them a page; it won’t load, they’re annoyed, and I’m a bit embarrassed. Luckily, they’re good sorts and wait for the damn thing (I ply them with beers).
But what if they’re not my friends? What if they’re just another stranger browsing the web looking for top quality content? If they found my site and had to deal with the crazy load times, they wouldn’t stick around; they’d just straight bounce.
Friends: bouncing is bad because it sends poor user engagement signals to Google.
You see, Google monitors user behaviour when someone visits a site. They keep an eye on clicks, on-page time, scroll depth, and several other user engagement factors. All of these then contribute to the user experience, which is a confirmed ranking factor.
So if someone visits your site and immediately leaves because of a poor user experience – in this case, poor load times – Google takes note and will penalise you. They will lump you in with the other poor user experience sites which live comfortable and carefree directly at the bottom of the SERP.
Yes, if your site loads slowly, your rankings will fall.
There was no way I was about to let my precious posts fall to the wayside. I spent years of blood, sweat, and tears improving the SEO of The Broke Backpacker, and I’d be damned if I let it perish because of poor load times!
What Was Causing Such Poor Load Times?
I’ll be honest, I wasn’t entirely sure why the site was so slow at the time. I knew that media played a huge role in load times and that the massive library of plugins wasn’t helping much either. But was there more to it than these?
I asked several developers who were kind enough to peek under the hood of the site to let me know what they thought. Most gave me the same answer: it was a monster. A bloated, Frankensteinian-like fiend that had been modified so many times (and so poorly) over the years that it no longer resembled anything beautiful or normal. Frankly, no one was surprised it loaded so horribly.
Here are a few common observations among the developers:
- Too many redundant and cumbersome plugins.
- Unoptimised, uncompressed images.
- Lack of lazy loading, particularly on embed elements like video.
- Poor handling of CSS and JS.
- A poorly-developed theme.
- An inconsistent server and CDN.
- Third-party scripts gone wild.
These were the most pressing issues although there were a host of other potential pain points as well. It might have been possible to tackle these on my own but it seemed that the issue of site speed was too big for just me or my team to handle.
So I decided to bring in the big guns.
I figured that this overhaul would take serious time and attention, not to mention a serious investment. I would need to hire experts in the field, real aces that could take my poor – wretched website and turn into the lightning-fast speed demon that it ought to be.
Overview of What We Did
Alright, enough with the backstory – let’s get to the real meat of this article: overhauling the site.
After getting in contact with my hosting provider, WPEngine (who has always steered me in the right direction), they connected me with a proper web design agency. After a bit of negotiating, we shook hands and got to planning. This theme overhaul would cost me a pretty penny but it would all be worth it in the end (just wait for the results…)
Over the next 6 months, my team and I would work closely with this agency to completely redo The Broke Backpacker. Our goal: make it fast as hell and give it a long overdue fresh coat of paint.
We aimed to bring the average load time to less than 3 seconds: a 300% improvement over the current 12.5 seconds load times. Would we be able to do this?
For the sake of brevity, I’m not going to get into the nitty-gritty and talk about every single step we took; that would make for a tedious article. Rather, I’m going to provide some broad strokes now so you have an idea of what a theme overhaul entails as well as what it’s like to work with an enterprise-level marketing agency.
A Quick Note on Methodology:
During the actual theme overhaul, benchmarks were taken using Google’s PageSpeed Insights tool. PSI analyses a page based upon several different factors, such as Time to First Byte, Contentful Paint, and Cumulative Layout Shift. It then assigns a 0-100 score to the page based upon its performance.
This case study relies less upon PSI though and uses Google Analytics Page Speed report to illustrate improvements. It is a slightly different tool but more or less reflects how the site speed has developed over time.
I will be referring to both PSI and GA’s Page Speed report throughout this article – two important tools for any online business.
Phase 1 – Scoping and Initial Auditing
First and foremost, the dev team (whom we worked most closely with at the marketing agency) had to take a look at the backend of the site and see what was going on. Their first impressions were that the site was extremely bloated and that it was being slowed down by a lot of junk scripts and code (shocker).
The good news was that there were some very obvious optimisations that could be done right out of the gate. After taking an initial benchmark of initial site load times, they got to work.
The most crucial part of this stage was the plugin audit. By cleansing plugins that we no longer needed and integrating others into the theme itself, we hoped to reduce our plugin usage from 72 (a ghastly amount) to less than 10. Such an enormous payload drop would most definitely speed up load times.
The plugin audit itself was quite simple: the devs made a list of all the plugins in-use with their thoughts on whether they were necessary or not. Some plugins were clearly not being used, were way too heavy on the site, or could easily be handled by the new theme. After this, we managed to remove over 30 useless plugins and slated several for integration.
The devs also did a similar audit to third-party scripts. They stripped the ones that were no longer being used and redeployed others, either putting them directly into the theme or injecting them using Google Tag Manager.
Upon finishing this initial audit and deploying the changes, we immediately saw 35% faster load times. Simply cleaning house made the site 4.5 seconds faster. We were well on our way to our goal.
Phase 2 – Creative Handover + Functionality
This phase was less about pure performance and more about aesthetics. We thought that if we were going to be overhauling the site (and paying a lot for it), why not update the look as well? Granted, we didn’t want to change the site completely but a fresh coat of paint would do the ol’ boy good.
In terms of the design, we decided to make things simple. By keeping the overall look of the site clean and not incorporating any sort of complicated element, we made sure the site would remain fast. Using complex visuals and functionalities, things that might involve additional JS scripts or API calls, would only complicate things further. We didn’t want to stress about these.
I’m going to skip explaining the actual design process because there’s nothing that needs to be highlighted. All that I’ll say is that if you’re handling UI mockups on your own (these are like the visual templates for the site) make sure someone capable is handling them. UI mockups are important and it can be a real pain to redo if they aren’t up to scratch.
Whilst the dev team wasn’t really active during this phase, they did manage to set up and calibrate a new CDN for us. They opted for Cloudflare, which is one of the most trusted CDN providers in the game. Upon their suggestion, we went with the Pro version for a reasonable $20 more per month because it offered a cool feature called Polish that helps optimize images further.
Upon deploying Cloudflare’s Polish feature, average load times were a modest 15% faster.
Phase 3 – Development
Once the creative was finalised and we made sure that all the functionalities we wanted would be incorporated into the new site, only one thing remained: building the damn thing. This was the part that we were all excited about.
The dev team said it would take roughly two weeks to make a working build of the new theme. They would be, of course, doing this on a staging site completely separate from the live site as to not interrupt business. We left them to their work in eager anticipation.
Because the developers worked on their own, I wasn’t exactly sure what they were going to do. But I did know it was going to be intensive.
Starting from a skeleton theme (the most basic theme you can imagine with minimal framework), they coded everything from the ground up. The templates, the nav, header, footer, and on-page elements; everything was made using custom code. To keep it fast, no CSS libraries were imported whatsoever; everything was 100% new and 100% The Broke Backpacker. The CSS and JS that were also present were minified as well.
Two weeks later, they delivered us the first draft of the new site, and let me tell you: it was a powerful moment. The new site, even with only a semi-complete theme grafted on, was a thing of beauty: elegant, functional, modular – all of these and more.
Most importantly though, the new theme was FAST. I mean, really fucking fast; faster than I ever expected.
Initial benchmarks for the new theme on staging put it at 50% faster than the live site, all thanks to clean, efficient coding. Mind you, this was still staging, which is a closed environment and doesn’t react exactly like the live site, but it was still a great sign. The next step was just to provide feedback and refine the theme before ultimately pushing it live.
Phase 4 – QA phase + Final Approval
We were on the home stretch now – a brand new, fully-fledged theme was within our grasps. We just had to make sure that it was as close to ready as possible. Thus we entered the QA Phase or “Quality Assurance”.
Despite the site looking sexy as all hell and running at top speeds, there were still bugs. The purpose of the QA phase was to find and fix these.
Bugs were to be expected. You can’t, in all frankness, expect a developer to code every single feature of a site on the first try; that requires a level of intimacy with the site that only those who have worked with on it for years would have. At this point, we just had to do our due diligence and make sure everything worked as we wanted.
For the next two weeks, we combed the site for any possible error. This basically meant telling my team to drop everything that they were doing and to assign them areas of the site to handle. We needed to check as many posts as possible in a relatively short amount of time. We used an extension called Bugherd to provide feedback.
Much to the surprise (and perhaps dread) of the devs, we dropped a mountain of tickets on their desks with things that needed to be changed. My advice for anyone who is in a similar situation: be very thorough in your inspection but DO understand that your site might not function exactly as it did before. Point out inconsistencies but be prepared to accept new features as they are.
Fast forward two more weeks after the devs implemented our requests and a second smaller QA phase was finished and we were ready to go live with the new theme. This was the moment we all waited for…
Twas the moment of truth: would the new site in a live environment perform as well as we expected it to? Well, we wouldn’t know until we tried!
We all sat with bated breath as the dev team pushed the new theme live. This process would require about a day of waiting as the staging environment was copied over to the live site and the marketing agency ran their performance checks. It was important to make sure that there were no unforeseen issues, like 404s, crawl errors, random robots.txt edits, or anything else of that nature.
In the end, there were no complications. The transition was smooth and we officially had a brand new site!
And how fast was it in the real world? Even better than we thought. With the extra help from the CDN, a fine-tuned server, and proper caching, we managed to get the average site load time down to 3 seconds: the exact mark we were going for!
In the biz, we call that mission fucking complete.
But wait, there’s more…
Ads: Are They Worth the Bloat?
Despite the site being 300% faster than it was before and looking better than ever, I was not satisfied. Having gotten a taste for how quick it could be, I wanted it to be even quicker. How was I supposed to make the site faster though?
I haven’t mentioned this yet but one thing that every single developer I worked with harped on about was ads.
Scripts from third-party ad providers, such as Ezoic, Mediavine, and Adsense, are notorious for slowing down sites. This is because these scripts need to make dozens (or sometimes hundreds) of requests whilst bidding is taking place. On top of that, all of the visuals need to load as well. These processes all cause massive blocking time.
The Broke Backpacker has run ads for a long time and it has been a very steady source of income. But sample testing on the staging site pegged them at causing the site to load 30% slower.
No amount of tweaking seemed to make them any less burdensome either. It didn’t matter if we used a blocker code to stop the ads on one page whilst we left them live on another, or if we turned down the overall frequency. The mere presence of the script on the site was causing universal slowdown. The ad provider, who shall remain confidential, was also unwilling to help us find a way to limit the effects of the script.
I had a difficult decision on my hands: was the presence of ads and the income they generated worth the 30% hit to site speed?
I decided no, they weren’t worth the pain. I gambled that the extra boost in site speed would lead to higher SERP rankings, more traffic, and that the lack of ads would increase user engagement and, consequently, conversions. Both would make up for the lack of ad revenue.
How Are the Load Times Without Any Ads?
It’s fast guys: real fuckin’ fast. It was fast before we got rid of the ads, and now that they are gone, it’s even faster! We’re talking ‘Roadrunner just cased the crack den’ fast.
After being ad-free for about a month and collecting some real-world data, it became clear that my initial projections were correct. I retested some pages on PageSpeed Insights and the scores all came out as I thought they would (30% better than when ads were live).
But if we refer to Google Analytics and the data there, site speed looks to have improved even more. According to GA, since removing our ads, the average load time is roughly HALF of what it was before. Load times were now a blistering 1.5 seconds. So, the ads were causing more like a 50% hit on load times.
Let’s take a moment to recap how far we’ve gone since starting this theme overall. It really is quite remarkable.
Before we started this theme overhaul, our average load time was 12.5 seconds. After several rounds of optimisations, a brand new theme, and the removal of ads, that number has dropped down to 1.5 seconds.
Referring to original benchmarks set using Google PageSpeed Insights, we were averaging something like 28 on desktop and 33 on mobile. We’re now scoring in the low 90s on mobile and close to 100 on desktop.
That’s a 718% decrease in average load times according to GA and 178% increase in PageSpeed Insight scores. With an average mobile score of 90 on PGI, we also jumped to the 93% percentile as well, which meant that we were faster than 93% of the rest of the web.
This was all thanks to:
- Stripping unnecessary plugins and third-party scripts.
- Using a good CDN.
- Optimising our server and caching.
- Not relying upon external CSS libraries like Bootstrap.
- Building the theme from scratch.
- Minifying CSS and JS.
- Optimising and compressing images (we did this after the overhaul actually).
- Working with a team of professional developers and designers.
- Turning off ads
How Do We Compare to the Rest of the Web?
I’m going to throw out a couple of averages in order to provide a bit more perspective:
What is the average Speed Index (load time) on desktop? 4.7 seconds
What is the average Speed Index (load time) on mobile? 11.4 seconds*
What is the average size of a webpage? 1.872 mb
What is the average amount of requests? 72
What is TBB’s Speed Index (load time) on desktop? 0.78 seconds
What is TBB’s Speed Index (load time) on mobile? 2.56 seconds
What is the average size of a TBB page? 635kb
What is the average amount of requests from TBB? 48
You might be asking yourself now: “How fast should my own site load according to Google?”
Well, there’s not a simple answer to this since Google looks at load times relatively. When I say relatively, I mean it uses field data from all the sites in its index and creates scores or standards based upon how they perform. This means that you might have a perfect score today but in three months it could go down because everyone else got faster.
This also means that you should be looking at your competitors when optimising for site speed. If sites in your niche are all fast, you’ll need to be fast as well to keep up. If sites in your niche are slower though, you could potentially pull ahead of the pack with some optimisations. Try out this online tool to see how other sites score on PSI in your niche.
In general, I’d recommend that your site loads in less than 3 seconds at the very least. It’s better if it’s less than 2 seconds though.
I also wouldn’t get too caught up scoring a perfect 100 on Google PageSpeed Insights: this is very difficult to do and is not worth the extra hassle for large sites. Scoring 90 or above is still very good and is probably enough.
*Web averages come from Machmetric. TBB averages come from two groups of posts, 8-10 posts each.
The Moment of Truth: The Core Update
So we’ve wrapped up the bulk of the theme overhaul project and I got what I wanted out of it – that is speed. We got SERIOUS speed. I’d made the site super fast but at the cost of five figures worth of expenses, six months of my time, and a terminated advertisement contract. All of that would be for naught if the site didn’t start ranking higher on the SERPs as well.
Would it all be worth the pain?
Fast forward a couple of months and it’s the first week of December. We’re gearing up for the holiday season when one fateful day, we hear the news: a new Google core update was on the way. And from the sound of things, it was going to a big one.
This would be a defining moment for us. Would Google like our flashy new updates? We battened down the hatches and prepared for the worst.
My friends: twas a glorious update for us. Traffic, which had been slowly but steadily rising since the end of November, rose steeply. In the first few weeks, we were looking at a 50% increase in organic clicks. By the end of December, daily traffic had almost DOUBLED compared to October averages.
And the growth didn’t stop there either; within the next three months, it would continue to grow. In March 2021, we got 200% more organic clicks than we did in October 2020.
An unexpected development was also Google Discover, which is something we never really noticed. Whilst we won big on Search, we arguably won even bigger on Discover. Discover traffic suddenly sprang out of the ground like a burst oil vein and we were accruing hundreds of thousands of clicks seemingly overnight. At one point, a quarter of all site traffic came just from Discover. Such a turn of events lead me to dive deeper into Google Discover; it’s something which will take moretesting to further optimise…
Needless to say, we had won the December Core Update. It seems that my gamble had paid off dividends: I had thrown everything into overhauling the site and improving site speed, and it seemed that Google liked what it saw.
There is not a whole lot left to do in terms of making the site faster. We could tweak the source code further, run another image audit to remove anything gargantuan, and maybe make our content a bit shorter. In particular, I’d be curious to see if there was a way to use ads on the site without taking a 30% hit to load times. (Let me know if you have any ideas in the comment section!)
But honestly, we’re at the point of diminishing returns. Anything we do is going to require lots of money and will yield subpar results. If I was trying to get the site speed to less than a second or score a perfect 100 PageSpeed Insights, it would be purely for the thrill of it and not for the potential ranking benefits.
No, my site is fast enough at the moment; the increased traffic following the core update is evidence of that. I’m satisfied for the moment believing that what I did to improve the site appeased the Google gods. 718% faster load times and 200% more traffic is downright shitting spectacular; now I need to focus my efforts on other traffic channels, such as email marketing.
If your site is struggling to load quickly and you’ve never considered optimising before, I highly recommend that you do so ASAP. Load time and Core Web Vitals (Google’s way of assessing user experience) are only going to become more and more important in the coming future. Now is the time to start focusing on these things.
If you’re a blogger or small scale business, I’d recommend optimising using one of many online resources. Elementor has a fantastic article on the subject and you don’t have to actually use Elementor to gain some insight from it.
If you’re a mid to large scale business and are looking to be aggressive, feel free to reach out to me for recommendations. I can connect you with quite a few agencies that specialise in this sort of work.
Until next time everyone!