Slow website: the causes in load order

A website is slow when one step of loading makes visitors wait: the server response, the files that block display, the weight of images and scripts, the third-party services the page calls, then running the code. Checking in that order keeps you from compressing images when the server is what holds everything up.

The most telling figure is how long the main content takes to appear: Google rates it good up to 2.5 seconds and poor beyond 4. It is one of the Core Web Vitals, which the website speed audit measures.

What "slow" means to Google

Google sums up perceived speed in three measurements, the Core Web Vitals: how long the largest visible element takes to appear (LCP, good up to 2.5 seconds), how fast the page reacts to a click or a key press (INP, good up to 200 milliseconds), and how stable the layout stays while loading (CLS, good up to 0.1).

These thresholds apply to three out of four visits, on phones and on desktops. A page that feels fast on your office computer can still be slow for a good share of your visitors.

For search, Google says that these measurements, along with other page experience aspects, align with what its core ranking systems seek to reward. Speed is one of its signals, and it does not decide rankings on its own.

The causes, in the order a page meets them

A page loads in steps, and each step partly waits on the one before. A cause that sits early delays everything after it.

The server responds. Before anything shows, the browser follows redirects, looks up the server's address, sets up the secure connection, then waits for the server to build the page. web.dev recommends keeping this first stretch under 0.8 seconds. An overloaded host, or a page rebuilt from scratch on every visit, pushes it past that.
The browser fetches what blocks display: stylesheets, scripts loaded at the top of the page, fonts. Until they arrive, the screen stays blank or the text stays invisible.
Images and scripts download. A photo uploaded straight from a camera often weighs far more than what the screen shows, and a file that is neither compressed nor cached is downloaded again on every visit.
Third-party services load: analytics, chat, video, maps, ads, bot protection. Each one opens a connection to another server, and its code adds to yours without you controlling its weight.
The code runs. While the browser is running JavaScript, the page ignores clicks, even if it looks fully loaded.

No image optimization wins back the time lost before the server answers. That is why the order matters more than the list.

What we find on the sites we audit

35%take more than 4 seconds to show their main content, the threshold Google rates as poor

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

This figure uses real-visit data when Google publishes it for the site, and our own measurement under mobile conditions otherwise.

What the audit measures, and why

Each page in scope is loaded in a browser throttled to match a typical phone on an ordinary network, then on desktop. The report gives both, because a site can be fast on one and slow on the other.

How long the main content takes to appear, which tells you when visitors finally see what they came for.
Server response time, which delays every step after it.
The weight actually downloaded and the number of requests, split between images, scripts, fonts and styles. That weight belongs to the site: it stays the same whatever the visitor's connection.
What blocks display, what is neither compressed nor cached, and images served larger than the screen that shows them.
The share of that weight and waiting that comes from third-party services rather than your own site.
How fast the page reacts to clicks, which can only be measured on real visits. When Google publishes no such data for a site, the report says so and draws no conclusion.

The guide to Largest Contentful Paint breaks down the four steps before the main content appears, and where the time usually goes.

Quick fixes, and fixes that take a project

Part of the slowness can be fixed without touching the structure of the site: images resized and compressed to the size they are shown at, compression and caching turned on at the server, a third-party service nobody uses removed from the page.

Removing a third-party service lightens the page and also cuts what it sends to other companies. The guide on what your website sends outside the EU explains what those services receive.

Other causes take a project: an undersized hosting plan, a theme or page builder that loads a lot of code on every page, a site whose content only appears once JavaScript has run, and can stay blank when that code hits a JavaScript error. If the server is the problem and you change hosts, the guide on choosing EU web hosting lists the questions to ask a provider.

What this check doesn't tell you

We measure the site from the outside, like a visitor. We see how long the server takes to respond, not what keeps it busy: a slow database, a heavy plugin, a server shared with other sites. That diagnosis needs access to the server.

Our measurements are taken under fixed conditions, on the pages in scope. They do not describe each visitor's device or network; they describe what the site asks of every one of them.

By Quentin Mathis, Z29K · updated September 28, 2026