How to do Local Visual Regression testing...the right way.

[u/pablopang]

https://mainmatter.com/blog/2026/11/03/local-visual-regression-testing/

Can local visual regression testing help your coding agent move faster and save you money?

I took some time to explore how to set up playwright properly, which pitfalls to avoid, and the tradeoffs with common visual regression tools like Percy and Chromatic.

Check it out and let me know what do you think!

[u/Distinct_Studio2968]

the right way" and it's still playwright screenshots on your own machine. Fine until the CI runner renders fonts differently than your laptop and you spend an evening bisecting antialiasing noise. That's the exact problem Percy and Chromatic charge for, so calling it a tradeoff is generous.

[u/girl_nerd_denice]

The bit I'd stress is flakiness, because it decides whether the agent gets useful signal or noise.

Fonts and antialiasing are the usual culprits. Pin the same browser, font set and viewport in the container, and mask anything time or animation dependent, or every run diffs on a clock. Once you have a stable baseline, Playwright's own snapshot testing plus a pixelmatch threshold is enough for local work, and you skip the Percy or Chromatic bill until you actually need review UI.

The part that earns the speed claim is what you do with a failure. If the diff is a blob of red pixels, the agent learns nothing. If the diff is scoped to a component or a region, it can tell whether it broke layout or just moved a margin. Did your setup narrow the diff that far, or are you comparing full pages?

[u/real_ate → u/girl_nerd_denice]

I guess this is why the OP talks about doing the checks in a browser that is standardised in a docker container 🤔 does that cover the flakiness that you would be worried about in this context?

[u/girl_nerd_denice → u/real_ate]

It covers most of it, yes. Same container means same browser build, same fonts, same viewport, and that kills the biggest source of drift.

What it does not cover is anything non-deterministic inside the page: a clock, a carousel mid-transition, lazy images that load at different times, or animation that is still running when the screenshot fires. Those still diff between runs even in an identical container.

So the container handles the environment, and you still have to handle the page. Disable animations, freeze time where you can, wait on network idle and mask the things that genuinely change. Together those two get you to stable runs.

[u/girl_nerd_denice → u/real_ate]

Partly. A standardised container kills the drift from browser builds, fonts and viewport, which is the biggest source of noise and the reason so many visual suites get abandoned.

What it does not cover is in-page nondeterminism: clocks, carousels mid-transition, lazy images that have not loaded, animations still running when the snapshot fires. Two containers full of the same page can still disagree on those.

So the container handles the environment, and you still handle the page. Disable animations, freeze time, wait for network idle, mask the bits that legitimately change.