Response Time (response-time)

Summary

HTTP latency samples with configurable percentile thresholds.

Classification

• Category: PERFORMANCE
• Plugin id: response-time
• Version: 1.2.0
• Target types: WEBSITE, API, WEBSHOP
• Weight class: LIGHT
• Risk level: not set on plugin object
• Browser required: No (HTTP / Node / other — see source)
• Tier / group: Tier 1 — HTTP-only

Schedule

• scheduleHints: { defaultInterval: '*/30 * * * *', priority: 7 }
• Prerequisites: None declared on this plugin.

Configurable inputs

Public keys are derived from inputSchema: z.object({ ... }) (underscore-prefixed keys are runtime-only and omitted here).

Field	Notes
requests	Zod field in inputSchema — see source for defaults, min/max, and .describe().
warnMs	Zod field in inputSchema — see source for defaults, min/max, and .describe().
criticalMs	Zod field in inputSchema — see source for defaults, min/max, and .describe().
timeout	Zod field in inputSchema — see source for defaults, min/max, and .describe().
samplePages	Optional injected pages when Run on other pages is enabled on the target profile.

Multi-page mode

When Run on other pages is enabled, the plugin measures latency on the homepage plus up to 10 injected sample pages. Findings and fingerprints are per-page; run score uses the worst p95 across all checked pages.

Runtime / injected config

• None documented beyond standard worker context (target, config, logger, reportProgress). Underscore-prefixed keys are internal.

Checks that produce findings

These checks run inside this plugin during a single test run. They are not separate tests in the database — each becomes a Finding linked to the Run for response-time.

Check	Typical severity	Why
Severe p95 latency (above critical threshold, default 8000 ms)	WARNING	p95 above 8s means most users wait multiple seconds on key paths — bounce and conversion loss at scale.
Slow p95 latency (above warn threshold, default 2000 ms)	WARNING	p95 above 2s misses common Core Web Vitals / UX targets; Google uses speed as a ranking and quality signal.
Severe p99 tail latency (when p95 is OK but p99 is high)	WARNING	Healthy median with sporadic 8s+ responses indicates cold starts, GC pauses, or queue spikes that averages hide.

How each check works

1. Sampling — Sends requests sequential HTTP GETs (default 5, max 50) via runLatencySamples() with per-request timeout (default 10s). Live progress reports each timing.
2. Statistics — computeLatencyStats() sorts samples and computes avg, p50, p95, p99, min, max.
3. Finding rules (all WARNING severity) —
   • If p95 > criticalMs (default 8000) → “Severe response time” finding (includes avg/p50/p99 evidence).
   • Else if p95 > warnMs (default 2000) → “Slow response time” finding.
   • If p99 > criticalMs while p95 ≤ criticalMs → separate “Severe tail latency” finding.
4. Run score — 100 if p95 ≤ warnMs; 55 if p95 ≤ criticalMs; 25 otherwise. Note: criticalMs names a threshold, not CRITICAL finding severity.

Caveats and concerns

• Homepage-only by default — Enable Run on other pages to measure latency on product/category templates from crawl data.
• Small sample size — Default 5 requests may miss intermittent spikes; p99 with n=5 is a rough tail estimate.
• Network path — Includes teste.no worker→target latency; remote workers may see different RTT than local users.
• GET only — POST/GraphQL-heavy apps may show different latency on real mutations.

Source

packages/test-plugins/src/plugins/response-time.ts