Slow website: how to diagnose it and prioritise improvements

Late rendering, an unresponsive interaction or content shifting during reading can disrupt a task. The commercial effect depends on the context, audience and journey; a speed test alone cannot calculate lost sales.

Start with priority pages and actions. Record device, connection, server location, cache status and the troublesome step so that the observation can be reproduced.

LCP measures the rendering of the main visible content, INP overall responsiveness to interactions and CLS visual stability. Google’s published ‘good’ thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1.

These thresholds are assessed at the 75th percentile of page loads, separately for mobile and desktop where enough data exist. They describe specific dimensions of experience, not the total value of a page or its business outcome.

Field data come from real users and reflect their devices, networks and journeys. They need enough volume and usually cover a rolling period. PageSpeed Insights can show them when available.

• Lighthouse produces a laboratory diagnosis under simulated conditions.
• It helps reproduce a problem and test a change, but its score can vary.
• Analyse the metrics and recommendations instead of treating the score as a business target.

For LCP, examine the main element, server response, render-blocking resources and when the browser discovers that element. For INP, look for long JavaScript tasks and work performed after an interaction.

For CLS, reserve space for images and injected content, then inspect fonts and late components. Target the observed cause on the affected page template rather than applying a generic checklist everywhere.

Fix issues that block an action or affect many pages first: an oversized primary resource, costly third-party script, unstable layout or inconsistent server response. Verify that the change preserves accessibility and functionality.

Release measurable changes in small groups and compare equivalent conditions. Field data will move only as new observations replace older ones, so an immediate change is not always visible.

The first is image weight. A four-megabyte photo straight from a phone, displayed in a three-hundred-pixel frame, forces every visitor to download a hundred times more than necessary. Resizing, compressing and serving a modern format such as WebP or AVIF divides a page’s weight by five or ten with no visible loss; it is almost always the first fix to make.

The second is the accumulation of third-party scripts: analytics tools, chat widgets, fonts loaded from an external service, share buttons, advertising pixels. Each looks light on its own; together they block rendering and occupy the phone’s processor for seconds. An honest inventory often removes half of them without anyone noticing.

Then come undersized hosting that answers the first request slowly, a theme or page builder that loads all its CSS and JavaScript on every page, and unoptimised web fonts that make text flicker. These five causes explain most of the poor LCP and INP values seen on small-business sites.

Open the report and start with the field-data section, if it exists. It is the only one that describes what your visitors experience. Note which metric fails and on which device type; a poor LCP on mobile but a good one on desktop points immediately to resource weight and the network, not the server.

• Then move to the laboratory diagnostics and find the LCP element the tool identifies.
• If it is an image, the problem is its weight, its format or when the browser discovers it.
• If it is a block of text, look at fonts and render-blocking CSS.
• This targeted reading avoids spending a day optimising something that carries no weight in the measurement.

• Ignore the overall score as a goal.
• Two pages at 70 can have unrelated problems, and going from 70 to 95 in the lab changes nothing if the real LCP stays poor.
• Treat the recommendations as a list of leads ranked by estimated gain, and check the actual gain after each fix.

Step one: images. Resize them to the dimensions actually displayed, convert them to WebP or AVIF, declare their dimensions in the code and prioritise the one that appears at the top of the page while deferring the others. This step alone often resolves LCP and CLS.

• Step two: scripts.
• List every third-party script, ask whom it serves, and remove those without an answer.
• Defer the remaining ones until after the page has rendered.
• An analytics tool can wait a second; a chat widget can load on the first scroll.

• Step three: server and caching.
• Check the response time of the first request; beyond a few hundred milliseconds, a page cache or a content delivery network is called for.
• Step four: fonts and CSS, by limiting the number of font files, hosting them on the site and loading only the styles needed.
• Measure between each step, or you will not know which one worked.

Studies published by the large web companies regularly associate longer load times with lower conversions. Those results come from very high-traffic sites and do not transfer as they are to a neighbourhood business; quoting them as a universal law would be dishonest.

What does hold on any site: a mobile visitor on an average network who waits five seconds in front of a white screen has time to go back to the search results and pick the next competitor. Slowness does not drive everyone away; it drives away part of the least decided people, who are precisely the ones a site needs to convince.

To measure on your own site, compare the share of visitors who leave the landing page without interacting before and after a fix, over a comparable period and traffic source. That is not proof, but it is an indication specific to your site, far more useful than a percentage read elsewhere.

A corrected site degrades from the first heavy image published without compression or the first script added “to test”. Performance is hygiene, not a closed project. Set three simple rules for those who publish: every image goes through automatic resizing, every new script is justified in writing, every new page is checked on mobile before publication.

Automate what can be automated. A content management system or a modern build pipeline can resize and convert images at publication without intervention. A performance budget — maximum weight per page, maximum number of scripts — checked on every production release stops regressions before they reach visitors.

Finally, look at the field data once a month. It evolves with devices, networks and content; a metric drifting slowly toward the wrong side is cheap to correct as long as it is spotted early.

Google recommends good Core Web Vitals for Search and for users. It also stresses that page experience includes more than these metrics and that good scores do not guarantee top rankings.

Improve performance for users and service robustness. Combine it with useful content, understandable architecture, mobile usability, a secure connection and the absence of intrusive interstitials.