PlaywrightPHP

Performance

Measure browser-visible performance signals and application metrics without turning tests into unstable benchmarks.

Performance checks are useful when they protect a user-facing budget: page load cost, resource count, rendering delay, or an application metric you own.

They are not general benchmarks. CI machines are variable, networks differ, and browser startup adds noise.

What browser tests can measure

Playwright PHP can observe performance through the page:

  • navigation timing;
  • resource requests and response sizes when available;
  • custom performance.mark() and performance.measure() entries;
  • application-specific readiness markers;
  • screenshots, traces, and videos for visible timing problems.

Prefer metrics your application defines deliberately. They are usually more stable than raw wall-clock timing.

Minimal browser metric

Use a broad threshold and a metric you understand:

php
$duration = $page->evaluate(<<<'JS'
() => {
    const entry = performance.getEntriesByType('navigation')[0];
    return Math.round(entry.duration);
}
JS);

self::assertLessThan(5_000, $duration);

For application readiness, an owned mark is better:

php
$ready = $page->evaluate(<<<'JS'
() => performance.getEntriesByName('app-ready').length > 0
JS);

self::assertTrue($ready);

An owned mark describes a product milestone. Navigation timing is useful for a broad lab budget, but it does not know when your application considers the page usable.

Keep thresholds defensible

A useful threshold has a reason. For example: "the dashboard must become interactive within our CI budget" is better than "duration must be under 500 ms".

Start with warnings or reports before making a hard gate. Once the signal is stable, promote it to a CI failure.

Collect a metric only when the test or report uses it. A number hidden in a CI log is not a quality gate.

Combine network and runtime signals

Performance problems often show up through multiple channels:

  • network requests are too many or too slow;
  • console logs show hydration or bundle warnings;
  • traces reveal long waits between actions;
  • custom marks show where the application became ready.

Use the smallest signal that explains the problem.

Common pitfalls

  • Creating brittle benchmarks on shared CI.
  • Measuring browser startup instead of page behavior.
  • Failing on a single slow request without retry or context.
  • Ignoring the difference between lab checks and real-user monitoring.
  • Hiding performance data in logs no one uploads.

Go next