A performance regression process should catch meaningful changes before they become a recurring customer problem. For a small SaaS team, start with a few representative routes, reproducible conditions and clear ownership. A complicated dashboard that nobody uses is less valuable than a small test suite linked to release decisions.
This is a proposed operating workflow. It does not assume a particular CI provider or promise that a fixed score threshold will suit every product.
Choose representative journeys
Select a stable marketing page, a conversion route and a core application interaction. Add a content-heavy route if the product publishes guides or directory pages. Explain why each route belongs in the suite so future changes do not quietly turn the tests into an arbitrary URL list.
Use synthetic accounts and stable test data for authenticated journeys. Avoid testing against a changing production account whose contents make one release incomparable with the next. Preserve the scenario configuration alongside the application version.
Establish variation before thresholds
Run the same build repeatedly to understand normal measurement variation. Lighthouse scoring can vary with conditions, so a small isolated change should not automatically be treated as a regression. [1]
Track underlying metrics and failed operations, not only a score. A severe error on signup deserves attention even when the marketing page score is unchanged. Conversely, a slight score movement may not justify blocking a release if the underlying experience is stable and the difference is within expected variation.
Define warning and blocking conditions
Separate a warning that prompts investigation from a failure that blocks release. A newly broken route, missing critical content or consistently unresponsive interaction may justify a hard stop. A moderate asset increase may trigger a review of whether the added functionality is worth the cost.
Performance budgets can formalize resource and experience constraints. [2] Treat your selected limits as product decisions informed by baselines, not as universal Google requirements. Record the owner who may approve an exception and the reason for doing so.
Diagnose changes at the right layer
When a test fails, compare the build's changed dependencies, resources and server behavior. Ask whether the issue is a real product regression, a test-environment problem or an intentional workload change. Preserve the failed run long enough to investigate instead of rerunning until a green result appears.
An illustrative release might add a customer-video library to a shared layout. The regression appears on every route even though only one page displays video. That points to a dependency-boundary review, not independent optimization work on every affected page.
Connect pre-release and production checks
A controlled test cannot represent every device, user state or network. After release, review production errors and appropriately collected user measurements. Keep a rollback plan for changes that pass synthetic tests but cause a real workflow problem.
Label external measurements separately. IndieTools Speed offers periodic observations of public product websites. [3] Those observations can complement your own monitoring, but they should not be treated as a direct result of your CI run or as proof that authenticated workflows passed.
Make the report useful to a founder
A release summary should answer four questions: what changed, what the tests found, what users may notice and who owns any follow-up. Include the relevant route and build, not just a red percentage.
For a small team, a short exception log prevents repeated debates. If an important new feature adds measurable work, document why the tradeoff was accepted and when it will be revisited. This makes performance an explicit part of product management rather than an occasional cleanup project.
Should every score decrease block a release? No. Use reproducibility, underlying metrics and user impact.
How many routes are enough? Start with representative workflows and expand when incidents reveal a blind spot; there is no universal count.
What is the first implementation step? Save a reproducible baseline for one critical journey and assign an owner to investigate meaningful changes. Add complexity only when it improves decisions.
Explore related IndieTools resources: reported technology collections.
Continue your research
- Track Website Speed Week Over Week
- Next.js SaaS Pages: Audit Hydration After Redesign
- Website Performance During Product Launch Traffic
Sources and verification
Sources consulted for this article on October 1, 2026. Product capabilities are documented claims unless an actual test is explicitly described.
