How performance budgets and SpeedCurve are helping us to keep a high performant website

Berry de Witte
Mar 25 · 6 min read

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.

Mobile-first dashboards

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.

two of our main graphs on the homepage dashboard

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.

If you’re aiming for the best, your javascript bundle should be below 150 KB, performance score over 90 and for the user-centric metrics, Google has the following guidelines.

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.

homepage performance budget status

Notifications

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.

A positive notification about performance increasing

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

After refactoring and optimizing some code for the main image (we call it the top teaser) on the homepage, we accidentally flagged that image as to be lazy-loaded. This means that the image was loaded after the initiation of the javascript. This caused the Speed Index to increase as the page needs more time to load. By default you always want to eager load images above the fold, because you will always need them at that point.

the main image (top teaser) on the homepage with the brand logo overlay

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.

Updated homepage status

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!

wehkamp-techblog

We'll try to keep up and post on the stuff we're doing and…

Berry de Witte

Written by

senior front-end developer @ Wehkamp.nl

wehkamp-techblog

We'll try to keep up and post on the stuff we're doing and discovering. Interesting in working @wehkamp? Check out https://werkenbij.wehkamp.nl/

More From Medium

More on Performance from wehkamp-techblog

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade