A redesign stays fast only when performance becomes a product constraint after launch, not a one-time Lighthouse task before launch. Use Core Web Vitals as field-experience guardrails, diagnose them at the template and component level, and pair them with budgets for images, JavaScript, fonts, motion, and third-party code. The current “good” thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less, evaluated at the 75th percentile.
The key tradeoff: rich media and interactivity are not automatically bad, but every visual or behavioral feature spends part of a finite loading, interaction, and stability budget.
1. Know what LCP, INP and CLS actually tell you
Core Web Vitals describe three different parts of the user experience:
- Largest Contentful Paint (LCP) measures loading performance. Google recommends 2.5 seconds or less for a good experience.
- Interaction to Next Paint (INP) measures interaction responsiveness across the page visit. Google recommends 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures unexpected visual movement. Google recommends 0.1 or less.
The thresholds are intended to be assessed at the 75th percentile, separated across mobile and desktop. That matters because a fast developer laptop is not representative of every visitor.
These metrics are useful constraints, not complete UX scores. A page can pass Core Web Vitals and still be confusing, inaccessible, or commercially ineffective. It can also have an excellent lab run while real users experience slow networks, weaker devices, long sessions, or third-party contention.
| Metric | User experience question | Common redesign causes | First places to inspect |
|---|---|---|---|
| LCP | “How quickly does the main content feel loaded?” | Hero media, server delay, render blocking, late discovery | LCP element, TTFB, image request timing, CSS/fonts |
| INP | “How quickly does the page respond when I interact?” | Long JS tasks, heavy hydration, expensive handlers, third parties | Interaction traces, long tasks, component work, script ownership |
| CLS | “Does the page stay visually stable?” | Missing dimensions, injected banners, late fonts/content | Shift sources, media dimensions, embeds, dynamic UI |
2. Use field data to find reality and lab data to find causes
A sustainable performance process uses both field and lab data because they answer different questions.
Field data comes from real users. Chrome User Experience Report (CrUX) powers field views in tools such as PageSpeed Insights and Search Console when sufficient data exists. Field data captures the variety of devices, networks, caches, sessions, and interactions that a synthetic run cannot reproduce.
Lab data runs in a controlled environment. Chrome DevTools and Lighthouse are useful for reproducing problems, inspecting waterfalls, finding long tasks, testing code changes, and preventing regressions before release.
Lighthouse cannot directly measure INP in a no-user synthetic run; Total Blocking Time can help diagnose main-thread risk, but it is not a replacement for INP field data. Treat the two as complementary.
A good diagnostic loop
- Find a poor template or URL group in field data.
- Reproduce a representative page in lab tooling.
- Identify the element, request, task, or component responsible.
- Make one targeted change.
- Run lab regression tests immediately.
- Watch field data after enough real traffic accumulates.
Do not wait for a monthly report to discover that a deploy added a 3 MB hero or a synchronous marketing script. CI and pre-release checks should catch obvious budget violations before they reach users.
3. Diagnose by template and component, not by one homepage score
Redesigns usually create shared components: hero, navigation, card grid, testimonial carousel, pricing table, form, footer, cookie manager, analytics layer. That makes component-level diagnosis more valuable than chasing isolated URLs.
If every service page has poor LCP, inspect the shared service hero. If product pages have high INP after opening filters, inspect the filter interaction and its data/render path. If CLS appears across pages after the consent banner loads, fix the banner behavior once.
A practical inventory records:
- affected route/template;
- failing or risky metric;
- responsible component;
- owner;
- evidence;
- proposed fix;
- validation method;
- rollout status.
This converts “performance is bad” into engineering work that can be assigned and verified.
4. Improve LCP by following the critical content path
LCP problems are often less about the final file format than about when the browser can discover and render the important content.
For an image LCP candidate, inspect:
- whether the image is present in the initial HTML or discovered late through client-side logic;
- whether it is unnecessarily lazy-loaded;
- whether responsive source selection serves a sensible size;
- whether the file is compressed appropriately;
- whether a preloaded resource actually matches the resource used;
- whether CSS or JavaScript delays visibility;
- whether server response time delays everything that follows.
For text LCP, fonts and render-blocking styles may matter more than image optimization.
Hero media needs an explicit policy
Marketing teams often add the largest asset to the most important area of the page. That is exactly why the hero needs guardrails:
- define allowed media types and dimensions;
- generate responsive derivatives automatically;
- require poster images for video;
- avoid autoplay video when it adds little explanatory value;
- load the most important visual intentionally rather than relying on generic lazy-loading rules;
- preview the mobile asset, not only desktop.
The right byte cap depends on the visual, route, CDN, device mix, and product requirements. Use a team budget and measure the result rather than presenting one universal file-size number as truth.
5. Improve INP by reducing work on the interaction path
INP is about the responsiveness users feel when they interact. A page can load quickly and still feel sluggish if clicks, taps, typing, or controls trigger expensive main-thread work.
Common redesign causes include:
- hydrating a large client-side component tree that does not need interactivity;
- filtering or sorting large collections synchronously;
- expensive state updates that rerender too much of the page;
- analytics handlers doing unnecessary work before the next paint;
- third-party widgets occupying the main thread;
- large JavaScript bundles parsed and executed on routes that barely use them;
- interaction handlers that combine computation, DOM updates, and network work in one blocking sequence.
A durable fix usually comes from architecture rather than micro-optimizing one callback:
- keep static content server-rendered where possible;
- isolate interactive islands;
- split expensive work;
- avoid unnecessary rerenders;
- defer non-essential work until after the visible response;
- load third-party functionality only where it is needed;
- test the actual interaction on representative devices.
Give interactions their own budget
A performance budget should include more than initial page weight. Identify critical interactions—navigation, menu open, filter, calculator, form step, modal, checkout action—and make their responsiveness part of QA.
6. Improve CLS by reserving space and controlling dynamic content
CLS is often a design-system problem hiding inside implementation details.
The most common prevention rule is straightforward: the page should know the size of important content before that content arrives.
Use explicit dimensions or aspect ratios for images and video. Reserve appropriate space for embeds. Avoid inserting banners above existing content after the user has started reading. Be careful when fonts change text metrics. Keep skeletons and loaded states geometrically compatible.
Dynamic personalization and consent UI deserve special attention because they can appear after initial render. A late banner, injected recommendation block, or experiment variant can create movement even when the core page was stable in a lab test.
7. Treat fonts as part of the rendering budget
Typography can be central to a brand redesign, but font strategy affects both loading and stability.
Useful decisions include:
- how many families and weights are truly required;
- whether variable fonts reduce or increase the practical payload for the chosen usage;
- what subset or language coverage is needed;
- whether local/system fallbacks can be metric-compatible;
- how font-display behavior affects the design;
- whether preload is limited to truly critical files.
Do not preload every font. Preload is a priority signal, and overusing it competes with other critical resources.
Review typography with real page templates. A font strategy that looks efficient on the homepage can still become expensive if every article or locale pulls additional weights and subsets.
8. Give third-party scripts an owner and a removal date
Third-party code is one of the easiest ways for a site to become slower after a successful launch. Analytics, experimentation, chat, personalization, consent, ad pixels, video embeds, social widgets, and sales tools can accumulate because each has a different business owner.
A useful registry records:
| Script/integration | Business purpose | Routes | Consent class | Loading rule | Technical owner | Review date |
|---|---|---|---|---|---|---|
| Analytics adapter | Product/marketing measurement | Approved routes | Analytics | Consent-aware, non-blocking | Data / engineering | Quarterly |
| Marketing pixel | Campaign attribution | Required routes only | Marketing | Consent-gated | Growth | Quarterly |
| Video/embed | Product explanation | Pages using media | Functional as applicable | Placeholder / lazy activation | Content / engineering | Per release |
| Chat/support | Visitor support | Selected commercial pages | Depends on provider | Delayed/intent-based | Support / engineering | Quarterly |
The specific list will differ by company. The important rule is that “marketing script” is not ownerless infrastructure. Every integration should have a reason to exist, a loading policy, and a path to removal.
9. Turn performance budgets into enforceable release rules
A budget that lives in a slide deck will not survive campaign pressure. Put budgets into the systems where work happens.
A practical budget can cover:
- Core Web Vitals field targets;
- route-level JavaScript growth;
- critical CSS or render-blocking resources;
- hero/image media policy;
- font families/weights and preload count;
- third-party scripts;
- critical interaction responsiveness;
- layout-shift regressions;
- total number of high-priority network requests.
Not every budget needs a universal numeric cap. Some are policy constraints: “no new synchronous third-party script in the critical path,” “no hero video without a mobile poster/fallback,” or “new components must reserve media dimensions.” Numeric caps are strongest when they are derived from the site's current baseline and desired user experience.
Example release policy
| Budget area | Policy | Automated check | Human check | Owner |
|---|---|---|---|---|
| CWV | Maintain good p75 targets where field data exists | Monitor/RUM alert | Review template regressions | Performance owner |
| Hero media | Responsive asset + explicit dimensions required | Asset rule/build check | Mobile visual QA | Design + engineering |
| JavaScript | Route growth must be explained | Bundle diff | Interaction trace | Engineering |
| Third parties | New vendor needs owner/loading rule | Script inventory | Privacy/performance review | Growth + engineering |
| Layout stability | No avoidable shifts in core templates | Visual/performance test | Dynamic-state QA | Frontend |
| Critical interactions | Key controls remain responsive | Interaction/lab trace | Representative-device test | Product engineering |
10. Keep the CMS inside the performance model
A redesign can launch with beautifully optimized assets and still degrade when editors upload original images, add several embeds, duplicate animation-heavy sections, or paste new tracking code.
The CMS should make the fast path the easy path:
- automatic image derivatives and sensible responsive markup;
- media validation and preview;
- components that reserve layout space;
- safe embed patterns;
- constrained animation options;
- no arbitrary script injection;
- preview warnings for unusually heavy content;
- reusable SEO and accessibility fields;
- clear ownership for third-party integrations.
Performance is easier to maintain when the publishing system prevents known regressions rather than asking every editor to become a performance engineer.
11. Monitor after launch with both trends and incident triggers
A monthly review is useful, but it is not enough. Performance needs two cadences:
Continuous or release-based controls catch regressions quickly. Bundle changes, asset size, script additions, and lab traces can be checked before or immediately after release.
Field-data trends show whether real-user experience remains healthy across devices and templates. CrUX, Search Console, PageSpeed Insights, and first-party real-user monitoring can contribute different views. Google explicitly notes that CrUX is useful for field assessment but does not provide the detailed per-pageview telemetry that many sites need for diagnosis, so first-party RUM can be valuable for faster, more granular investigation.
When a regression appears, record the change that caused it and the preventive rule that should stop the same class of issue next time. The objective is not merely to restore a score; it is to improve the system.
12. Connect performance to business carefully
Performance affects the experience through mechanisms that are easy to understand: visitors see meaningful content sooner, interactions respond faster, and the page moves less unexpectedly. Those improvements can reduce friction in commercial journeys.
What performance data does not do by itself is prove a specific revenue uplift. If conversion changes after a performance project, evaluate the result alongside traffic mix, campaigns, seasonality, pricing, page changes, and product factors. Use controlled experiments when feasible, and describe modeled scenarios as models rather than guarantees.
This causal restraint makes the performance case stronger, not weaker. It keeps teams focused on a measurable user experience rather than promising a universal percentage increase.
13. A performance-budget checklist teams can keep
- Identify the LCP element on important templates.
- Check real-user p75 LCP, INP, and CLS where field data exists.
- Compare mobile and desktop rather than averaging them together.
- Record the heaviest hero/media assets and their loading rules.
- Audit font families, weights, subsets, and preloads.
- Inventory route JavaScript and critical interactions.
- Assign an owner and loading rule to every third-party script.
- Verify images/video/embeds reserve layout space.
- Test consent banners, personalization, and experiments for layout shifts.
- Add budget checks to CI or release QA where they are automatable.
- Add representative-device interaction testing for important controls.
- Review field trends after releases and major campaigns.
- Turn every repeated regression into a component, CMS, or policy guardrail.
For teams planning the broader redesign, use the B2B website redesign strategy and Web Design & Development service to connect performance work to the full site system.
14. FAQ
Do we need to hit 100 in Lighthouse?
No. Lighthouse is a useful lab diagnostic and regression tool, not the product goal. Core Web Vitals are field-oriented user-experience metrics, and a site also needs accessibility, clarity, reliability, and business usefulness.
Why does PageSpeed field data differ from our Lighthouse run?
They measure different populations and conditions. Field data reflects real users across devices, networks, caches, and interactions; a lab run uses a controlled environment. Use field data to identify real experience and lab data to reproduce and debug causes.
Can Lighthouse measure INP?
A no-user synthetic Lighthouse run cannot directly measure INP because INP depends on real interactions. Total Blocking Time can help diagnose main-thread risk in lab testing, but it is not a substitute for INP field measurement.
Should we remove all animation to improve performance?
No. Keep motion that communicates hierarchy, sequence, state, or brand meaning, but implement it efficiently and respect reduced-motion preferences. Remove motion that spends rendering or attention budget without helping the user.
What should be in a performance budget?
Use the constraints that match your architecture: field CWV targets, JavaScript growth, critical media, fonts, third parties, layout stability, and important interactions. Base numeric caps on your real system rather than copying a generic checklist blindly.
Interactive tool: check your performance budget against field thresholds
Use real-user p75 data from CrUX, RUM or Search Console to classify the current LCP, INP and CLS readings. This small tool uses the documented Core Web Vitals bands—not fabricated conversion predictions—and helps identify the first metric worth investigating. A good score alone cannot prove that a feature is accessible, useful or fast on every device.
Official sources
- Web Vitals — web.dev
- Chrome UX Report documentation
- PageSpeed Insights
- Search Console Core Web Vitals report
A maintainable performance budget is not a promise that every page will always be perfect. It is a control system: detect the experience real users are getting, find the responsible component, prevent the same regression from returning, and make every new feature explain how it spends the site's performance budget.
