Core Web Vitals are operations One-off optimizations fade away as long as performance budget, release sign-off and monitoring are missing
To me, Core Web Vitals are an operations topic, not a project. An optimization project ends with good values and a handover. The platform keeps running afterwards: every release, every campaign and every new tag changes load time, responsiveness and layout stability. Without fixed rules in day-to-day operations, the values drift back to where they were before the project.
I base this position on two sources: my own Core Web Vitals Benchmark 2026 with Google's real-user data for the DACH region, and what keeps showing up in projects on Adobe Experience Manager and Magnolia CMS. At the end are the three routines I consider indispensable.
Core Web Vitals in the AEM benchmark: 49.4 percent pass on smartphones
In the AEM Core Web Vitals Benchmark, 49.4 percent of the 4,222 AEM datasets from Germany, Austria and Switzerland pass all three Core Web Vitals on smartphones. Across all websites in the three countries, the figure is 68.7 percent, data as of August 2026. In the Magnolia CMS Benchmark, which is based on a separate crawl of 148 websites, 64.2 percent pass.
On its own, this snapshot says little about whether good values last. That takes a trend over several months.
Trend since January 2024: shares that were reached do not hold by themselves
The HTTP Archive API provides the shares on a monthly basis, in the benchmark from January 2024 onwards. At that point, 45.2 percent of AEM websites passed on smartphones, in January 2026 51.7 percent and in August 2026 49.4 percent. Over the same period, the overall market in the three countries rose from 62.2 to 68.7 percent.
I draw two conclusions from this. First, the market is moving: if you only hold your values, you fall behind your competitors. Second, a level once reached is not stable, because between January and August 2026 the share of AEM websites went down again.
The line mixes real work on the platforms with a population that changes every month. For a single platform, it therefore proves nothing. But it matches what projects show: without rules in operations, a gain is gradually used up.
INP instead of FID from March 2024: Google moves the bar
Besides your own platform, the yardstick changes too. On 12 March 2024, Interaction to Next Paint replaced First Input Delay as a Core Web Vital (web.dev). INP evaluates the response time of all interactions during a visit, whereas FID only captured the waiting time before the first input (web.dev on INP).
In the benchmark's time series, the share of passing AEM websites fell from 45.6 to 39.8 percent from February to March 2024, and the overall market from 62.1 to 56.4 percent. My assumption is that some of these websites changed nothing that month and still stopped passing. If Core Web Vitals were booked as a completed project, there is neither budget nor ownership for a change like this.
Releases, campaigns and tags: three sources of regression in day-to-day operations
Projects show the same pattern again and again. Degradation rarely arrives with a major rebuild, but in small steps that are each justifiable on their own:
- Releases: a new component brings its own JavaScript, an update enlarges a library, a change to the cache key lowers the hit ratio. Each of these changes passes its functional sign-off, while load time is often not checked at all.
- Campaigns: a hero image in the wrong size delays Largest Contentful Paint, a late-loading banner without reserved space shifts the layout. Campaigns run through the editorial team, not through development.
- Tags: new scripts go live through a tag manager without any deployment. According to the Web Almanac 2025, around 90 percent of all pages include at least one third party. How these scripts affect responsiveness is covered in Third-Party Scripts.
An optimization project cleans up the existing stock. It does nothing against the inflow, because the inflow continues after the project ends.
28-day window in the Chrome UX Report: regressions become visible late
Google assesses the Core Web Vitals from the Chrome User Experience Report, at the 75th percentile over a rolling 28-day window (CrUX methodology). A release that worsens the values only shows up in this data after days and is fully reflected only after four weeks. A fix takes just as long again.
If you only watch Google's data, you learn about a regression when it has already been in the field for weeks. For a project with a final report, that is no problem; for a platform with releases every two weeks, it is: by the time a degradation stands out, two more releases are live, and the cause can hardly be traced.
Performance budget, release sign-off and monitoring keep Core Web Vitals in check during operations
This leads to three routines that should keep running after every project. None of them is costly, but each needs an owner.
- Performance budget per page type: limits for JavaScript, image weight, number of third parties and lab values, checked in the delivery pipeline. A build that breaks the budget is rejected or released deliberately. Structure and values are described in Performance Budget.
- Release sign-off against target values: before go-live, a lab measurement per page type against the budget; after go-live, the comparison with field data. Deviations become tickets with measured value, target value and acceptance criterion.
- Monitoring in the field: real user monitoring by page type, market and device reports a degradation within a day instead of after four weeks. New tags go live only after a check against the budget.
The routines answer the three sources of regression: the budget catches releases, the sign-off turns deviations into tasks, and monitoring shows what campaigns and tags do in the field.
Ownership of performance: a line in the operating budget instead of a project
The organizational consequence is less comfortable than the technical one. A project has a budget, a start and an end; afterwards, nobody feels responsible. In operations, performance needs the same as availability or security: a named owner, a fixed place in release planning and a line in the running budget. Without that line, there is no money for the fix at the next setback, and the next project starts again from the baseline.
That is why I put little weight on how fast a platform is at the end of a project. More telling is how fast it is twelve months later and whether anyone would have noticed a degradation in between. My part in this is target values, measurement and sign-off; implementation stays with the team that builds the platform every day. The process is described in Website Performance Optimization, and why sign-off should not sit with the implementing team is the subject of the position Sign-off separate from implementation.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, regardless of whether we work together.
Frequently asked questions about Core Web Vitals in operations
Is one optimization project per year enough for good Core Web Vitals?
An annual project cleans up the existing stock. Between two projects, however, releases, campaigns and new tags keep coming, and Google always assesses the last 28 days. What counts is therefore the state in every month, not at the end of the project. Ongoing control with a performance budget per page type and a sign-off per release is more effective.
What role does real user monitoring play in operations?
It shortens the time until a degradation stands out. Google's data reflects a release fully only after four weeks, while real user monitoring shows the change by page type, market and device within a day. The yardstick for sign-off remains the field data at the 75th percentile.
Who should own Core Web Vitals in operations?
A named person on the platform operator's side, often the platform owner or the product owner. In addition, each value in the performance budget gets an owner, for example marketing for tags and development for JavaScript. Without this assignment, a reported degradation stays unresolved.