# How to improve website performance: measure, then fix one thing

> By Lawrence Dauchy, Founder, DFYe. Published 2026-08-13. 10 min read. Guides.
> Source: https://dfye.com/blog/how-to-improve-website-performance/
> Language: en

Three numbers tell you whether your site is slow and where. Everything after that is finding the single largest cost and removing it.

**TL;DR.** To improve website performance, measure before changing anything. Three metrics cover it: largest contentful paint under 2.5 seconds, interaction to next paint under 200 milliseconds, and cumulative layout shift under 0.1. Open the network waterfall, find the request or the query that actually costs the time, and fix that one thing. Caching hides a slow page rather than making one fast, and knowing the difference is most of the work.

To improve website performance you measure first and then change one thing. Three
published thresholds tell you whether you have a problem and where:
[largest contentful paint](https://web.dev/articles/lcp) under **2.5 seconds**,
[interaction to next paint](https://web.dev/articles/inp) under **200 milliseconds**,
and [cumulative layout shift](https://web.dev/articles/cls) under **0.1**. Most sites
that feel slow have one dominant cost rather than twelve small ones, and the twelve
point checklists exist because writing one is easier than opening a waterfall.

Find the single largest cost, remove it, measure again. That loop is the whole method.

## What should you measure first?

Three numbers, and each one describes a different complaint a visitor would make. The
composite score a tool shows you is a weighted summary of these, so look underneath it.

| Metric | What a visitor would say | Good |
|---|---|---|
| Largest contentful paint | It took ages to show me anything | Under 2.5 seconds |
| Interaction to next paint | I tapped and nothing happened | Under 200 milliseconds |
| Cumulative layout shift | It moved and I tapped the wrong thing | Under 0.1 |

Chasing the headline score rather than these three leads people to fix whatever the
tool weighted heavily this year. The three underneath are stable, they map onto
sentences a real person would say, and two of them are about interaction rather than
loading, which is where most modern slowness actually lives.

Measure on a phone, on mobile data, on the page people actually land on. A homepage
tested over office wifi on a laptop is a measurement of your office.

## How do you find what is actually costing you?

By opening the network waterfall and reading it, which takes about five minutes and is
skipped almost universally in favour of installing something.

Sort by size and look at the top three. Then sort by duration and look at the top
three. They are usually different requests, and the distinction matters: a huge image
is a bandwidth problem you fix by compressing it, while a small request that takes two
seconds is a server or third-party problem that compression will not touch.

Then find the first thing that blocks rendering. Anything in the head that is not
marked async or deferred stops the page being drawn until it arrives, and a single
render-blocking script from a third party can cost more than every image on the page.
[The guide to optimising LCP](https://web.dev/articles/optimize-lcp) is the reference
for what to do once you have found it, and
[Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) will point at the
same things in a more readable order if a waterfall is unfamiliar.

Write down the number before you change anything. Without a before, you are going to
be arguing from memory in an hour.

## What are the usual culprits?

A short list covers most sites, and matching the symptom to the cause saves you
changing four things at once.

| Symptom | Usual cause | Where to look |
|---|---|---|
| Nothing appears for seconds | Render-blocking CSS or JavaScript in the head | Waterfall, first blocking request |
| Slow admin, fast front end | A plugin working on every request | Deactivate one at a time on a staging copy |
| Huge page weight | Original-resolution images | Network tab, sorted by size |
| Content jumps while loading | Images or embeds with no reserved space | Lighthouse, the layout shift section |
| Slow only since last month | A plugin or theme update | Compare against the update log |

Row three is the most common and the easiest. A photograph straight from a camera is
several megabytes and is being displayed at 800 pixels wide. Resizing and compressing
it is not an optimisation project, it is a Tuesday, and
[lazy loading](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading)
anything below the fold is close to free.

Row four is the one people tolerate for years. Reserving space for an image by setting
its width and height stops the page dancing while it loads, costs nothing, and fixes a
metric you are measured on.

## What about plugins and third-party scripts?

The count is not the problem. Twenty small plugins can cost less than one that runs a
database query on every page load, and the advice to simply use fewer plugins is how
people end up removing something useful while keeping the expensive one.

What to check for each is narrow. Does it load its stylesheet and script on every page
or only where its feature appears. Does it do work on the front end at all, or only in
the admin. Does it call somebody else's server while the page is rendering, because
that turns their bad day into yours.

Third-party scripts deserve separate attention because they are the ones nobody owns.
Analytics, chat widgets, review embeds, advertising tags: each was added by somebody
solving one problem, and none of them appears in a plugin list. Add them up honestly.
We measured our own widget on the way to
[dropping a 31kB animation library](/blog/we-dropped-gsap/) for thirty lines of code,
and the habit is the same at any scale: open the build output, find what the thing
costs, and decide whether the job it does is worth that. What a chat widget in
particular should cost your page is in
[making a widget that fits your site](/blog/ai-widget-website/), and our own figure of
7.1kB loading after paint is on [the features page](/features/), enforced by a budget
on every build rather than claimed.

## What about web fonts?

They are the cost most often forgotten, because a font is not thought of as a
download. On a lot of sites the fonts are the largest render-blocking thing on the
page, and they cause both of the metrics people find hardest to move.

Four things are worth checking, in this order.

**How many weights are you loading.** Two families at four weights each is eight files
before you have shown a word. Most designs use three of those eight. Dropping the
unused ones is the largest win available and takes ten minutes.

**Whether the text waits.** By default a browser may hide text until its font arrives,
which is a blank page holding a perfectly good paragraph. Setting the font to swap
shows the fallback immediately and replaces it when the real font lands; setting it to
optional accepts the fallback on a slow connection and never swaps at all. Swap is the
usual right answer, and it converts a blank screen into a visible one.

**Whether the swap moves anything.** If your fallback is metrically far from your web
font, the text reflows when the real one arrives and your layout shift number takes
the hit. Choosing a fallback with similar metrics, or tuning the size adjustment,
removes the jump without removing the swap.

**Where they come from.** A font requested from another origin adds a DNS lookup, a
connection and a handshake before the first byte, all of it on the critical path.
Self-hosting the two or three files you actually use removes that entirely, and lets
you preload the one used above the fold.

None of this is a project. It is an afternoon, it is measurable in the same waterfall
you already opened, and on a text-heavy site it frequently beats every image change
combined.

## How much does caching really help?

A great deal, and less than people think, because it does two different jobs and only
one of them is making your site fast.

Caching stores the finished page so the server does not rebuild it for the next
visitor. That genuinely removes server time, and on a site whose slowness is server
time it changes everything you can measure. What it does not do is make the page itself lighter. The
same images, the same scripts, the same render-blocking third party: all still there,
now delivered promptly.

It also has holes exactly where your money is. A logged-in visitor, a cart page, a
checkout: none of those can usually be served from a cache, so your most valuable
pages meet the original slowness. A shop that tested its homepage, saw a good number
and stopped has measured the one page that was never the problem.

Use caching. Also fix what made the page slow, because one day you will look at a page
the cache cannot serve. How we keep our own cost down rather than hiding it is on
[how it works](/how-it-works/).

## When is more speed not worth it?

Once the three numbers are inside their thresholds on a real phone, which is a finish
line most guides never mention.

Past that point the returns fall away sharply. Going from 2.4 seconds to 2.1 is not
something a visitor notices, and the effort is usually better spent on the thing they
do notice, which is whether the page answers their question. A fast page that does not
say when the item will arrive loses to a slower one that does.

Two specific cases are worth naming. If your slowness is a single slow database query
on an admin screen your customers never see, it is a comfort problem rather than a
business one, and it can wait. And if the only remaining win is a rewrite, price the
rewrite honestly against what the current site costs you in lost visitors; frequently
it does not clear.

The failure mode at the other end is worse and more common: optimising something that
was never the bottleneck, seeing no change, and concluding the site cannot be made
fast. That is not a performance problem. It is a measurement problem, and the fix is
to go back to the waterfall before touching anything else.

## Quick answers

### How do I improve my website's performance?

Measure first, then change one thing. Open the network waterfall on a real page and
find the largest request and the longest one, because they are usually not the same.
Most sites have a single dominant cost, an uncompressed hero image, a render-blocking
script, one plugin doing work on every request, and fixing that beats a checklist of
twelve small improvements you cannot attribute afterwards.

### What is a good page speed score?

A score is a summary of three things worth checking directly: largest contentful paint
under 2.5 seconds, interaction to next paint under 200 milliseconds, and cumulative
layout shift under 0.1. Chasing the composite number encourages fixing whatever the
tool weighted heavily rather than what your visitors feel. Look at the three underneath
it and ignore the headline figure.

### Why is my website slow even after optimization?

Usually because the optimisation addressed something that was not the bottleneck.
Compressing images on a site whose problem is a slow database query changes nothing
measurable, and the effort convinces you the problem is unsolvable. Go back to the
waterfall and find where the time actually goes before changing anything else. The
second most common answer is a caching plugin that is not caching the page you tested.

### Does caching make my site faster?

It makes a slow page arrive faster, which is not the same thing and matters when it
stops working. Caching hides the cost of generating a page; it does not reduce it, so a
cache miss, a logged-in visitor or a cart page all meet the original slowness. Use it,
and separately fix whatever made the page slow, because one day you will look at a page
the cache cannot serve.

### How much do plugins slow down WordPress?

The count does not matter and the behaviour does. Twenty small plugins can cost less
than one that runs a database query on every page load or loads its stylesheet
everywhere for a feature used on one page. Find the expensive ones rather than the many
ones, and check what each adds to a page that does not use it.

### Do I need a faster host?

Sometimes, and it is the most expensive answer so it is worth being last. Server time
shows as a slow first byte with nothing else pending; if your first byte is quick and
the page is still slow, moving host changes nothing. Rule out the front end first,
because most sites that feel slow are slow after the server has already done its job.

## Sources

- [web.dev: largest contentful paint](https://web.dev/articles/lcp)
- [web.dev: interaction to next paint](https://web.dev/articles/inp)
- [web.dev: cumulative layout shift](https://web.dev/articles/cls)
- [web.dev: optimize largest contentful paint](https://web.dev/articles/optimize-lcp)
- [Chrome: Lighthouse overview](https://developer.chrome.com/docs/lighthouse/overview)
- [MDN: lazy loading](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*