Standard SW-1:2026.2 · Category 3 of 9

Performance & Core Web Vitals

Q: Does your main content render for real users in under 2.5 seconds?

Field p75 LCP at or under 2.5 s on mobile. LCP measures when the main content becomes visible, which is the moment a visitor decides whether to stay. It is the Core Web Vital most strongly associated with bounce behaviour and the one most often broken by things nobody thought of as performance decisions: a hero image served at desktop dimensions to phones, a font that blocks text rendering, or a personalisation script that must resolve before the page paints.

Q: Does the page respond to taps and clicks within 200 ms?

Field p75 INP at or under 200 ms. INP measures whether the interface actually responds when touched, across the whole visit rather than just at load. It replaced First Input Delay because responsiveness after load matters more than responsiveness at load. Poor INP is almost always caused by long JavaScript tasks blocking the main thread — typically tag managers, analytics, chat widgets and consent tools all initialising at once.

Q: Does content jump around while the page loads?

Field p75 CLS at or under 0.1. Layout shift is the fault users feel most viscerally — the mis-tap caused by a button moving under the thumb. It is also among the cheapest to fix, because the causes are a short and well-understood list: images without dimensions, ads and embeds without reserved space, web fonts swapping metrics, and content injected above existing content.

Assessed on field data where a site has enough traffic to produce it, and on lab data where it does not — the distinction is recorded on the checksheet, because a lab score is a prediction and a field score is a measurement. We inspect the three Core Web Vitals plus the payload characteristics that cause them.

Weight: 14 / 100
Checks: 5
Pass-blocking: 1
WOF analogue: Brakes & tyres

PF-01Major failweight 4measured

Largest Contentful Paint within threshold

Does your main content render for real users in under 2.5 seconds?

Pass, advisory and fail criteria for PF-01
Pass	Field p75 LCP at or under 2.5 s on mobile.
Advisory	Field p75 LCP between 2.5 s and 4.0 s, or insufficient field data with lab LCP under 2.5 s.
Fail	Field p75 LCP above 4.0 s, or lab LCP above 4.0 s where no field data exists.

Why it matters

LCP measures when the main content becomes visible, which is the moment a visitor decides whether to stay. It is the Core Web Vital most strongly associated with bounce behaviour and the one most often broken by things nobody thought of as performance decisions: a hero image served at desktop dimensions to phones, a font that blocks text rendering, or a personalisation script that must resolve before the page paints.

How we inspect it

We read the 75th-percentile mobile LCP from field data where the origin or URL has sufficient sample. Where it does not, we run a lab measurement under a throttled mobile profile and record the result as derived, because a lab figure predicts rather than measures user experience.

Source: Chrome UX Report field data (75th percentile, mobile) with lab fallback

Remedy

1Identify the actual LCP element per template — it is frequently not the element you assume.
2If it is an image: serve modern formats, size it correctly with responsive srcset, and set fetchpriority="high" with preloading.
3Remove lazy-loading from the LCP element; lazy-loading above the fold directly delays it.
4Eliminate render-blocking CSS and JavaScript in the critical path; inline the critical CSS.
5Preconnect to required third-party origins and defer everything not needed for first paint.
6Reduce TTFB with edge caching — server response time is a floor LCP can never beat.

Verification

Recheck re-reads field data after the 28-day collection window, or re-runs the lab profile where field data is unavailable.

Usually fixed by: Developer
Effort: Large · 1–3 days
Est. impact: high
Typical cost: NZ$800–3,200

PF-02Minor failweight 3measured

Interaction to Next Paint within threshold

Does the page respond to taps and clicks within 200 ms?

Pass, advisory and fail criteria for PF-02
Pass	Field p75 INP at or under 200 ms.
Advisory	Field p75 INP between 200 ms and 500 ms.
Fail	Field p75 INP above 500 ms.

Why it matters

INP measures whether the interface actually responds when touched, across the whole visit rather than just at load. It replaced First Input Delay because responsiveness after load matters more than responsiveness at load. Poor INP is almost always caused by long JavaScript tasks blocking the main thread — typically tag managers, analytics, chat widgets and consent tools all initialising at once.

How we inspect it

We read the 75th-percentile INP from field data and, where available, attribute the slowest interactions to specific long tasks and script origins so the remedy targets the actual blocking work.

Source: Chrome UX Report field data (75th percentile, mobile)

Remedy

1Attribute slow interactions to specific scripts using field attribution data rather than guessing.
2Break long tasks into smaller chunks and yield to the main thread between them.
3Defer non-essential third-party scripts until after first interaction or into a web worker.
4Audit the tag manager — accumulated unused tags are the most common single cause.
5Debounce expensive event handlers and avoid layout thrashing inside them.

Verification

Recheck re-reads field INP after the collection window and confirms the p75 is inside threshold.

