Web performance optimization: Core Web Vitals, method and business impact

A rapide site is not the one that gets 100 in a lab on a Tuesday morning. It’s the one that responds quickly enough to real users, on the routes that matter, without sacrificing accessibility, measurement or functionality.

1. The operational definition: experienced speed, responsiveness and stability

Web performance is the ability of a page or application to make content useful, respond to interactions and remain visually stable within an acceptable time frame for its real users.

Core Web Vitals measure three dimensions:

• Largest Contentful Paint (LCP) : appearance of the main content perceived;
• Interaction to Next Paint (INP) : visual response time to interactions;
• Cumulative Layout Shift (CLS) : Unexpected instability of the layout.

Google classifies an experience as "good" when LCP ≤ 2,5 s, INP ≤ 200 ms, and CLS ≤ 0,1 at the 75e percentile. This means that at least 75 % visits in the segment must meet each threshold. An average sometimes hides the most penalized users.

2. Key figures: the Web is growing, and the traffic rate decreases with weight

The case studies illustrate a method, not a universal coefficient “100 ms = x%”. Offer, traffic, devices, season, country and route modify the effect. The right promise is about measuring the customer’s context.

3. The performance income statement

Each element added to a page creates an initial cost and a recurring cost. A hero video consumes transfer, decoding and sometimes stability. A font adds files and potential blocking. A marketing tag executes code, calls other domains, and can change without deployment. A client component increases downloading, hydration, memory and maintenance.

The “performance budget” works like a financial budget: it sets an envelope before the purchase and requires arbitration. It must not be an arbitrary technical limit copied from another site. It starts from the devices, networks, routes and field thresholds targeted.

When the budget is exceeded, the team removes, defers or proves the value of the addition. A dated, owned exception is better than a limit that everyone ignores.

4. HTTP, browsing, cache, third parties, delays, JavaScript and rendering: one budget per owner

A global envelope of 1,5 MB is not enough if no one knows who consumed the bytes. Break it down by responsibility: content for media, design system for fonts and styles, marketing for tags, frontend for interactive code, platform for server and cache.

This attribution makes the arbitrage concrete when a campaign requests a video, two pixels and a widget: the team immediately sees the effect on the pages, the most constrained devices and the remaining margin, then chooses between compression, conditional loading, replacement or removal of an older element.

The budget must also relate to CPU time, because two scripts of identical weight do not impose the same work: one parses then waits, the other executes a long calculation, traverses the DOM, triggers styles and blocks the interaction at the precise moment when the user tries to open the menu.

Finally, assign a lifespan to third parties. A campaign tag expires. An embed receives an alternative. A temporary test is withdrawn. An owner confirms every quarter that the value still exists, otherwise the component leaves the page and frees up capacity for a truly useful need.

Governance becomes visible. The debate too. This is desirable.

Without this mechanism, the collective cost remains diffuse while each local addition seems almost free; several rational decisions taken separately then produce a slow experience that no one explicitly chose.

A thirty-minute monthly review is often enough for important pages: note the deviations, attribute their source, check the exceptions and remove what has lost its purpose. Before a campaign or product release, the same magazine becomes a gateway to acceptance with field data, laboratory data and testing of marketing events.

The goal is not to prevent change. It requires that each major addition show its value, its cost and its owner before occupying the common budget sustainably. This rule also protects teams: they arbitrate on shared data instead of defending invisible optimization alone in the face of immediate commercial demand.

5. Diagnosis: reading a waterfall as a chain of responsibility

5.1. Step 1 — Choose a route and segment

Avoid “the site is slow”. Select page, device, country, traffic source and action: mobile product sheet from a campaign, B2B form on professional devices, customer area after connection.

Gather field data over several weeks, reproducible laboratory metrics, logs and business metrics. Field data reveals the actual distribution; the laboratory allows a change to be reproduced and compared. Lighthouse is neither CrUX nor full monitoring.

5.2. Step 2 — Decompose LCP

LCP can be broken down into server time, resource discovery time, download time and rendering time. The solution depends on which piece is dominant.

• High TTFB: cache, backend, base, geography or overhead;
• image discovered late: priority, HTML, incorrect lazy loading or CSS;
• slow download: weight, format, CDN, dimensions;
• delayed rendering: CSS/JS blocking, hydration or main thread busy.

Optimizing the image without looking at its discovery can gain little. Preloading all images creates the opposite effect.

5.3. Step 3 — Decompose INP

INP observes the latency of interactions during the visit. An interaction includes entry time, handler processing, and presentation time. Look for long tasks, third party JavaScript, excessive rendering, synchronous calculation and massive DOM updating.

Break down work, avoid unnecessary re-renders, move some calculations to a worker, reduce scripting, and provide feedback rapide. A spinner displayed after two seconds is not a response rapide.

Test modest devices. The developer's recent post runs the same JavaScript much faster than a user's median or older phone.

5.4. Step 4 — Decompose CLS

Shifts often come from images without dimensions, injected content, fonts, advertisements, banners and animations that modify the layout. Reserve space, use aspect-ratio, stabilize fonts and insert messages without pushing active content.

The laboratory tool helps locate. The field reveals late lags after interaction or personalized content, sometimes invisible on initial loading.

5.5. Step 5 — Map Third Parties

For each script: internal owner, purpose, data, weight, CPU time, cascading domains, consent and review date. Disable it on a measurement environment and observe performance over business metrics.

Tags installed via a manager can bypass the development pipeline. Install publishing rules, automatic inventory and alert on new domains.

5.6. Step 6 — Follow network and server path

