Why your website feels slow, and what to fix first

Three numbers that decide whether a page is slow

Google's free testing tools grade pages on three measurements, called Core Web Vitals, each describing something a visitor actually feels.

Largest Contentful Paint (LCP) is how long the biggest thing on screen, usually a photo or headline, takes to appear. Good is 2.5 seconds or less; poor is over 4 seconds. In 2025 an image was the largest element on 76% of mobile pages.

Interaction to Next Paint (INP) is how quickly the page reacts when someone taps a button, opens a menu or types. Good is 200 milliseconds or less; poor is over 500. Cumulative Layout Shift (CLS) measures how much the page jumps about while loading, the thing that makes you tap the wrong link. It is a score, not a time: 0.1 or less is good, above 0.25 is poor.

To pass, a page needs each measure in the good range for at least three in four visits. In July 2025, 48% of mobile websites managed it, against 56% on desktop. Google says Core Web Vitals are used by its ranking systems but do not guarantee a top position, and that it still shows the most relevant page when the experience is sub-par. Speed matters mostly for the people who arrive.

The usual first culprit: images far bigger than the screen

In the 2025 Web Almanac, the HTTP Archive's annual report on the state of the web, images made up more bytes than anything else on both mobile and desktop pages. One in ten mobile home pages carried more than 6 MB of images.

The cause is usually innocent. A photo from a phone or stock library is often several thousand pixels wide, then shown a few hundred pixels wide on a phone. The browser downloads every pixel anyway, like posting a wall poster to someone with room for a postcard.

Resize each photo to about twice the width it is displayed at, which keeps it sharp on high-resolution screens, then compress it. Modern formats such as WebP and AVIF usually give smaller files than JPEG at similar quality; check the result by eye.

Two settings matter as much as file size. Lazy loading delays an image until the visitor scrolls near it: sensible further down the page, harmful for the main image, because it holds back what people are waiting to see. About 16% to 17% of pages still lazy-load their LCP image. And give every image a width and height, so the browser can reserve the space rather than shove text down when the file lands. On mobile, 62% of pages miss this for at least one image.

Extras that each cost a little: scripts, plugins and fonts

Every chat bubble, tracking pixel, social feed, review widget, video embed and booking tool is code the visitor's phone must download and run. Each seems small. Together they keep the browser busy, and a busy browser cannot respond to a tap, which is what INP measures.

Phones feel this most. In lab tests for the 2025 Web Almanac, the median mobile page spent a total of 1,916 milliseconds too busy to respond promptly while loading, against 92 milliseconds on desktop. Plugins add to the pile, because a plugin may load its code on every page, including pages where it does nothing.

Fonts were the next-largest contributor to page weight after images and JavaScript. 87% of mobile pages use at least one web font, and each family, weight and italic is usually a separate file. Text often appears first in a stand-in font; when the real one replaces it, the text can change size and push the page around. Use one or two families and only the weights you need.

List every extra and ask what the business would lose without it. Remove anything nobody can defend, and load the rest only where it is needed: a video can show a still image and load the player when someone presses play.

When the server is slow to start: caching and response time

Before a browser can show anything, the server has to send the first byte of the page. That wait is called Time to First Byte (TTFB). PageSpeed Insights treats 0.8 seconds or less as good and over 1.8 seconds as poor, and in 2025 only 44% of mobile websites had a good TTFB.

On systems such as WordPress, the server normally builds each page on request, running code and fetching content from a database. Picture a café baking a fresh loaf for every sandwich. A page cache keeps finished copies on the shelf, so most visitors are served straight away. Pages that differ for each visitor, such as a basket, cannot come off the shelf, so keep them lean.

If response time is poor on a simple page even with caching on, gather evidence before upgrading anything: which pages, what time of day, and figures from several tests. That gives your host something specific to investigate, and stops you paying for more capacity when the cause is a heavy plugin.

Measure with free tools, and know which numbers count

PageSpeed Insights, Google's free test, shows two kinds of result. Field data comes from real Chrome users over the previous 28 days, reported at the 75th percentile so that it reflects the slower end of real visits. Lab data is one simulated visit, run by a tool called Lighthouse on a mid-tier phone over a mobile network. Google notes that the two can differ.

Field data is what counts for Core Web Vitals, but a small site may not have enough visitors to produce it. PageSpeed Insights then falls back to figures for your whole site, or shows none. In that case, use the lab results as a guide and test on your own phone over mobile data rather than office Wi-Fi.

Because field data covers 28 days, a fix can take up to four weeks to show fully. Lab scores vary between runs, so test three times and note the middle result. To find your heaviest files, open Chrome DevTools, choose the Network panel, reload the page and sort by size.

Your fix list, from quickest to biggest

Change one thing at a time and retest the same page in the same way. After each change, check that menus, forms and checkout still work: a faster page with a broken enquiry form is not an improvement.