---
name: performance-benchmark-baseline
description: "Establishes a performance baseline for load and Core Web Vitals, with the numbers to beat and a record of exactly how they were measured. Use when a developer wants a repeatable measurement of page speed and server load before making optimisations, so later changes can be compared. Do not use for fixing performance problems or one-off speed checks with no recorded method. Related topics: coding, technical."
---

# Performance Benchmark Baseline

Establishes a performance baseline for load and Core Web Vitals, with the numbers to beat and a record of exactly how they were measured.

## When to use

Use this skill when a developer wants a repeatable measurement of page speed and server load before making optimisations, so later changes can be compared. Do not use it for fixing performance problems or one-off speed checks with no recorded method.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Fix the method first: tool version, device and network profile, cache state, region, and run count.
3. Run each page at least five times and record median and spread for the Core Web Vitals, Time to First Byte, and transfer size.
4. Load test backend endpoints at expected concurrency and record throughput, p50, p95, p99, and error rate.
5. Compare results against the targets and published thresholds and write the numbers to beat.
6. List the top three suspected bottlenecks with the evidence for each.

## Inputs

- **Application URL or local command** (free text, e.g. "Where it runs")
- **Pages or endpoints to test** (longer free text)
- **Device and network profile** (choose one: Desktop fast, Mobile mid-range 4G, Mobile slow 3G)
- **Tooling** (choose one: Lighthouse, WebPageTest, k6, Playwright traces)
- **Traffic expected** (free text, e.g. "Concurrent users at peak")
- **Targets if any** (free text, e.g. "LCP under 2.5 seconds")

## Output

A results table per page and endpoint, a numbers-to-beat list, three suspected bottlenecks, and a method section precise enough to rerun.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Performance Benchmark Baseline

Measure a performance baseline I can compare future changes against.

- Application URL or local command: {{Application URL or local command}}
- Pages or endpoints to test: {{Pages or endpoints to test}}
- Device and network profile: {{Device and network profile}}
- Tooling: {{Tooling}}
- Traffic expected: {{Traffic expected}}
- Targets if any: {{Targets if any}}

Define the method before running anything so results are repeatable: tool and version, device and network profile, cache state, region, and number of runs. Run each page at least five times and report the median and spread rather than one run. Record Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, Time to First Byte, and total transfer size. For backend endpoints under load, record requests per second, p50 and p95 and p99 latency, and error rate at the expected concurrency. Compare to the stated targets and the published Core Web Vitals thresholds, then list the numbers to beat. Add the top three suspected bottlenecks with evidence. Return a table plus a method section another person can re-run.

## Pitfalls

- Reporting a single run, so noise looks like a regression later.
- Testing with a warm cache and a fast desktop profile, flattering the numbers.
- Leaving out the tool version, which makes future comparisons invalid.