DNS, TLS, CDN, edge, load balancer, application, cache, base and API contribute to the delay. A distributed trace or Server-Timing headers connect the layers. Averages overwrite peaks: look at p50, p75, p95 and p99 depending on risk.

A cached page may be rapide while a custom search remains slow. Measure operations and data actually used.

6. Prioritization: the impact × reach × trust × effort matrix

Assign to each improvement: estimated technical gain, share of traffic affected, importance of the journey, confidence in the diagnosis and complete effort. Include regression risk.

Quick wins exist, but lasting discipline also corrects the source: image component, CMS rule, tag governance or pipeline. Otherwise, the default returns to the next campaign.

7. Recommended method: measure, isolate, test, deploy, keep

7.1. Reference state

Record Core Web Vitals by size and segment, server metrics, weights, scripts and business KPIs. Keep period, seasonality, campaigns and changes.

7.2. Causal hypothesis

Formulate: “reducing the lead image discovery time should improve LCP on mobile, without decreasing quality or increasing CLS”. A precise hypothesis chooses the measures and safeguards.

7.3. Breeding

Create a stable lab test, then verify that the problem matches the field. A synthetic throttling does not perfectly imitate a device; it is used to compare.

7.4. Isolated change

Change a small number of factors. Run functional, visual, accessibility and analytics tests. An optimization that breaks consent or rendering is not a success.

7.5. Gradual deployment

Use feature flag, sample or A/B test when volume allows. Compare technical metrics, conversion, quality and support. Vodafone and Rakuten isolated an optimized version to estimate the effect in their context.

7.6. Permanent guardrail

Add CI budget, field monitoring, regression alert and quarterly third party review. Performance becomes a product property, not an annual campaign.

8. Who owns the performance?

Performance deteriorates when everyone adds locally and no one owns the global envelope.

9. Cost and return: building an honest business case

Calculate affected volume, path value, technical deviation, plausible gain and full cost. Present multiple scenarios instead of a single promise.

Potential monthly value = eligible sessions × conversion rate × unit value × observed improvement.

The “observed improvement” must come from a site-specific test or a clearly labeled range as a hypothesis. The Vodafone and Rakuten cases prove that the effect can be measured; they do not provide a multiplier to copy.

Add the avoided costs: infrastructure, abandonment, support, technical SEO, accessibility on modest devices and team productivity. Then add maintenance: without budgets and monitoring, the gains erode.

10. Logiks Tips: Six anti-scoring rules

1. Don’t just drive the Lighthouse score; look at the metrics and their distribution.
2. Segment by size and device before announcing an average.
3. Optimize the path that leads to a decision, not the easiest page to show.
4. Delete before compressing what has no owner or value.
5. Tie marketing scripts to a decision and an expiration date.
6. Block regressions in the delivery system, not by collective memory.

11. Roadmap 30 / 60 / 90 days

11.1. Days 1 to 30 — Measure correctly

• install or make Real User Monitoring more reliable;
• group pages by template;
• link sessions, Web Vitals and KPIs when legal;
• inventory weight, scripts and third parties;
• select two priority routes.

11.2. Days 31 to 60 — Correct the dominant causes

• break down LCP, INP and CLS;
• process images, rendering, JavaScript and server according to evidence;
• remove unnecessary third parties;
• create CI budgets and tests;
• validate accessibility and tracking.

11.3. Days 61 to 90 — Prove and rule

• gradually deploy or experiment;
• compare technology and business;
• document results and limitations;
• integrate performance into launch criteria;
• plan quarterly review and owner by budget.

12. FAQ

12.1. What are good Core Web Vitals thresholds?

At the 75e percentile, Google defines good LCP ≤ 2,5 seconds, INP ≤ 200 milliseconds, and CLS ≤ 0,1. Each metric must be good for the overall assessment to pass.

12.2. Do Lighthouse and PageSpeed ​​Insights measure the same thing?

Lighthouse primarily produces a laboratory measurement in a simulated environment. PageSpeed ​​Insights can present both CrUX field data and Lighthouse diagnostics. The two answer different questions.

12.3. Does a more rapide site always convert better?

Not automatically. Vodafone and Rakuten tests have observed gains in their contexts, but offer, traffic and experience intervene. Measure your own effect with a baseline and, if possible, an isolated change.

12.4. Should we aim for a score of 100?

Not as a business objective. Aim for field thresholds on critical paths, a stable experience and a system without regressions. A one-time perfect score can hide slow users or a worthless page.

12.5. What is the first lever to optimize?

The one that the diagnosis identifies. Often, LCP image, third-party JavaScript rendering, and TTFB provide gains, but their priority depends on the segment and critical path. Start with the waterfall and field data.

12.6. How often to monitor performance?

Continuously for field data and with each delivery for technical budgets. Carry out a broader review before the campaign, redesign, addition of third-party tools and at least every quarter for governance.

13. Conclusion

Optimizing web performance is about protecting the user’s time and device. Core Web Vitals thresholds provide a common language; value emerges when the team connects these metrics to a business journey and decision.

Sustainable gain does not come from a week of compression. It comes from a budget, managers, tests and an explicit right to refuse what adds weight without producing value.

14. Main sources

1. HTTP Archive — Web Almanac 2025, Page Weight, published in 2026.
2. HTTP Archive — Web Almanac 2025, Performance, published in 2026.
3. web.dev — Core Web Vitals thresholds, updated May 2025.
4. web.dev — Vodafone case study, March 2021.
5. web.dev — Rakuten 24 case study, August 2022.
6. web.dev — Renault case study, accessed on July 13 2026.
7. web.dev — Farfetch case study, accessed on July 13 2026.
8. Google Search Central — Page experience guidance, accessed on July 13 2026.