Why your page is slow, in the order worth checking

Every performance guide is a list of forty optimisations, most of which will save you eleven milliseconds. In practice four things account for nearly every genuinely slow page, and they are worth checking in this order because each one blocks your ability to measure the next.

1. Time to first byte

How long the server takes to start responding. Nothing in the browser can begin until this is over — it is pure dead time, and it sits underneath every other metric.

Under 200 ms is good. Over 600 ms is a problem, and over a second means nothing else on this list is worth optimising yet, because you are polishing the part of the load that happens after the delay.

Usual causes, in rough order of likelihood: database queries (the N+1 problem — a loop that runs one query per row, so a page listing 50 items makes 51 queries), no page caching on a CMS that rebuilds every page from scratch on every request, slow third-party API calls made synchronously during rendering, and shared hosting where you are contending with a hundred other sites.

The reason TTFB comes first is diagnostic as much as practical: a 900 ms TTFB makes every other measurement noisy, and fixing it often makes the page feel fine without touching anything else.

2. Render-blocking resources

The browser has your HTML and starts parsing. It hits a <link rel="stylesheet"> and stops — CSS is render-blocking by design, because rendering without it would flash unstyled content. It hits a <script> without async or defer and stops again, because that script might document.write something.

Five stylesheets and three synchronous scripts in the head is eight sequential round trips before a single pixel is painted. On mobile that is easily a second and a half of blank white screen.

What actually helps:

• defer on every script that is not needed for first paint. This is the highest-value single change on most sites and it is one attribute. defer downloads in parallel and executes in order after parsing; async executes whenever it arrives, which breaks scripts with dependencies.
• Inline the critical CSS — the rules needed for what is visible without scrolling — and load the rest asynchronously.
• Audit third-party scripts ruthlessly. Analytics, tag managers, chat widgets, A/B testing, three ad networks and a cookie banner. Each is a DNS lookup, a connection and an execution, on someone else's server, at their speed. This is very often the largest single cost on a page and the one nobody owns.
• Self-host fonts and use font-display: swap. A web font that blocks rendering means invisible text until it arrives.

3. Images

Images are typically 60–70% of page weight, and they are the easiest thing on this list to fix properly.

The common failures are all the same failure — serving more image than the page needs:

• Wrong dimensions. A 4000-pixel-wide photo displayed in a 400-pixel column. The browser downloads all of it, then throws away 99% of the pixels.
• Wrong format. JPG and PNG where WebP would be 25–35% smaller at the same quality. See the format guide.
• No compression. Straight off the camera or the design tool, with all the metadata still attached.
• Everything loaded at once. loading="lazy" on images below the fold is one attribute and defers most of the page's weight.

Fixing images usually moves Largest Contentful Paint more than anything else, because the LCP element is an image on most pages. Our image compressor and converter handle the format and size work in the browser.

One exception worth naming: do not lazy-load the hero image. Lazy-loading the LCP element delays exactly the thing being measured, which is the opposite of the intent.

4. Layout shift

Not speed, but it is measured alongside it and it is what makes a page feel broken. Cumulative Layout Shift is the metric for content jumping around as it loads — you go to tap a link and an image finishes loading above it and pushes it out from under your finger.

Causes are few and each has a direct fix:

• Images without width and height. The browser cannot reserve space for something whose size it does not know. Setting both attributes lets it hold the space from the start; CSS can still scale it responsively.
• Ads and embeds injected into the flow. Reserve the slot with a fixed-size container.
• Web fonts swapping. A fallback font with different metrics reflows the text when the real font arrives. size-adjust and well-chosen fallbacks reduce it.
• Banners inserted at the top after load. Cookie notices are the usual offender. Overlay them rather than pushing the page down.

What the Core Web Vitals actually are

• LCP — Largest Contentful Paint. When the biggest visible element finishes rendering. Good is under 2.5 s. Driven by TTFB, render-blocking and image weight, in that order.
• INP — Interaction to Next Paint, which replaced First Input Delay in 2024. How quickly the page responds when you interact with it. Good is under 200 ms. Driven almost entirely by long JavaScript tasks blocking the main thread.
• CLS — Cumulative Layout Shift. Good is under 0.1.

They are a ranking signal, and a weak one — a fast page does not outrank a better page. They matter far more for conversion than for position. People leave slow pages, and that has always been true regardless of what Google measures.

Measuring it honestly

The trap is testing on your own machine, on a fast connection, with a warm cache. That page is always fast.

Test throttled to a mid-range phone on 4G, and pay more attention to field data — what real visitors experienced, which is what the Chrome UX Report in Search Console shows — than to lab scores. Lab data tells you what is wrong; field data tells you whether it matters to anyone.

Our website speed checker fetches a URL and reports the response timing, page weight and blocking resources — enough to place a page in one of the four categories above, which is the part that decides what to do next. The minifiers for HTML, CSS and JavaScript handle the easy wins once the structural problems are dealt with.

The order matters

Fix the server first, then what blocks rendering, then the images, then the shifting. Doing it the other way round — minifying CSS on a site with a 1.2-second TTFB — is how people spend a week on performance and change nothing anybody notices.