A slow website

"The site feels slow" describes an impression, not a fault. Before you change anything, you need to know which part of loading is eating the time - otherwise it is easy to optimise what was already fast and never touch the real brake.

Measure first, do not reach for plugins

Open PageSpeed Insights and enter your address. You get two sets of numbers, and the difference matters:

• Field data - real measurements from Chrome users. This is what counts towards how your page is assessed.
• Lab data - a single Lighthouse run on a simulated connection. Useful for diagnosis, but it can drift away from what people actually experience.

Google assesses three metrics at the 75th percentile of page loads - the threshold has to be met by three quarters of visits, measured separately on mobile and desktop:

• LCP (largest contentful paint) - 2.5 seconds or less.
• INP (interaction to next paint) - 200 milliseconds or less. It replaced the earlier FID metric.
• CLS (cumulative layout shift) - 0.1 or less.

Separate a slow server from a heavy page

This is the most important split in the whole diagnosis. Look at the server response time - the moment the browser receives the first byte of the document. Lighthouse fails that audit above 600 milliseconds; the Core Web Vitals recommendation puts the line at 800 milliseconds.

If the server answers slowly, no amount of image compression will fix it - you are working on the wrong side. The usual causes:

1. No response caching. The page is generated from scratch on every visit, even though the result is identical for most pages.
2. Database queries. One visible delay is often several hundred queries per page - the classic N+1 problem, where related data is fetched inside a loop.
3. No object cache. Redis or Memcached take repeated reads off the database.
4. An overloaded or shared server. Response time swings with the neighbours' load, not with your code.

How to settle this quickly? Check the response time several times, at different hours, for the same page. A steadily high number points at your code or the database. A number that jumps from 200 ms to 2 seconds points at the server.

On the browser side

When the server answers fast and the page still drags, the time goes into what the browser has to download and run:

• Images. The most common single cause. A 4000 px photo shown in an 800 px container wastes bandwidth. Scale to the real display size, set width and height, use WebP or AVIF, and add loading="lazy" below the fold.
• Blocking scripts and stylesheets. Anything in <head> without defer or async holds back the first paint.
• Third-party scripts. Chat widgets, maps, advertising pixels, A/B tests. Each one is a separate connection and code you do not control.
• Fonts. Without font-display: swap the text waits for the typeface to download.

Layout shifts

CLS is a different kind of problem - a page can be fast and still infuriating if the content moves out from under your finger. The culprits repeat: images and iframes without declared dimensions, cookie banners inserted above the content, and fonts that change line height when they swap in. Reserve space for anything that arrives late.

The order that pays off

Measure first and write the number down. Then fix the server response time, because it affects every page at once. Next take the images above the fold, then the third-party scripts, and leave the details for last. Measure again after each change - without that you do not know what helped, and field data updates with a delay, so you will not see the effect immediately.