How we find the friction and verify the fix.

Real visitors and the lab, side by side

Where Google has enough data, we read the Chrome UX Report: the 75th percentile of LCP, INP, CLS, FCP and TTFB over the last 28 days, per device type. Alongside it, controlled lab runs help investigate the technical causes.

Lab tests set to your audience

We load the page in Chrome on the phone and network your visitors typically use. Device speed and network come from your region, and the round trip from your real‑visitor data.

Repeated, not once

Each test runs at least three times and we use the middle result. One lucky or unlucky load never decides anything.

Main content, broken into its parts (LCP)

We split the wait for the main content into server response, how long before the image is requested, its download, and how long before it is painted. That shows which part is slow, not just that the page is.

What keeps the browser busy (INP)

Long tasks and script start‑up time are traced to the script that runs them, including third‑party tags. That is usually why taps feel slow.

Server and CDN delivery (TTFB)

Whether your CDN served the page from cache, what the server says about its own timing, and compression, cache headers and redirect chains.

Accessibility

We run axe's WCAG‑based checks. A violation in code you control, such as poor contrast or a control without a name, is reported as a confirmed defect.

No real‑visitor data?

Many pages have too few visits for Google to report. We say so plainly, and rank on lab evidence alone.

Regions we calibrate for: South Africa, Nigeria, Kenya, other African markets, Europe, the US and Canada, Australia and New Zealand, and mixed global audiences.

Only what holds the page back

A speed fix leads only if it acts on the main cause of the wait, by a clear margin, across repeated runs. Everything else goes to the backlog.

The bar

At least 150 ms and 15% of the wait for the main content, in the middle result of three or more runs.

Real visitors first

Problems real visitors feel come first, then confirmed accessibility defects. Gains we only see in the lab come last.

One owner per fix

Code your team controls becomes a work order. A vendor's script or a tag choice becomes a short brief for whoever decides.

Estimates stay estimates

Lighthouse's estimated savings are labelled as estimates, one fix at a time. We never add them up or rank by them.

Each supported fix becomes a deterministic work order: evidence, source checks, implementation steps, safeguards and verification instructions. Your developer or coding agent works from it in your repository; your team reviews and releases the change.

1. What Stroma observed. The evidence, and the conditions it was measured under.
2. Confirm which code owns the page. The agent records the app, route, rendering mode and framework version, and names the file, before it edits anything.
3. Check the premise. If the code does not match what we saw, the agent stops and reports it.
4. The change for your stack. Step by step for server‑rendered and static HTML, general steps for other stacks, with what must keep working and how to undo it.
5. Verify. Once the change is live, the agent asks Stroma to re‑test the page.
6. Report back. What changed, and anything a person still needs to check.

Stroma never reads your source code. Your agent does the work, and your team decides what ships.

After release, we load the same page under the same conditions, at least three times before and after, and compare like with like. We check the mechanism, not a score.

The change itself

The specific change must be present on the same main element in every run after release. A faster score on its own does not count.

Check for related regressions

Regression checks cover what the work order said must keep working, and related fixes touched by the same change are checked in the same run.

Confirmed, not confirmed, or could not compare

Confirmed means the change is in place as described. Not confirmed says what is still missing. Could not compare means something besides your change moved, such as the test conditions, so we make no judgement.

Each result carries a verifiable signature recording which page we checked and when. Confirmation means the specified change is present; it does not establish an increase in leads or conversions.

Where Chrome has data, your workspace also tracks real‑visitor numbers over time. That is context, not proof that one change caused a shift.

Your analytics flag where visitors leave. Stroma helps investigate technical friction on those pages, turn supported findings into work orders and verify deployed changes.

• How much money a slow page costs, or what a fix will earn.
• Totals of estimated time savings.
• That a problem is fixed before a re‑test confirms it.
• That a page meets accessibility law or a WCAG level. Automated checks find some issues, not all.
• Anything about pages or visits we did not measure.

Built on Lighthouse, axe and the Chrome UX Report.