Skip to content
certyn logoCertyn
Start Free
RecipesDoc

Performance Check of a Slow Page

Certyn measures a slow page's Web Vitals and main-thread blocking, finds the slow requests, and files what hurts users.

For teams who hear "the reports page is slow" and want numbers and a cause, not a feeling.

Your setup

  • A web app on staging, with a test account.
  • One page or action that users call slow, for example /reports or the Apply filter button.
  • You want measured numbers, the likely cause, and an issue if it is real.

Say this to Certyn

Users say /reports is slow, and the Apply filter button freezes the page. Measure it on staging and tell me why.

What Certyn does

  1. Says the run length and starts an explore run with the page and action as the goal (app.run.create type explore). For a quick look, it can measure on the chat's Machine while you watch.
  2. In the run, Certyn measures the page's Web Vitals (browser.perf.check): LCP (main content shown), CLS (layout shift), FCP, TTFB, and Total Blocking Time with long tasks. Each value is rated good, needs improvement or poor, by Google's thresholds (for example LCP good up to 2.5 s, poor from 4 s).
  3. Measures the action: with the button as interaction_selector, it clicks it and reports the long tasks that blocked the page, and INP when the browser reports it.
  4. Finds the cause: slow or repeated requests and very large responses in the network log (browser.network.list), and the browser's counters for page size, script time and memory (browser.perf.get).
  5. Repeats on a slow network (browser.network.set slow_3g or 3g) to see if the page is still usable.
  6. Measures at least twice, then files an issue if a main page is well into poor or a main action feels broken.

What you get

  • The numbers per page, with the network setting and how many times it measured.
  • The slow request, the long task or the large response behind it.
  • If you ask: a test case that measures the page, so a later run shows if it got slower.

Limits

  • These are lab numbers from one Chromium on a Machine, not your users' devices or field data. Compare pages with each other, not with your real-user monitoring.
  • One browser, one user. This is not a load test: it does not show how the page behaves under many users. For that, see the k6 recipe.
  • Machine timing varies between runs. One slow run can be noise, so trust repeated results.
  • Web pages only.
PreviousAccessibility Check of Your Key PagesNextTest Each Pull Request's Preview URL (Vercel, Netlify)