After competing in the Northern European Page Speed race last year we boosted the performance of our website but we didn’t want to drop the ball after the nice achievements we accomplished. But how do you know what the impact is of your new build feature, added content to your site or how to know if your website is still performing after every release? The answer is measure, measure, and measure because to measure is to know.
That’s why we teamed up with SpeedCurve as they offer the right selection of products like synthetic webpage tests and performance audits which suit our current needs. Here’s the story of how we’re in the lead of keeping our website high performant.
We started with setting up dashboards for almost all our types of pages, like the homepage, overview and detail pages. We created customized graphs with Lighthouse scores, rendering times, content sizes and content requests as these are the main indicators for performance.
Lighthouse analyzes web pages, collecting modern performance metrics and insights on developer best practices.
All results are generated by mobile synthetic webpage tests. Why mobile and why synthetic? Mobile devices tend to have the slowest network connection. If your page is fast on mobile, it sure is on tablet or desktop with wifi or cabled connections. You don’t want to lose mobile users because it takes to long for your page to load.
We also decided to use synthetic tests as these will audit your page as a new visitor. If you would use real user monitoring (LUX), the average line will flatten out as the recurring visitors will already have certain resources cached which improves their performance.
Below you will see two of our graphs on the homepage dashboard. We will talk about the interesting drop in performance in a few moments.
Defining performance budgets
A performance budget is a set of limits imposed on metrics that affect site performance. To keep our performance from regressing over time, we set up budgets for key metrics like the Lighthouse performance score, Speed Index, content size and content requests.
The Speed Index is the average time at which visible parts of the page are displayed. It is expressed in seconds and dependent on size of the view port.
We defined different budgets for our page types as they don’t all have the same performance and content. If you are just beginning with budgets start with budgets you can maintain and set them higher whilst improving your website. Don’t set the bar too high with budgets you can’t reach, that’s not motivating.
After setting the budgets, SpeedCurve has a nice status page where you can easily see in one overview which budgets are still in the green and which need some TLC. As you can see the Speed Index increased highly and is way above budget.
As we don’t want to continuously check SpeedCurve every time something is deployed, we added a Slack webhook and now we are getting in realtime notifications, good or bad, in our dedicated channel. Also we’re notified with a weekly email report to see what happened during that period.
Hey, but what happened to your performance?
Well, sometimes the simplest or smallest changes can have quite some impact and that’s one of the main reasons why you want everything in place. For example, we have a generic component that can lazy load an image just before it comes in to view (which is a must-have performance feature).
Lazy loading is a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed
Unluckily for us, lazy loading wasn’t the only issue that made the performance drop. At almost the same time the bug was released to production, a new top teaser was planned by the content team to go live.
On every top teaser, the content team can place an overlay and in this case one was created with the logo of some brands. Unfortunately the size of that image was over 800 kB which doubled the total request size of the homepage and also resulted in a big performance drop.
After investigating and fixing these issues, performance increased to a score of 86 and the Speed Index decreased to 2.61s which is still a little bit over budget so there’s still room for improvement there. For the Lighthouse we could even raise the budget to 85.
Make the web faster!
With the dashboards, performance budgets and notifications in place, we stay in the lead regarding the performance of our website. We’re getting realtime notifications and with that, we can easily and quickly trackback what was released, what happened with the content or even third-party packages and act upon that. Sometimes mistakes and fixes can be easy, in other cases, it takes up more time and resources to fix the issue and I think that makes the life of a frontend developer more challenging, interesting and fun. So let’s make the web faster for everyone!
There are of course more companies or tools like SpeedCurve which can offer the right solution for your needs. You might even try setting up a Lighthouse audit service yourself. In the end, it’s up to you how you want to optimize your website performance.
Thank you for taking the time to read this story! If you enjoyed reading this story, clap for me by clicking the 👏🏻 below so other people will see this here on Medium.
I work at Wehkamp.nl one of the biggest e-commerce companies of 🇳🇱
We do have a Tech blog, check it out and subscribe if you want to read more stories like this one. Or look at our job offers if you are looking for a great job!