Usually fixed by: Developer
Effort: Large · 1–3 days
Est. impact: medium
Typical cost: NZ$800–3,200

PF-03Minor failweight 3measured

Cumulative Layout Shift within threshold

Does content jump around while the page loads?

Pass, advisory and fail criteria for PF-03
Pass	Field p75 CLS at or under 0.1.
Advisory	Field p75 CLS between 0.1 and 0.25.
Fail	Field p75 CLS above 0.25.

Why it matters

Layout shift is the fault users feel most viscerally — the mis-tap caused by a button moving under the thumb. It is also among the cheapest to fix, because the causes are a short and well-understood list: images without dimensions, ads and embeds without reserved space, web fonts swapping metrics, and content injected above existing content.

How we inspect it

We read the 75th-percentile CLS from field data and identify the shifting elements in a lab render so each contributing element can be scoped as its own fix.

Source: Chrome UX Report field data (75th percentile, mobile)

Remedy

1Set explicit width and height attributes, or CSS aspect-ratio, on every image, video and iframe.
2Reserve fixed space for ad slots, embeds and cookie banners before they load.
3Use font-display: optional or size-adjust descriptors to prevent metric shift on font swap.
4Never inject banners or notices above existing content after render — reserve the space or overlay it.
5Apply CSS containment to independently updating regions.

Verification

Recheck re-reads field CLS and re-renders the page to confirm no shifting elements remain above threshold.

Usually fixed by: Developer
Effort: Medium · 2–8 hrs
Est. impact: medium
Typical cost: NZ$240–800

PF-04Advisoryweight 2measured

Page weight and request count within budget

Is the page shipping more bytes than its content requires?

Pass, advisory and fail criteria for PF-04
Pass	Under 1.5 MB total transfer and under 60 requests on mobile, with third-party under 30% of bytes.
Advisory	1.5–3 MB or 60–100 requests.
Fail	Over 3 MB total transfer or over 100 requests on a content page.

Why it matters

Page weight is the underlying cause behind most Core Web Vitals failures, and it is the metric that most directly translates into real cost for visitors on metered mobile connections. Unused JavaScript is the usual culprit: frameworks shipped in full to render pages that are essentially static, plus every tag ever added and never removed.

How we inspect it

We record total transfer size, request count, and the breakdown by resource type, separating first-party from third-party bytes and identifying unused CSS and JavaScript through coverage analysis.

Source: Resource waterfall from the inspection render

Remedy

1Run coverage analysis and remove or defer CSS and JavaScript unused on first render.
2Serve images in modern formats at correct dimensions with responsive srcset.
3Subset fonts to the characters actually used and self-host to avoid a third-party connection.
4Audit third-party scripts against measured business value and delete the ones nobody can justify.
5Set a per-template performance budget and enforce it in CI so regressions fail the build.

Verification

Recheck re-renders the page and confirms transfer size and request count are inside budget.

Usually fixed by: Developer
Effort: Medium · 2–8 hrs
Est. impact: medium
Typical cost: NZ$320–1,200

PF-05Minor failweight 2measured

Images are correctly sized, compressed and formatted

Are images served at the right dimensions in a modern format?

Pass, advisory and fail criteria for PF-05
Pass	All images within 1.5× displayed dimensions, served as AVIF or WebP, with lazy-loading below the fold only.
Advisory	Modern formats used but some images oversized, or legacy formats retained as fallbacks only.
Fail	Images over 2× displayed dimensions, uncompressed PNG/JPEG for photographic content, or lazy-loading applied to the LCP element.

Why it matters

Images are typically 50–70% of page weight and the most consistently available source of savings. The most expensive single mistake is serving one desktop-resolution image to every device: a 2,400-pixel-wide hero delivered to a 390-pixel phone wastes roughly 95% of its bytes and is very often the LCP element, so the waste lands directly on the metric that matters most.

How we inspect it

Every image is compared for intrinsic versus rendered dimensions at mobile viewport, checked for format, and evaluated for potential byte savings from re-encoding at equivalent visual quality.

Source: Per-image analysis of intrinsic vs displayed dimensions, format and compression

Remedy

1Generate responsive variants and serve them with srcset and correctly specified sizes.
2Convert photographic content to AVIF with WebP fallback; keep PNG only for images requiring lossless transparency.
3Set explicit dimensions on every image to prevent layout shift.
4Apply loading="lazy" below the fold and fetchpriority="high" to the LCP image.
5Move transformation to a build step or image CDN so correctness does not depend on editors remembering.

Verification

Recheck re-analyses every image against displayed dimensions and confirms format and sizing compliance.

Usually fixed by: Developer
Effort: Medium · 2–8 hrs
Est. impact: medium
Typical cost: NZ$320–1,200