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 under 2.5 seconds, interaction to next paint under 200 milliseconds, and cumulative layout shift 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 is the reference for what to do once you have found it, and Lighthouse 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 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 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, and our own figure of 7.1kB loading after paint is on the features page, 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.
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.
Questions we get on this
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.
