How to speed up page load time

A slow page load is usually a template or component problem, not a site-wide mystery. Start with one live URL that represents the slow page type, identify whether Largest Contentful Paint (LCP), Interaction to Next Paint (INP), or Cumulative Layout Shift (CLS) is failing, and fix that specific bottleneck before copying the change to every page that uses the same layout.

Use PageSpeed Insights for the page-level diagnosis and Google Search Console for the rollout view. PageSpeed Insights compares field data from the previous 28 days with a fresh Lighthouse run, while Search Console groups similar indexed pages so the same issue can be fixed once at the template level instead of chasing URLs one by one.

Current Core Web Vitals data is a rolling 28-day average, so a clean lab retest does not immediately change the field status. PageSpeed Insights can also show origin-level data when a URL does not have enough samples, and Search Console validation starts a fresh tracking window rather than forcing a recrawl or instant remeasurement.

Related: How to set up Google Search Console for a website
Related: How to perform an SEO audit for your website

Steps to speed up page load time with PageSpeed Insights and Search Console:

  1. Open the slow page in PageSpeed Insights and run the test for Mobile first. 
    https://pagespeed.web.dev/

    Use a live URL that represents the slow template, such as the homepage, article layout, landing page, or product page that real visitors are actually loading.

  2. Check whether the field data is reported for the page itself or only for the origin before blaming that one URL.

    PageSpeed Insights can fall back to origin-level data when the tested page does not have enough CrUX samples. Fixes made for one URL still need to match the wider template or component problem that the field data is describing.

  3. Identify the metric that is still failing at the 75th percentile and ignore unrelated audit noise. 
    LCP  2.5 s or less
INP  200 ms or less
CLS  0.1 or less

    Fix the metric still marked Needs improvement or Poor for the device type being optimized. A page only passes Core Web Vitals when all three metrics are in the good range.

  4. Open the same property in Google Search Console and review the matching Core Web Vitals issue group for the same device type.

    Search Console groups pages with similar user experience, so one example URL often represents a reusable template or component bug across many indexed pages.

  5. Fix LCP when the main content appears late by reducing server response time, removing avoidable redirects, and making the largest above-the-fold image easy for the browser to discover and fetch early. 
    <img src="/images/hero.webp"
width="1200" height="800"
loading="eager"
fetchpriority="high">

    Common LCP wins are serving the hero image at its displayed size, converting oversized images to WebP or AVIF, keeping the LCP image out of loading=“lazy”, and avoiding CSS background images for the main visual when a normal img element would be discovered earlier.

    Related: How to compress a PNG file in Linux
    Related: How to create CloudFront distribution from AWS S3 bucket
    Related: How to host static website on AWS S3

  6. Fix INP when clicks, taps, or key presses feel delayed by removing or deferring non-critical JavaScript and breaking long main-thread work into smaller units.

    Heavy tag managers, chat widgets, consent banners, personalization code, and large client-side rendering bursts are common INP regressions. Use a DevTools Performance trace when the slow interaction is not obvious from PageSpeed Insights alone.

  7. Fix CLS when content jumps during load by reserving space for images, embeds, ads, consent banners, and other injected elements before they render. 
    <img src="/images/card.webp"
width="640" height="360">

    Explicit width and height attributes, an aspect-ratio placeholder, and fixed containers for ad or embed slots are the usual first fixes. Do not remove reserved space just because an ad or widget loads late or returns empty.

  8. Re-run PageSpeed Insights on the same URL and confirm that the blocking metric has improved in the fresh lab result.

    The lab run validates the current build immediately, but the field data remains historical until enough new real-user visits land in the next rolling 28-day window.

  9. Deploy the same fix to every page that uses the affected template or component, then return to the issue details page in Search Console and click Start Tracking after the rollout is complete.

    Start Tracking begins a new validation window for that issue group. It does not force a recrawl, repopulate CrUX data instantly, or rescue a partial rollout.