Core Web Vitals Acceptance Criteria Ticket templates with a definition of done for LCP, INP, CLS and TTFB, ready for Jira or Azure DevOps
A performance ticket without an acceptance criterion ends in a discussion about Lighthouse points. The templates on this page turn every metric into a task that a development team can implement and an independent party can sign off: with baseline, target value per page type, checks before merge, evidence in field data after go-live and a definition of done for every release.
Values in square brackets are placeholdersDownload the templates as PDF
Acceptance criteria for Core Web Vitals: thresholds, percentile and time window
Google assesses the Core Web Vitals at the 75th percentile of visits, separately for mobile and desktop, over a rolling 28-day window. An acceptance criterion adopts these three definitions, otherwise it measures something other than Google. The thresholds come from web.dev, for Time to First Byte from web.dev/articles/ttfb.
| Metric | Good | Poor | In the lab |
|---|---|---|---|
| Largest Contentful Paint | up to 2.5 s | over 4 s | measurable |
| Interaction to Next Paint | up to 200 ms | over 500 ms | only with an executed interaction, Total Blocking Time as approximation |
| Cumulative Layout Shift | up to 0.1 | over 0.25 | loading phase only in navigation mode |
| Time to First Byte | up to 800 ms | over 1.8 s | measurable |
This defines the structure of every template: a lab measurement under defined conditions checks before merge whether the change works in the right direction. Sign-off only happens with field data after go-live. How the two sources differ is described in Measuring Core Web Vitals.
Structure of the ticket templates: baseline, target value, checks and evidence
- Ticket title with page type, metric and target value. A ticket applies to one page type, not to the whole platform.
- Context with the measured baseline, its source and the date. Without a baseline, an improvement cannot be proven.
- Acceptance criteria before merge from the lab and from code checks that the team can run itself.
- Acceptance criteria after go-live from field data, 28 days later.
- Evidence attached to the ticket, so the sign-off is possible without follow-up questions.
Largest Contentful Paint ticket template: name the LCP element, shorten its loading path
Ticket title: [Page type]: Largest Contentful Paint on mobile at most [2.5] seconds at the 75th percentile
Context: Baseline at the 75th percentile on mobile: [value] seconds according to [Chrome User Experience Report or real user monitoring], as of [date]. LCP element on this page type: [image, heading or text block]. Reference URLs: [list].
LCP before merge: LCP element, image size and lab measurement
- The LCP element of the page type is named. If it is an image, it loads without lazy loading, with
fetchpriority="high"and in a size that matches the rendered width. - No render-blocking resource that is not needed for the first view loads before the LCP element, in particular no third-party script.
- Lab measurement on the reference URLs under defined conditions (device, network throttling, median of [5] runs): Largest Contentful Paint at most [value] seconds.
- No other metric gets worse by more than [10] percent compared with the baseline in the same measurement.
LCP after go-live: 75th percentile of field data over 28 days
- Largest Contentful Paint of the page type is at most [2.5] seconds at the 75th percentile of mobile field data over 28 days.
- If the value deviates, a new ticket is created with the measured value as baseline.
Evidence: Measurement log with conditions, URLs, date and values before and after the change, plus a link to the field data analysis after 28 days.
Interaction to Next Paint ticket template: measure the most frequent interactions, relieve the main thread
Ticket title: [Page type]: Interaction to Next Paint on mobile at most [200] milliseconds at the 75th percentile
Context: Baseline at the 75th percentile on mobile: [value] milliseconds according to [source], as of [date]. Slowest interaction according to real user monitoring: [element and interaction].
INP before merge: named interactions with CPU throttling
- The [3] most frequent interactions of the page type are named, such as opening the menu, setting a filter or typing into a form field.
- Each of these interactions is measured in the Performance panel of Chrome DevTools or in Lighthouse timespan mode with [4x] CPU throttling and takes at most [value] milliseconds.
- Total Blocking Time of the page is at most [value] milliseconds in the lab measurement, as an approximation of main thread load during page load.
- No new third-party script without approval against the performance budget.
INP after go-live: field data with interaction attribution
- Interaction to Next Paint of the page type is at most [200] milliseconds at the 75th percentile of mobile field data over 28 days.
- Real user monitoring attributes slow interactions to an element, so that a regression can be traced to a component.
Evidence: Recording of every named interaction with duration, device and throttling, plus a link to the field data analysis after 28 days.
Cumulative Layout Shift ticket template: reserve space, including for late-loading components
Ticket title: [Page type]: Cumulative Layout Shift at most [0.1] at the 75th percentile
Context: Baseline at the 75th percentile on mobile: [value] according to [source], as of [date]. Largest shift according to measurement: [component].
CLS before merge: dimensions, reserved space and a manual test
- All images, videos, iframes and ad slots have width and height or a fixed aspect ratio in the markup.
- Late-loading components such as personalization, notices and the consent banner have reserved space with a fixed height or appear as an overlay without shifting content.
- Switching from the fallback font to the web font does not shift visible content.
- Lab measurement: Cumulative Layout Shift at most [value]. In addition, a manual test with scrolling and the most frequent interactions, because the lab measurement of the page load only covers the loading phase.
CLS after go-live: field data including scrolling and interaction
- Cumulative Layout Shift of the page type is at most [0.1] at the 75th percentile of mobile field data over 28 days.
Evidence: Measurement log with the shifted elements before and after the change, result of the manual test, link to the field data analysis after 28 days.
Time to First Byte ticket template: cache hit ratio as an acceptance criterion
Ticket title: [Page type]: Time to First Byte at most [800] milliseconds at the 75th percentile
Context: Baseline at the 75th percentile on mobile: [value] milliseconds according to [source], as of [date]. Cache hit ratio for this page type: [value] percent.
TTFB before release: cache hit ratio, parameters and invalidation
- At least [value] percent of anonymous requests for the page type are answered from the cache, demonstrated from the cache and CDN logs.
- Campaign parameters such as
utm_source,gclidandfbclidcause no cache miss. The test case is documented. - A publication invalidates no more than necessary. The scope (page, subtree or site) is documented and backed by a test case.
- On a cache miss, the application responds within at most [value] milliseconds, and there is no redirect chain in front of the page.
TTFB after go-live: response time for real visitors per page type
- Time to First Byte of the page type is at most [800] milliseconds at the 75th percentile of mobile field data over 28 days.
Evidence: Excerpt from the cache and CDN logs with cache hit ratio per page type, result of both test cases, link to the field data analysis after 28 days.
Definition of done for performance: five points for every release
The tickets cover targeted improvements. To keep a platform from getting slower again after optimization, five points belong in the team's definition of done:
- For every affected page type, there is a measurement log with defined conditions, before and after the change.
- Budgets for JavaScript, CSS and images are checked in the build pipeline. Exceeding a budget fails the build.
- Every new third-party script is approved against the performance budget and has a named owner.
- No metric gets worse by more than [tolerance] percent compared with the last release.
- 28 days after go-live, the field data is checked. Every deviation from the target value becomes a new ticket.
The budget check in the pipeline can be implemented with Lighthouse CI or with PerfDelta, which checks budgets per URL against field and lab data. How target values are set and prioritized is described in Website Performance Optimization.
Download: ticket templates as PDF under CC BY 4.0
The templates as a PDF contain all four tickets and the definition of done with checklists to transfer into Jira, Azure DevOps, GitLab or GitHub. They are licensed under Creative Commons Attribution 4.0: clients, agencies and IT service providers may use and adapt them, including in commercial projects, with the attribution "Christian Schreiber, ch-schreiber.net".
The requirements these tickets come from are in the specification templates AEM Performance Requirements Template and Magnolia Performance Requirements Template.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, whether or not a collaboration follows.
Frequently asked questions about acceptance criteria for Core Web Vitals
Why is a Lighthouse score not enough as an acceptance criterion?
Lighthouse measures a simulated page view without real devices, without real networks and without consent given, so without the tags that only load after consent. Google, by contrast, assesses the 75th percentile of real visits over 28 days. A Lighthouse score works as a check before merge, sign-off happens with field data per page type.
How is Interaction to Next Paint checked before go-live?
With named interactions that are executed and measured in the Performance panel of Chrome DevTools or in Lighthouse timespan mode with CPU throttling. A pure load check does not capture any interaction. Total Blocking Time only serves as an approximation of main thread load there.
Who signs off performance tickets?
Ideally a party that is not itself responsible for the implementation. The team checks the criteria before merge itself. An independent party checks the evidence in field data after 28 days against target value and baseline.