In short
Performance is best treated as an ongoing product feature — budgeted, monitored, and maintained continuously — rather than a one-time optimization phase completed before launch, since every new feature and dependency added afterward has the potential to erode performance gains that were never protected by ongoing measurement.
The phase framing and its hidden assumption
Scheduling "performance optimization" as a discrete phase — typically right before launch — implicitly assumes performance is a problem that gets solved once and stays solved. This assumption is wrong in a specific, predictable way: every feature, dependency, and content addition made after that phase has the potential to erode the gains it achieved, and without ongoing measurement, that erosion happens invisibly.
Why performance regresses by default
Absent active protection, performance tends to degrade over time as a natural consequence of normal product development — a new library added for a feature, an additional image, a third-party script for a new integration. None of these individual additions feels like a performance decision in the moment, but their cumulative effect is a real, gradual regression that a one-time optimization phase did nothing to prevent.
What treating it as a feature actually means
A feature has an owner, a definition of done that includes it, and ongoing measurement of whether it's working — applying the same framing to performance means a performance budget enforced continuously (ideally automated in CI), real-user monitoring tracked over time, and performance considered part of the definition of done for new features, not a separate concern addressed afterward.
The team dynamic this shifts
When performance is a one-time phase, it's someone else's problem to have solved already by the time a new feature ships — which means the team building the new feature has little incentive to consider its performance impact. When performance is an ongoing, measured feature with an enforced budget, every contributor has a direct, immediate signal (a failed CI check, a budget violation) if their change degrades it, which distributes the responsibility rather than concentrating it in an occasional cleanup effort.
The cost comparison
A performance regression caught immediately, at the moment it's introduced, is typically a small, quick fix — identify the specific new dependency or asset causing it and address it directly. The same regression, left unaddressed for months while more changes accumulate on top of it, becomes a much larger, harder-to-diagnose problem, often requiring a full audit to untangle which of many subsequent changes actually caused the degradation.
A practical reframe
Instead of scheduling a performance optimization phase, schedule the infrastructure that makes performance an ongoing, visible property of the product: a budget enforced in CI, real-user monitoring with alerting, and performance considered explicitly in code review, the same way correctness and security already are. This is a genuinely different, and more effective, way to relate to performance than treating it as a project with an end date.
Keep reading: How to Measure Real-User Performance.
Primary source: web.dev’s Core Web Vitals guidance documents the specifics referenced above.
Common questions
Isn't a dedicated performance optimization phase still useful?
It can address existing problems, but without ongoing measurement and an enforced budget afterward, the gains from that phase erode as normal product development continues — the phase alone doesn't prevent regression.
Why does performance tend to regress over time by default?
Because normal development — adding features, dependencies, images, and third-party scripts — has a cumulative performance cost that isn't visible in any single change, absent continuous measurement catching it.
What does treating performance as an ongoing feature require in practice?
A performance budget enforced automatically (ideally in CI), real-user monitoring tracked continuously, and performance considered as part of the definition of done for new features, not addressed separately afterward.
