Dati prodotto strutturati significa che ogni informazione sul prodotto vive in un attributo tipizzat…
Performance Budgets 2026: Who Owns the Speed Number?
Who owns the speed number when marketing builds pages itself?
The short answer: nobody, as long as the performance budget is not defined as a team discipline first. That is exactly the gap that becomes visible in 2026. The moment marketing teams compose landing pages and campaign pages on their own in the editor, ownership of Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) drifts into a gray zone. Marketing builds the page but does not measure the speed number. Engineering measures it but no longer builds the page. And the result lands as a ticket in the next sprint, after conversion has already taken the hit.
This article is deliberately not the hundredth speed-equals-revenue piece. That correlation is well known. The open question is a different one: who owns the budget once composition is democratized? We argue for performance budgets as a binding discipline with clear ownership and automatic guardrails in the editor, instead of after-the-fact dev firefighting. The audience is the CMO, CFO, and engineering lead who jointly own this number.
What is a performance budget?
A performance budget is a binding upper limit for the metrics that determine how fast a page loads and how interactive it is. It is not an aspiration but a rule that takes effect in the build and publish process, before a page goes live.
The three core metrics are Google's Core Web Vitals, because they are public, measurable, and ranking-relevant:
- LCP (Largest Contentful Paint): Target under 2.5 seconds. Measures when the largest visible element has loaded.
- INP (Interaction to Next Paint): Target under 200 milliseconds. Measures how quickly the page responds to user input. INP replaced First Input Delay as a vital in 2024 and is therefore the relevant responsiveness number for 2026.
- CLS (Cumulative Layout Shift): Target under 0.1. Measures visual stability, meaning whether content jumps around as it loads.
A performance budget locks these thresholds in place and defines what happens when a page breaks them. It is this second part, the consequence, that is missing from most setups. Without a consequence, a budget is just a note in Confluence.
The ownership gap: when marketing composes pages
Classically, responsibility was cleanly split. Engineering built the page, engineering owned its performance. If a page was slow, it was clear whose backlog carried the problem.
In the model where marketing teams compose on their own using a Frontend Management Platform (FMP), that clean split breaks down. Marketing picks components, uploads images, drops in hero videos, adds a third tracking script, and publishes without a developer ticket. That is precisely the speed gain everyone wants. But every one of those decisions has performance consequences:
- An uncompressed hero image tips over the LCP.
- An extra marketing script degrades the INP because it blocks the main thread.
- A late-loading banner without reserved height creates layout shift and pushes up the CLS.
The ownership gap appears because the person building the page neither sees nor owns the speed number, while the person who owns the number no longer builds the page. This is not a question of blaming marketing. It is a structural governance problem. A responsibility that sits between two teams effectively sits with neither.
It shows up in the budget too. Anyone planning the experience layer as its own line item for 2027 has to assign performance ownership explicitly, otherwise it reappears as unplanned dev work.
LCP, INP, and CLS as budget metrics, not as a quarterly report
The decisive shift is to treat these three values not as an after-the-fact report but as a budget line with a target. A quarterly report tells you the page was slow last quarter. A budget prevents it from ever going live slow in the first place.
In concrete terms, each metric gets a fixed threshold that is checked in the publish process:
- Metric | What it measures | Budget threshold | Typical trigger on breach
- LCP | Load time of largest element | < 2.5 s | Uncompressed hero media, blocking fonts
- INP | Response to input | < 200 ms | Too many marketing/tracking scripts
- CLS | Visual stability | < 0.1 | Late-loading banners with no reserved space
These values are not invented, they are the public Core Web Vitals thresholds from Google. The difference is not in the numbers but in anchoring them as a binding rule inside the workflow rather than as a metric on a dashboard you glance at at quarter's end.
A responsibility matrix for marketing, dev, and leadership
Performance governance only works when every role knows what it owns. The following matrix is a starting point you can adapt to your organization. What matters is the logic behind it: the budget is set jointly but owned in clearly distributed ways day to day.
- Area of responsibility | Marketing / E-Commerce | Engineering | Leadership (CMO/CFO/Eng lead)
- Define the budget (set thresholds) | involved | involved | decides
- Build components (guardrails) | uses | builds + maintains | funds
- Compose + publish the page | owns | supports | -
- Media optimization (images, video) | owns in the editor | automated in the layer | -
- Measure performance + alert | sees in the editor | runs monitoring | sees in the report
- Fix a budget breach | first responder in the editor | second responder at the component | escalates on conflict
- Decide speed vs. feature trade-off | proposes | assesses technically | makes final call
The core of this matrix is the row Fix a budget breach. When marketing uploads an oversized image, it should see that in the editor immediately and correct it on its own, rather than triggering a dev ticket after launch. Engineering owns the guardrails, not every individual page. And leadership owns the fact that the budget exists at all and that, when campaign speed and the speed number conflict, a decision actually gets made.
How an FMP brings the guardrails into the editor
The difference between a performance budget on paper and one that actually works lies in where it is enforced. A Frontend Management Platform can enforce the budget right where the page is created, that is, in the editor itself, instead of in a downstream code review.
In practice, this means marketing composes within guardrails that engineering defined once:
- Components with a built-in budget: Engineering maintains a central component library in which performance is already included. When marketing composes from it, every page inherits these properties instead of risking them anew per page. The same logic applies to brand consistency when marketing composes pages: what is defined centrally can be used in a decentralized way without quality drifting apart.
- Automatic media optimization: Images are converted to modern formats, scaled, and lazy-loaded in the layer. Marketing does not need to operate an image tool, the LCP protection kicks in automatically.
- Budget feedback in the editor: Instead of a quarterly report, the person composing sees a warning directly when an action breaks the budget. The correction happens before publishing, not after.
- Monitoring after launch: Performance monitoring based on field data detects regressions per deploy and alerts before they become a conversion dip.
The result is a shift in the logic. Performance is no longer a sprint task at quarter's end but a platform property that takes effect at the moment of composition. Marketing keeps its speed, engineering keeps control of the guardrails, and leadership gets a number that does not have to be explained after the fact.
FAQ
Who should formally own the performance budget? The thresholds belong with leadership, because they represent a trade-off decision between marketing speed and technical quality. Day-to-day adherence is distributed: marketing for composition, engineering for the guardrails. A budget with no formal owner in leadership stays non-binding.
Does a performance budget slow marketing down? No, if it is enforced in the editor rather than in code review. A warning on image upload costs seconds. A dev ticket after launch costs a sprint. The budget protects speed by preventing rework.
Is a monitoring tool not enough on its own? Monitoring tells you a page is slow, that is, after it is live. A budget prevents it from going live slow. The two belong together: guardrails before launch, monitoring after.
What sets INP apart from the old First Input Delay? INP measures responsiveness across the entire lifetime of a page, not just the first interaction. That makes it the stricter and more realistic number for interactive storefronts, and it has been the official Core Web Vital since 2024.
Next steps
Performance budgets are not a tooling question, they are a governance question. The first step is not buying software but giving a clear answer to the opening question: at your organization, who owns the speed number when marketing builds pages itself?
If you want to assign that responsibility cleanly and enforce it automatically, it is worth looking at how a Frontend Management Platform anchors guardrails in the editor and how performance and Core Web Vitals work as a platform property rather than a sprint task.
Further reading: