Which website speed problems to fix first

The rule behind the order

Every speed fix has a size and a cost. The size is how much it moves the number that fails. The cost is the time, risk and money it takes. The right order is the largest gain for the smallest cost, and always aimed at the number that decides the result: whether real visitors pass the Core Web Vitals.

A report with forty items does not mean forty jobs. Usually two or three of them cause most of the delay, and the rest are small. The skill is in finding those two or three.

Step 1: pick the pages

You cannot fix a whole site in one go, and you do not need to. Rank your pages by what they are worth to you:

1. The pages that bring most of your visitors, usually the home page and a few popular ones.
2. The pages where visitors become customers: the contact page, the booking page, the product and checkout pages.
3. Everything else.

Start with the first two groups, and with the mobile result for them. If a template is shared, such as all product pages, a fix to the template fixes all of them at once.

Step 2: pick the one metric that fails

Look at the real-visitor result for each page. Three numbers can fail: loading (LCP), responsiveness (INP) and stability (CLS). Choose the one that is furthest into the red, or that fails on most of your important pages. Work on one at a time, because fixes for different metrics rarely help each other, and it is easier to see what worked.

Step 3: use the order that fits the metric

If loading (LCP) fails

1. The server response. If the first wait is long, nothing else helps much. A page cache, a CDN and better hosting are the first fixes. See time to first byte.
2. The main image. Is it lazy-loaded, set as a CSS background or added by a script? Is it far bigger than the space it fills? This is the most common cause on the web, and it is usually a small change. See how to fix a slow LCP.
3. Blocking files. Scripts without defer, and large stylesheets in the head, hold the page back. See render-blocking resources.
4. Web fonts and heavy sliders at the top of the page.

If responsiveness (INP) fails

1. Scripts nobody needs. Remove unused plugins, tags and widgets first. This is the cheapest and largest gain.
2. Third-party code. Chat, ads, tag managers and tracking are the most common source. See third-party scripts.
3. The slow interaction itself. Find it by testing the things visitors do most, and fix the longest of its three parts. See how to fix a slow INP.

If stability (CLS) fails

1. Images, videos and embeds without a set size. The easiest fix and the most common cause.
2. Banners, bars and pop-ups that push the page down after it has drawn.
3. Fonts that change size when they load.
4. Late-loading blocks, such as reviews and recommendations, without a placeholder. See how to fix layout shift.

The quick wins

These are the changes that are cheap, safe and often large. Check each one before you reach for anything more complicated.

• Turn on a page cache, or the one your host provides.
• Make sure the main image is a normal image tag, is not lazy-loaded, and is the right size.
• Set width and height on every image.
• Remove plugins, scripts and tags that are not used.
• Convert large JPEG and PNG photos to WebP or AVIF.
• Add defer to scripts that do not need to run first.
• Limit the number of web fonts and weights.
• Lazy-load images and embeds below the first screen.

What can wait

Some work has a real but small effect. Do it after the above, or when you have time:

• Minifying CSS and JavaScript. It trims the bytes but rarely changes the result by much.
• Combining files, if the site is on HTTP/2 or HTTP/3: there, many small files cost little. On HTTP/1.1 they cost more, so check the protocol first. See the Speed Lab test.
• Cleaning the database. It helps the server, but only on sites with a large, neglected one.
• Shaving the last few points off the lab score.
• Optimizing pages nobody visits.

A worked example

Here is an imaginary small business site, with the numbers made up to show the method. On mobile, the real-visitor LCP is 3.9 seconds and fails. INP and CLS pass. The report points at six things:

The order is clear. First the server cache and the main image, because they are large gains for little effort. Then the stylesheet, which is a medium gain with some risk. The fonts next. The chat widget is worth fixing for INP, though not for the failing number. The minifying goes last. Two small changes in the first hour would be expected to move LCP the most.

Who can do which fix

Many of the quick wins need no code. Knowing who is able to do what saves a week of waiting:

• You can remove plugins and tags nobody uses, resize and convert images before you upload them, switch on the cache your host provides, and check the settings of your page builder for the top image.
• Your developer or agency can change the theme and plugins, set up critical CSS, defer scripts, and change the way the server is configured.
• Your host can change the PHP version, add a cache or a CDN, and turn on newer protocols.
• The vendors of third-party tools can tell you whether a lighter version of the widget exists, or a way to load it later.

Bring in help when a change could break something that earns money, such as the checkout or a contact form, or when the real-visitor numbers are still poor after the quick wins. At that point the cause is probably deeper, and a measured diagnosis is cheaper than trying things.

What good looks like after each step

1. Test again with the same settings, three times.
2. Check that nothing broke. Click through the main pages and forms on a phone.
3. Write down the numbers next to the earlier ones.
4. Wait four weeks for the real-visitor data, then see whether the page passes.

If a fix did not move the number it should have, that is information: the cause was somewhere else, and the next item on the list is next.

Check your own page

Run the free audit and apply the three steps to the result. Pick the page, pick the failing number, and find its biggest cause. Write that one item down, and fix only that before you read the rest of the report.

Sources

• Optimize Largest Contentful Paint on web.dev: the order in which to fix the parts of LCP.
• Optimize Interaction to Next Paint on web.dev: the parts of an interaction.
• Optimize Cumulative Layout Shift on web.dev: the common causes.