Why your website loads slowly and how to check it yourself

Most slow websites are slow for the same few reasons: images far bigger than they need to be, too much JavaScript, other companies' scripts on every page, or a slow server. You can find out which one it is in a few minutes with a free tool from Google, without touching any code.

Does a second really matter?

In 2020 Deloitte Digital, working with Google, followed the mobile sites of 37 retail, travel, luxury and lead generation brands in Europe and the US for four weeks. When a site got 0.1 seconds faster, retail conversions went up by 8.4% and the average order by 9.2%. Those were big brands with a lot of traffic, so a small site won't see the same numbers. It does show that a tenth of a second changed what people did.

Google looks at speed too, as part of what it calls page experience. It counts for less than many people think. Google's own documentation says Search "always seeks to show the most relevant content, even if the page experience is sub-par". Speed helps most when your page competes with others that are just as useful.

How to check your site

Open PageSpeed Insights at pagespeed.web.dev, paste your address and press Analyze. The report has two parts, and they answer different questions.

The first part shows how fast your site was for real people using Chrome over the last 28 days. This is the one to trust, because it comes from real phones on real connections. A new or small site often doesn't have enough visitors for it. Then the section shows data for the whole site, or stays empty.

The second part is the score from 0 to 100, with a list of suggestions underneath. It comes from one simulated visit on a mid-range phone with a slow 4G connection, run from Google's servers. It's useful for finding causes, but it changes a little every time you run it, so don't chase single points.

Start with the Mobile tab. Phones have slower processors and often slower connections than laptops, so that's where problems show first.

The three numbers that matter

Google calls them Core Web Vitals. Each one has a clear limit, and a page passes when at least 75% of visits stay within it.

Largest Contentful Paint (LCP) is how long it takes for the main content to appear, usually the large image or the headline at the top. Good is 2.5 seconds or less.

Interaction to Next Paint (INP) is how quickly the page reacts when you tap or click something. Good is 200 milliseconds or less. It replaced an older measure, First Input Delay, in 2024.

Cumulative Layout Shift (CLS) measures how much things jump around while the page loads. It's the button that moves just as you go to tap it. Good is 0.1 or less.

If one of the three is red, start there. The suggestions under the score usually point to the cause.

What turns each number red

Google splits LCP into four parts: waiting for the server to answer, waiting before the main image starts downloading, downloading it, and drawing it on screen. The two you can usually do something about are the server and the weight of that image. One common mistake makes it worse: lazy loading the image at the top. Lazy loading tells the browser to wait before fetching an image, which helps for images further down the page. For the top one, Google's guide is blunt: never lazy-load it.

INP goes red when the phone is busy running JavaScript at the moment someone taps. The tap waits until the current work is done. The fix is less script and less work done in one go, which is mostly a job for whoever built the site.

CLS has four usual causes, according to Google: images without set dimensions, so the page doesn't know how much room to leave for them; ads, embeds and iframes with no space reserved; content added after the page has loaded, like a bar pushed in at the top; and web fonts that change the size of the text when they arrive.

The usual causes

Images come first. The HTTP Archive measures more than 15 million mobile websites every year, and in its 2025 report the median mobile page weighed about 2.2 MB, of which 911 KB were images, more than any other type of file. A single photo straight from a phone can weigh several megabytes. Resizing images to the size they're actually shown at, and saving them as WebP or AVIF, often cuts them to a fraction of the size.

JavaScript comes second, at 632 KB on the median mobile page. Its size is only part of the cost. The phone also has to run the code, and while it does, taps and scrolls wait, which is exactly what INP measures. Sliders, animations, chat widgets and heavy page builders all add to it.

Then there are other companies' scripts: analytics, ads, embedded videos, chat boxes, social media feeds, tracking pixels. Each loads from someone else's server and each may be quick on its own, but they add up. If PageSpeed names them among the things slowing the page, ask whether you still need every one.

The server can slow everything down before any of this starts. Until the first byte of the page arrives, nothing else can load. Google suggests keeping this time to first byte under 0.8 seconds. Cheap shared hosting, a site that rebuilds every page from a database on every visit, or a server on another continent from your visitors can push it higher. Caching, a content delivery network (CDN) or better hosting usually fix it.

Fonts are smaller, 122 KB on the median page, but if the text waits for them, the page stays blank for longer. One or two font families, and text that shows in a standard font until yours has loaded, usually solve it.

What you can do without a developer

Resize and compress images before you upload them. Free tools like Squoosh do it in the browser, and some site builders have an option for it. Remove plugins, widgets and scripts you no longer use. If you embed YouTube videos, look for an option that shows only a preview image and loads the player when someone clicks. Run PageSpeed again after each change, so you know what helped.

Now and then, open your site on your own phone, on mobile data rather than Wi-Fi. It isn't a measurement, but you'll feel what your visitors feel.

If the real-visitor numbers are still red after that, the problem is usually in the code or the server. That's the moment to bring in a developer, and the PageSpeed report is a good place to start, because it already shows them where to look.