Hello hello!

You know what it's like. You're supposed to be out in the garden, enjoying the glorious summer weather. Instead, you find yourself staring at your phone screen, going down a rabbit hole, trying to define exactly what a frontend soak test actually is. Typical.

See if you agree with me here. What I found was a lot of advice online about throwing a whole bunch of traffic at your web app and seeing what happens. To me, that sounds like the definition of a load test and is less about what happens in the frontend and more about how the server copes under heavy traffic. Important, yes, but nothing to do with how the frontend behaves for the user.

As far as I'm concerned, a soak test is a way to find out what gets worse over time, and on the frontend that's almost always memory. You want to know if your app has a leak before it falls over at the worst possible moment and becomes a nightmare to debug while real users are struggling at the same time as you're trying to fix it. On the backend, this is done by starting up a server and sending a lot of traffic to API endpoints and services, so that one small leak repeated thousands of times becomes impossible to miss. The equivalent in the frontend isn't traffic-related, it's time-related. Small memory leaks in your single-page web app (SPA) add up to very large ones as you keep interacting with the app over a long period. So a soak test would be a single, long-lived browser session with lots of activity taking place in the app, simulating a real user flow, and measuring memory usage, DOM node accumulation, and so on.

Of course, I had to sit down and try a whole bunch of stuff in Playwright. I was really pleased with that deep dive and so I wrote up how to do a soak test as my latest blog post.

I've seen people describe this before as repeating a user flow X hundred times and measuring the memory usage before and after to check for leaks. That has the potential to run quite fast when you hook it up to a Playwright session with one single browser context open the whole time, as you can automate the clicks. But when I was experimenting, I realised that there's more to it than just clicks. If you want to run a soak test fast (and I recommend it, to get fast feedback to fix your memory usage), some web apps run tasks on timers (think setTimeout(), etc.) and some run tasks when network responses are received. You don't want to wait around for either of those to happen, so you need to fake them both. Fortunately Playwright allows you to manipulate the browser time functions to act on your whim, and network responses can return fixtures instead of real data. Add it all together and you get a soak test that can run hundreds of times in just a couple of minutes and tell you where you need to look to fix your memory leaks.

I've never seen all these techniques used together before for this purpose, so I'd read it for that, code snippets included:

https://denodell.com/blog/your-spa-is-leaking-memory-soak-test-it

And now for some quick book news. It's got a new name! The book formerly known as "Performance Engineering in Practice" is now called "Fast by Default: Practical Performance Engineering". Same book, nothing new to buy if you have it in early access already.

Manning also released three new chapters as well for your enjoyment:

Chapter 6, Turn performance goals into budgets. Working out what's worth putting a number on, and how specific to get.

Chapter 7, Profile your code before it ships. Browser devtools, backend profilers, Instruments and Android Profiler. One section is on memory and leak detection, which is where the post picks up.

Chapter 8, Catch size problems during builds. What's actually in your bundle, why tree-shaking misses things, container and dependency size, mobile binaries, and keeping an eye on all of it over time.

All the book stuff is here on the Manning site: Fast by Default.

Hope you've enjoyed your July! Thanks for reading,
Den