Performance regression testing

Changes reach your users from everywhere: your own teams, third parties, the browser, the OS. Each one is small. Together they're death by a thousand cuts, and in most organisations nobody owns the whole journey.

I've always considered myself a QA engineer, not a performance specialist, but just over a year ago I set out to find ways to warn us about performance regressions before release. This talk is about what I've learned from the web performance community, what I built when off-the-shelf tools didn't fit, what I found, and where the numbers lied to me. That last part includes CI noise, unrealistic throttling, and why "LCP doubled" isn't always bad news.

You'll leave with a tester's view of web performance, some ideas for turning an existing test suite into a regression detector, and a few home-made acronyms.

Risko Ruus

Rush Street Interactive

Risko is a Principal QA Engineer at Rush Street Interactive with over 20 years of experience in software quality, development, and test automation. His background includes work on the Nokia smartphone OS, Skype, and mobile betting apps.

He focuses on helping teams deliver software quality beyond functional correctness, including non-functional requirements such as performance, reliability, and user experience. Recently, he has been building a testing library that brings visual assertions into UI tests using images, videos, and vision-capable LLMs.

Outside work, he enjoys backcountry hiking and learning Japanese.