I want to keep this case study anonymous, so I blacked out the website address. Both of these screenshots are site speed scores for the homepage of the site, run about a month apart, both for desktop.
Before jumping straight into things, I want to acknowledge that the jump from a score of 7 to 52 isn’t as impressive as it could have been. The thing is, we actually got the score up to 82, but in doing so, we messed up some of our A/B testing and tracking, and had to redo some of the fixes we’d implemented. That’s the biggest takeaway I want to impress upon people who are working on improving their site speed: you have to be careful not to break any tests, or mess up your tracking. And if you run display ads, there are certain improvements that you just can’t make. This case study is about optimizing your site as much as you can without breaking anything.
Taking over an existing website is always tricky, especially if it hasn’t had SEO work done in the past. You never know quite what you’re going to find when you start digging into the code
That was the case for this financial services website. The website was built on REACT and had been poorly maintained (from an SEO perspective, the coding was good). It took quite a while to fix some of the major technical SEO issues (404s, missing metas/alts, orphaned pages, etc). But at that point, I faced a much larger challenge: an abysmal site speed score, and the upcoming rollout of Google’s Core Web Vitals on the horizon.
The Problem
The biggest problem for this site was a ton of unused JS running on initial load of the page, as well as poorly-optimized images, and excessive tags logged in Google Tag Manager. On top of that, since the site was designed using Single Page Applications, all of the scripts on all different pages would run on initial load of any page, even if the script wasn’t in use on the page. All of this combined ensured that every single page scored terribly on Page Speed Insights, as well as the Core Web Vitals reports.
If you need a refresher on Google’s Core Web Vitals, you can find a simple overview here.
As you can see from this screenshot, the scores were all way too high. The only one that scored well, CLS, was helpful, but that’s easily the least important of the CWVs. In particular, CLP and FID are weighted far more heavily.
The Tactics
I dug into things further to see what, exactly, was causing the issues. As I mentioned above, it was a lot to do with bulky JS and tags from GTM all loading as soon as the page was opened.
This area is pretty helpful as a place to begin, but you can’t take it as gospel. As I mentioned above, because the site was built using SPAs, all our JS loaded for every page. So most of those scripts that are marked as “unused” at the top were actually in use, just not on that specific page. So I couldn’t just remove them entirely, or it would ruin our tracking or tests. Instead, we had to get creative and defer specific scripts per page. That way they could still run when needed, but wouldn’t impact the speed score when they weren’t.
The other fixes were relatively simple. We removed the specified CSS and render-blocking resources. We not only updated our images, but ensured that those near the bottom of the page would lazy-load so as to save on initial loading time. But not too high up the page, or it would impact the FCP and LCP scores.
We had some research and work to do around what JS we were using and how we used it. We managed to bundle things together so they would all run at once (even better if we could defer them to run after initial page load). But that didn’t work with every page, as we ran some intensive A/B tests that had to be served immediately or it would create an awful UX experience and ruin the integrity of our tests.
Another bulky section of code were the Google Tag Manager tags in the code. We had an old, outdated tagging system from an old agency that didn’t serve us well anymore. So the team went through and deleted as many old tags as possible without ruining our tracking.
The Results
Site Speed Results:
Once we rolled out all the code updates, our site speed score jumped from 7 to 52 immediately.
This indicates a dramatic increase in reactivity, as well as a better experience for users on site.
Overall Traffic Results:
This is in conjunction with my SEO/content marketing results for the same site. You can read that case study here.
You can see the graphs at the beginning of the article. Our organic traffic rose exponentially through 2020 and into the start of 2021. You can read more about the ups and downs in the middle in the notes below.
Overall, the tactics I implemented across the site drove the following results:
Sessions: When I started in September of 2019, the website had roughly 5k a month. By January of 2021, it increased by 540%
New Users: In September of 2019, the website had roughly 2.5k new users a month. By January of 2021, it increased by 820%.
Pageviews: In September of 2019, the website gathered roughly 8.7k pageviews in a month. By January of 2021, it increased by 360%.
Some Additional Notes
As I noted at the top, this isn’t as impressive as it could be. But when it comes to site speed (and, honestly, SEO in general) you have to split your optimization goals with your overall marketing goals. If you run display ads or A/B tests it may not be possible to bring your site speed score up as high as you may like. That’s okay!
If your website is otherwise well-optimized and your content is good and helpful, you can still rank. Site speed isn’t the end-all, be-all for ranking. Of course, a good site speed score can help.
If you want to learn more about SEO, read my overview here! And if you’re interested in an SEO audit or other services, book a free consultation call to learn how I can help.
Pink Hair Digital 