Website speed is the experience of waiting, tapping, and watching the page move. A site can finish downloading quickly and still feel slow because the main content appears late, a button does not respond, or a banner shifts the form just as someone tries to use it.

Optimize the real customer journey, not only a score. Start with the pages and devices that matter to the business, use field data where available, and make one traceable improvement at a time.

Understand the three Core Web Vitals

Google’s current Core Web Vitals measure:

  • Largest Contentful Paint (LCP): loading performance. A “good” LCP is 2.5 seconds or less.
  • Interaction to Next Paint (INP): responsiveness throughout a visit. A “good” INP is 200 milliseconds or less.
  • Cumulative Layout Shift (CLS): visual stability. A “good” CLS is 0.1 or less.

The assessment uses the 75th percentile of page loads, segmented by mobile and desktop. See the official Web Vitals guidance for the metric definitions and thresholds.

These are not the only performance signals. Time to First Byte, First Contentful Paint, total JavaScript work, memory, and network requests can help diagnose why the experience is poor.

Use field and lab data together

Field data

Field data comes from real visits across different devices, networks, locations, and user behaviour. It tells you whether actual users meet the thresholds, but it may be unavailable for low-traffic pages and can take time to reflect a release.

Lab data

Lab tests run in controlled conditions. They help reproduce a problem, inspect a network waterfall, identify long tasks, and compare a change before deployment. They do not represent every real visitor.

Google’s PageSpeed Insights documentation explains how the tool combines field and lab information. Test more than the homepage: include the primary landing page, pricing, contact, signup handoff, and a content-heavy article.

Fix LCP: show the main content sooner

The LCP element is often a hero image, large heading block, or banner.

Check the full chain:

  1. How quickly does the server begin returning HTML?
  2. Can the browser discover the LCP resource in the initial markup?
  3. Is it delayed by CSS, JavaScript, or client-only rendering?
  4. Is the resource correctly sized and compressed?
  5. Is the element competing with fonts or other high-priority requests?

Practical fixes include:

  • pre-rendering or server-rendering important content;
  • reducing redirects before the page;
  • caching static HTML and assets appropriately;
  • putting the hero image in the HTML rather than injecting it late;
  • avoiding lazy loading for the LCP image;
  • using responsive srcset and sizes values;
  • serving AVIF or WebP when they reduce bytes without harming quality;
  • preloading only the truly critical resource; and
  • limiting blocking font and stylesheet work.

The official LCP optimization guide recommends breaking LCP into subparts so you fix the actual delay rather than applying random optimizations.

Fix INP: keep interactions responsive

Poor INP often comes from JavaScript occupying the main thread when the customer taps, clicks, or types.

Look for:

  • large client bundles parsed on every page;
  • long event handlers;
  • expensive component hydration;
  • third-party scripts;
  • synchronous storage or layout work;
  • large DOM updates; and
  • repeated work on each keystroke or scroll event.

Improve responsiveness by:

  • shipping less JavaScript;
  • loading page-specific code only where needed;
  • breaking long tasks so the browser can respond;
  • avoiding unnecessary hydration for static content;
  • debouncing non-critical input work;
  • simplifying expensive DOM updates;
  • moving suitable computation off the main thread; and
  • delaying optional third parties until after consent and need.

Use the browser performance panel to inspect the interaction, not merely the initial load. The INP optimization guide covers input delay, processing duration, and presentation delay.

Fix CLS: reserve space before content arrives

Common causes include:

  • images or videos without dimensions;
  • cookie banners or alerts inserted above content;
  • ads and embeds without reserved containers;
  • web fonts that change text metrics dramatically;
  • animation that changes layout properties; and
  • async content injected into an existing flow.

Set intrinsic image dimensions or an aspect ratio, reserve space for embeds, and use overlays or preallocated regions for banners. Prefer transform and opacity for visual motion. Test the page through consent banners, form errors, accordions, font loading, and dynamic content—not only a clean reload.

Reduce image cost

For every image:

  • choose the dimensions needed at each breakpoint;
  • avoid sending a desktop image to a narrow phone;
  • select a modern format based on actual file-size and quality comparisons;
  • compress to the lowest acceptable visual cost;
  • lazy-load below-the-fold images;
  • include width and height; and
  • use a content delivery layer that can generate responsive variants.

Do not replace a simple CSS or SVG shape with a large raster image. Conversely, do not create an enormous, complex SVG that costs more to parse and paint than a well-compressed image.

Control fonts and third parties

Each font family, weight, and script adds transfer and rendering work. Use a small type system, subset files where appropriate, self-host when it improves control, and choose fallback metrics that reduce reflow.

Audit every third-party script:

  • Who owns it?
  • What decision does its data support?
  • Does it load before consent?
  • What performance and privacy cost does it add?
  • Can it load only on the pages that need it?
  • What breaks if it is unavailable?

Remove tools no one actively uses. The fastest request is the one the browser never makes.

Improve caching and delivery

Static, versioned assets can usually use long-lived browser caching. HTML and data need policies that reflect how quickly they change. Use content hashes so a new release receives a new asset URL instead of forcing every asset to revalidate.

Compress text assets with Brotli or gzip where supported. Serve content through a CDN, but remember that a CDN cannot repair slow origin computation, oversized client code, or a blocked main thread.

Set a performance budget

Create release thresholds for key templates:

  • JavaScript transferred and executed;
  • CSS and font bytes;
  • total image weight above the fold;
  • number and cost of third-party requests;
  • LCP, INP, and CLS in lab testing; and
  • field performance targets when sufficient data exists.

Run the checks in continuous integration and investigate meaningful regressions. A budget is more useful when it names the owner and exception process rather than failing without context.

Verify every change

  1. Capture a baseline with the same URL, device, and network conditions.
  2. Identify the metric and root cause.
  3. Make one focused change.
  4. Compare the trace, bytes, and visual result.
  5. Check accessibility and functional behaviour.
  6. Deploy to a preview and retest the full journey.
  7. Monitor field data and business outcomes after release.

Performance is a product quality, not a cleanup sprint. Make image sizing, bundle review, third-party approval, and regression testing part of normal publishing so the site stays fast after the redesign is complete.