Web performance expert Matt Zeunert, founder of DebugBear, digs into the tools, metrics, and organisational challenges behind keeping websites fast – and the one thing you should pay more attention to when testing
What first got you interested in web performance testing, and what keeps you curious about it now?
I was working for a website builder and our customers often brought up performance concerns. Usually because they tested their website with PageSpeed and got a bad score. I ended up working a lot on those kinds of issues, optimising load time, Lighthouse scores, etc.
When I started building DebugBear, it was a very confused tool doing all kinds of things for front-end developers. But what users understood and were willing to pay for were the page speed features. That also directed my interest, and over time we changed our product and positioning to focus on that.
Now one of the things I’m interested in is the organisational side of web performance. Whose job is it to keep the website fast? How do you justify the investment in it? And how do you prioritise fixes across the website?
How does DebugBear differ from other page speed monitoring tools, and how did you come up with the idea for it?
When I started, one key feature I cared about was the ability to compare test results over time. At my old job we could see that there was another 500 kilobytes of JavaScript on the page. But it wasn’t easy to figure out the exact file that was added or got bigger. So you had to spend a lot of time digging through the data to identify the cause of the regression.
Today we have a big focus on improving the three Core Web Vitals metrics. While some tools require a lot of custom setup, we work based on that goal to provide the most useful dashboards and debug data out of the box.
I’m also really proud of a lot of the custom features we’ve built over time. For example, our request waterfall view shows you how loading different resources impacts performance. And our experiments feature lets you try out optimisations quickly without deploying changes to your live site.
What can we expect to take away from your talk?
I’m hoping people will walk away with a more nuanced understanding of how different testing tools work and how that impacts the metrics they report.
That’s one of the biggest challenges people have with measuring performance: Different users have different experiences, and different tools report different values. Usually there is no one right way to measure things, but it really helps to understand what causes the discrepancies.
In your opinion, what is one metric people overreact to, and one they do not pay enough attention to?
Total Blocking Time (TBT) makes up 30% of the Lighthouse Performance score, and people care a lot about it. But it’s also kind of awkwardly defined, because it depends on the First Contentful Paint and Time to Interactive metrics (TTI). TTI in turn is really sensitive to specific CPU and network quiet time windows.
When people see changes in their Total Blocking Time score they often worry that it’s been caused by changes to the CPU tasks running on their page, when really one of the other input factors has changed.
It’s much more helpful to focus on Interaction to Next Paint instead, because that actually tells you how CPU tasks slow down user interactions. But it tends to get neglected because you can’t measure it in a lab test, and it really depends on what the actual user interaction is.
Well, you can test INP in the lab with our INP Debugger which just randomly clicks elements on the page. I’m always a bit reluctant to recommend the tool because it’s not an ideal approach, but a lot of our users love it.
What are you currently working on for DebugBear?
After four years of kinda thinking about it we finally shipped our custom dashboards feature! Teams now can put all the data that matters to them in one place, including being able to combine lab test results, real user metrics, and data from Google’s Chrome User Experience report in one chart.
We’re also thinking a lot about what AI means for web performance. For example, we’ve added AI agent prompts to our performance recommendations so the model has all the data it needs to try and fix a performance issue in the code. Overall we want to tighten the loop between analysing the data and fixing issues.
What’s the best piece of advice you’ve ever received?
You should build a real user monitoring tool! I’m not sure if this is super broadly applicable, but I’m pretty happy that I followed it.
At Pixel Pioneers Bristol 2026, Matt Zeunert will discuss web performance metrics. The conference will also cover new web platform features safe to use in your projects today, designing and building low-carbon websites, language as the key to a great user experience, creating web layouts with both code and UI design tools, and more. Get your ticket today!