Keep your website fast with a performance culture

You can find many resources on how to make your website faster. I have covered how to get started with web performance and how to fix the most common issues. It is also important to prevent regressions after improving page load speed and to establish a culture of continuous improvement.

Prevent regressions

Using synthetic tools like Lighthouse

I will start with what has not worked well for me. In the past I’ve used Lighthouse CI to give performance feedback to developers on pull requests. It also helped us with a critical release at Zalando. So I’ve been advocating it. You can read the case study on web.dev.

There are several problems with synthetic tools like Lighthouse CI. First, the results are somewhat inconsistent due to the synthetic environment simulation. Second, as we moved towards releasing features using feature flags, Lighthouse CI was unable to catch performance regressions. We might have been able to fix this by testing every combination of feature flags, but we also did not want to add complexity.

Performance budgets

A simpler, more effective way to keep pages fast is to set performance budgets for asset sizes. While they are only a proxy for page performance, they work remarkably well. You set reasonable budgets to stay under, and you can block pull requests that exceed the thresholds. This prevents you from accidentally importing a very large library or breaking your tree-shaking setup.

These thresholds should be flexible. They should not prevent you from shipping urgent fixes or new features you want to roll out quickly. They are the starting point for a healthy discussion about tradeoffs between features and page load performance. The key is to be aware of the tradeoffs you are making. To reduce friction and speed up analysis when thresholds are exceeded, provide developers with bundle reports on pull requests.

Integrate page load performance into your A/B testing

One of the best things you can do to prevent performance regressions is to correlate your page speed metrics with your business metrics. There is no better place to start than your experimentation setup, where you run your A/B tests. When creating new experiments, both developers and products should easily be able to use page load performance metrics as guardrails.

Another benefit of integrating these metrics into your A/B testing setup is that you can then correlate them with your business metrics. This allows you to measure the business impact of your web performance efforts and know where to increase your focus.

Integrate page load performance into your operational excellence

Your page load performance metrics should also be reviewed as part of your operational excellence. This is especially important if your website drives the majority of your revenue, such as e-commerce. By reviewing performance metrics on a weekly basis, teams can quickly identify and investigate problems early on.

Show business impact

As you continuously improve performance, remember to celebrate wins along the way. To be effective, remember to show how improving these metrics impacts business performance. The best way to show direct impact is through A/B testing as you roll out improvements. If you can’t get a direct correlation, validate user-perceived performance through user interviews. You can also work with your SEO team to review the impact of your page load performance over time.

This is a long game that will pay off over time. By creating a culture of web performance, you will maintain a great browsing experience for your users. That, in turn, will lead to improved engagement and conversions. What’s not to love?