Skip to content

Read environment and timing artifacts

Separate portable bundle evidence from Viewer-only performance observations.

Last reviewed Open Markdown

Use the portable context in session.md and network.har first. The standard artifact folder does not include the Environment, Timeline, or performance-panel data.

session.md can supply the start time, duration, starting page, and browser user agent. It does not necessarily include the application build, account role, test-data state, connection conditions, colour scheme, viewport, or every browser measurement. Take those facts from the tester’s Description or notes only when they were explicitly recorded.

network.har supplies request start times and HAR timing phases for captured HTTP traffic. Use those values to identify a long request or a request interval, not as a complete measurement of when the page became usable.

Keep these claims distinct:

  • HAR timing describes a captured request as observed by the browser.
  • A tester-authored wait describes elapsed user experience and should name the measurement method.
  • A screenshot establishes a visible state at an authored or correlated point.
  • FCP, LCP, long-task, lifecycle, and resource observations can exist while Recorder assembles the report, but the standard bundle does not provide them as a portable performance artifact.

Recorder does not calculate Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), or a complete responsiveness verdict. Do not infer a missing metric as zero.

If the HAR shows one long request, investigate that route and its server timing. If the response completed before the UI became ready, inspect client work with browser performance tooling. If the bundle lacks the decisive interval, ask for a controlled new attempt with the wait and conditions written into the handoff.

Use a profiler or repeatable benchmark for root-cause or release-level performance decisions. The bundle helps identify where to measure next; it does not replace that measurement.