Your site speed is costing you sales: a practical fix guide

web.dev defines three core metrics: Largest Contentful Paint for how quickly the largest content appears, Interaction to Next Paint for how the page responds to interactions, and Cumulative Layout Shift for visual stability. The good thresholds are LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under. Success is assessed at the 75th percentile, meaning most visits must meet the threshold on both mobile and desktop.

• LCP ≤ 2.5 seconds: the main content appears quickly.
• INP ≤ 200ms: good response to clicks, typing, and interaction.
• CLS ≤ 0.1: limited, unsurprising visual movement.
• Use the 75th percentile and review mobile and desktop separately.

PageSpeed Insights shows field data from the Chrome User Experience Report where there is enough volume, and then a Lighthouse lab result from a simulated environment. The field answers the question: what happened to real users over a period? The lab helps you reproduce a problem and diagnose the files and elements. Do not compare two numbers from two sources as though they were one test. Use the field to set priority, and the lab and DevTools to understand the cause and verify quickly.

Data may be unavailable for a new or low-traffic page, so you see origin-level data or nothing at all. In that case collect Web Vitals in your own analytics or use real-user monitoring, respecting privacy, then test on devices and networks that represent your audience. Separate the templates: a product page may be slower than an article because of images, reviews, and tracking, and the homepage does not represent the whole store.

Use DevTools or the Lighthouse report to identify the LCP element. If it is a hero or product image, reduce the file dimensions, use WebP or AVIF where suitable, provide a srcset of sizes, and do not lazy-load it, because it needs priority. preload or fetchpriority can be used carefully where the resource is known in the HTML. If the LCP is text, review the font, the server time, and any CSS that blocks rendering.

Break the LCP time into server response, resource discovery delay, load time, and render delay. Compressing an image will not fix a server that waits three seconds on the database, and a CDN will not fix JavaScript that blocks rendering after the resource has arrived. Pick the largest part of the chain. Reduce redirects, use appropriate caching, optimise the queries, send the HTML early, and make the main resource discoverable in the source rather than after a long script has run.

INP is affected by long tasks on the main thread, the event processing time, and the delay before the next paint. Watch the Performance panel during a slow interaction, split large work into smaller tasks, defer whatever the first response does not need, reduce third-party JavaScript, and avoid re-rendering large components on a simple click. In stores, chat, personalisation, recommendations, and tracking combined are often heavier than the theme's own code.

Do not delete important functionality just to improve the number. Load the feature on demand, use a Web Worker for suitable computation, reduce the DOM size, and beware of global listeners doing work on every scroll or keystroke. Test on mid-range devices, not the developer's fast machine. And give an immediate, safe response — a loading state, or disabling the pay button after a tap — while the system finishes the work in the background.

Set width and height or aspect-ratio on images and video, reserve room for ads and embeds, and do not inject a bar above the content after reading has begun. Use transform for movement rather than properties that change layout where that suits, and load fonts in a way that limits size differences. Shifts caused by direct user interaction are treated differently, but the visual rule is simple: never let the button move out from under the customer's finger.

Serve an image at roughly the size it is displayed at; do not send a 4000-pixel-wide file into a 400-pixel card. Choose a quality that preserves the details that matter, use responsive images, and enable lazy loading below the fold with the LCP image excepted. Put a CDN or an image transformation service in front of a large catalogue, but test the caching, the signatures, and the fallbacks. Do not convert everything indiscriminately; logos and flat graphics are often better as SVG or PNG.

1. 1Pull the largest transferred images out of the Network panel.
2. 2Compare the original dimensions with the displayed dimensions.
3. 3Convert the format and tune the quality.
4. 4Add srcset and sizes for responsive sizes.
5. 5Exclude the LCP image from lazy loading.
6. 6Re-measure on a representative network and device.

Use a limited set of weights or a suitable variable font, subset the characters where you have a correct pipeline, and set font-display to match the brand experience. Load critical fonts from a trusted origin with caching, and reduce chained @import. Extract critical CSS carefully, and remove unused styles only after checking the dynamic states. A small CSS file loaded at the end of a chain of requests can delay rendering more than a larger file discovered early.

Build a list of every external script, its owner, its purpose, and when it was last used. Remove old experiment tools and duplicate pixels, load chat, maps, or video on interaction where possible, and use defer or async according to the dependencies. Keep an eye on Tag Manager; the ease of adding tags can hide an accumulation the development team never sees in the repository. Set a performance budget that stops the problem returning after every campaign.

Measure Time to First Byte and separate DNS, connection, and server time. Review the hosting, the region, the CDN, modern HTTP, and compression, then inspect the application: N+1 queries, external APIs called inside the request, uncached templates, and heavy sessions or plugins. Use a page cache for suitable pages and an object cache for repeated data, with clear invalidation rules so you never show a stale price or stock level.

Set limits for JavaScript size, images, request count, and Lighthouse as a lab signal, and run a check on the important templates whenever they change. Watch the field weekly or monthly depending on traffic, and tie the alert to a release or a campaign. Do not make the score the only gate; check function, accessibility, and tracking too. Speed work is continuous, because marketing and content tools add weight over time.

1. 1Identify the affected template from field data.
2. 2Pick the worst metric and the element or interaction responsible.
3. 3Inspect Network, Performance, and the server path.
4. 4Fix the single largest cause and keep a before-and-after snapshot.
5. 5Verify function, tracking, and accessibility.
6. 6Ship and watch the field over the following period.
7. 7Add a rule that stops the cause returning in future releases.