Introduction
A slow website loses visitors before they read a word. People leave, search engines notice, and every fix you make blindly — a new caching plugin, a different host, a smaller image — is a guess until you know what is actually slow. The fastest way to improve loading speed is not to apply every optimization tip you have ever read. It is to measure one page, find the single biggest bottleneck, fix that, and measure again.
This guide follows that order. You will measure first with Google’s free tools, learn what the three Core Web Vitals numbers mean, identify which of the five usual suspects is costing you the most time, and apply the fixes in an order you can re-test after each one.
Step 1: Measure before you change anything
Run the test before you touch a setting, so you have a baseline to compare against. Pick your most important page — usually the homepage or your most-visited article — and test it twice: once on mobile and once on desktop, because Google judges them separately.
PageSpeed Insights is the starting point. Paste the page’s URL into PageSpeed Insights and wait for the report. It gives you two kinds of data. The top section is field data: what real Chrome users experienced on that page over the previous 28 days, drawn from Google’s Chrome User Experience Report. The section underneath is a lab test: Lighthouse loads the page once on a simulated phone and connection and lists what slowed it down. Field data is what Google judges; lab data is what you debug with.
Google Search Console gives you the site-wide view. Its Core Web Vitals report groups URLs that behave alike and marks each group good, needs improvement, or poor. Use it to find which pages need attention first, then test those pages individually in PageSpeed Insights. Our guide to the Search Console Performance report covers how to read Search Console’s reports in detail.
Write the numbers down. A simple before-and-after log — date, page, the three Core Web Vitals numbers, and what you changed — is what turns a speed project from guesswork into a record you can trust. Keep it in a note or a spreadsheet; you will use it after every fix in this guide.
What the three Core Web Vitals numbers mean
Google’s Core Web Vitals are three measurements of how a page feels to real visitors. Each one covers a different kind of slowness, and a page passes the assessment only when all three are good at the 75th percentile of page loads — meaning three out of four visits meet the target.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | How long until the largest content in view, usually a hero image or headline block, has rendered | 2.5 seconds or less | Over 2.5 up to 4 seconds | Over 4 seconds |
| INP — Interaction to Next Paint | How quickly the page visibly responds after a tap, click, or key press | 200 milliseconds or less | Over 200 up to 500 milliseconds | Over 500 milliseconds |
| CLS — Cumulative Layout Shift | How much the visible content jumps around while the page loads | 0.1 or less | Over 0.1 up to 0.25 | Over 0.25 |
A few things worth knowing about these numbers:
- LCP is about the biggest thing on screen, not the whole page. A single oversized hero image is the most common cause of a bad LCP.
- INP replaced First Input Delay (FID) as the responsiveness metric in March 2024. Older advice that mentions FID is out of date; INP measures every interaction across the whole visit, not just the first one.
- CLS is a score, not a time. Zero means nothing moved. Images without size information, late-loading banners, ads, and font swaps are the usual culprits.
- The PageSpeed performance score (0 to 100) is a lab summary, not a Core Web Vital. A high score is nice, but it is not what the assessment uses. Chase the three numbers, not the score.
Step 2: Find the bottleneck
PageSpeed Insights lists its findings under the lab test as “opportunities” and “diagnostics,” each with an estimated time saving. Read that list before you change anything. In practice, the bottleneck is almost always one of five things:
- Images that are too large or unoptimized. The single most common cause of slow pages, and the easiest to fix.
- Slow server response (time to first byte). The server takes too long to start sending the page at all. Often a hosting problem.
- Too many or too heavy scripts. Chat widgets, analytics tags, social embeds, and JavaScript-heavy features block the page from becoming interactive.
- Render-blocking CSS and web fonts. The browser waits for stylesheets and fonts before it shows anything.
- No caching, or a weak hosting plan. The server rebuilds every page from scratch for every visitor, or the plan cannot keep up with the traffic.
Note which one PageSpeed Insights flags with the largest estimated saving, and start there. Fixing a 0.2-second script problem while a 3-second hero image sits on the page is wasted effort.
Step 3: Fix the images first
Images are the usual winner, and the fixes are straightforward.
Resize images to the size they are displayed at. A 4,000-pixel-wide photo shown at 800 pixels wide is four times larger than it needs to be. Before uploading, resize the image to the largest size it will actually be shown at — for most blog content images, that is between 800 and 1,600 pixels wide.
Compress them. Run every image through a compression tool before upload, or use an image optimization plugin that does it automatically. Compression typically shrinks a photo substantially with no visible loss of quality. Use a modern format such as WebP where your site supports it; it is usually smaller than JPEG or PNG for the same quality.
Lazy-load images below the fold. Images further down the page should load only when the visitor scrolls near them, not at the same time as the content at the top. WordPress does this by default for images in the post content — check that your theme has not disabled it, and do not lazy-load the hero image itself, since that is the image LCP measures.
Set width and height on every image. When the browser knows an image’s dimensions before it loads, it reserves the space and the layout does not jump when the image arrives. That is the single most effective fix for a bad CLS score, and it applies to embedded videos and ads as well.
Re-test the page after the image fixes. On an image-heavy page, this step alone often moves LCP from poor to good.
Step 4: Reduce the server response time
If the server itself is slow to answer, no amount of image compression will save the page. In PageSpeed Insights this shows up as a long time to first byte.
Enable caching. A caching plugin stores a finished copy of each page and serves it directly, instead of rebuilding the page from the database on every visit. For a WordPress site, this is the single highest-impact server-side fix. Install one caching plugin, configure it, and test — do not install two, because they will conflict.
Check your hosting plan. Shared hosting on an overloaded server, or a plan with too little memory for your traffic, shows up as slow response times that no plugin can fix. If the server response time stays high after caching, ask your host whether the server is overloaded, or consider whether the plan still fits your traffic. A slow host is a hosting problem, and the fix is a hosting decision, not another plugin.
Keep the database lean. Old post revisions, spam comments, expired transients, and unused plugin data accumulate in the database and slow every query. Clean them up periodically with a database optimization plugin or your host’s tools — after a backup, as always.
Step 5: Cut the scripts that block the page
JavaScript is the usual cause of a bad INP score: the page looks loaded, but tapping a button does nothing because the browser is still busy running scripts.
Audit what loads on the page. Open the page and list everything that is not content: chat widgets, analytics tags, social media embeds, pop-up tools, ad scripts, and font loaders. Ask of each one: does this page need it? Remove anything that does not earn its place, and remove it site-wide if it was added by a plugin you no longer use.
Defer or delay non-essential scripts. Scripts that are not needed for the first thing a visitor sees — analytics, chat widgets, social embeds — can be loaded after the page renders, or only when the visitor interacts with them. Most caching and optimization plugins offer a “delay JavaScript” setting for this. Apply it carefully and test the page afterward: delaying a script that the page actually needs can break a feature.
Remove unused plugins. Every active plugin adds code to the page. Deactivate and delete plugins you do not use, and do not keep two plugins that do the same job. Fewer plugins means fewer scripts, fewer database queries, and fewer things that can conflict.
Step 6: Fix the fonts and the CSS
Limit web fonts. Each font family and weight is a separate download that can delay the first render. Use one or two font families, load only the weights you actually use, and consider using system fonts for body text — they load instantly because they are already on the visitor’s device.
Avoid font swaps that shift the layout. When a web font loads late and replaces the fallback font, the text reflows and the layout jumps — a classic CLS problem. Set a fallback font with similar sizing, or use font-display: swap so the text appears immediately in the fallback font and swaps cleanly when the web font arrives.
Do not load CSS the page does not use. Page builders and themes often load stylesheets for features that are not on the page. Some optimization plugins can remove unused CSS, but test carefully: removing a rule the page does need will break its layout. If you are not confident, leave this step and take the smaller win from the image and script fixes.
Step 7: Re-test and log the result
After each fix — not after all of them — re-test the same page in PageSpeed Insights and write the new numbers in your log, next to what you changed. This is the discipline that makes the whole project work:
- If the numbers improved, keep the change and move to the next bottleneck.
- If they did not improve, revert the change. A fix that does not move a number is clutter, and clutter slows the next round of diagnosis.
- If the numbers got worse, revert immediately and note what happened.
Expect the field data at the top of PageSpeed Insights to lag behind the lab test: it reflects real visitors over the previous 28 days, so it takes time for your fixes to show up there. The lab test underneath is your immediate feedback; the field data is the verdict that arrives over the following weeks. Search Console’s Core Web Vitals report will also take time to update — check it weekly rather than daily.
A before-and-after test log you can copy
| Date | Page | LCP | INP | CLS | Change made | Result |
|---|---|---|---|---|---|---|
| — | Homepage | — | — | — | Baseline, no changes yet | — |
| — | Homepage | — | — | — | Compressed and resized hero image | — |
| — | Homepage | — | — | — | Enabled caching plugin | — |
| — | Homepage | — | — | — | Delayed chat widget script | — |
Fill one row per change. If you change three things at once and the numbers move, you will not know which change did it — and you will not know which one to keep.
What not to do
Do not install a stack of speed plugins at once. Caching plugins, optimization plugins, and image plugins overlap, and two of them doing the same job will conflict and slow the site down. Pick one tool per job. Do not chase the PageSpeed score instead of the three Core Web Vitals numbers — the score is a lab summary, and a page can score well while real visitors still wait. And do not rebuild the site or change hosts as a first step: measure first, fix the images, the scripts, and the caching, and only then decide whether the host is the problem.
The bottom line
Measure one page, find the biggest bottleneck, fix it, and re-test. For most sites the order is images, then scripts, then caching, then fonts — but your page’s own numbers decide, not this list. Keep a log of every change and its result, and give the field data time to catch up with the lab test. Speed work is not a one-time project; it is a habit of measuring, fixing one thing, and measuring again. If you are starting a new site rather than fixing an old one, our guide on starting a blog from scratch covers the setup choices — including hosting and theme selection — that keep a site fast from the beginning.
Frequently asked questions
What is a good page loading speed?
Google’s Core Web Vitals give the practical answer: the largest content visible within 2.5 seconds, a response to taps within 200 milliseconds, and a layout shift score of 0.1 or less, measured across real visitors at the 75th percentile.
Why does PageSpeed Insights show different results each time I test?
The lab test loads the page on a simulated connection, so results vary slightly between runs. The field data at the top, drawn from real visitors over 28 days, is more stable. Test the same page a few times and look at the pattern, not a single run.
Will a caching plugin alone fix my site’s speed?
It helps a lot with server response time, but it cannot fix oversized images, heavy scripts, or a bad CLS score. Caching is one fix among several, and it works best after the images are optimized.
How often should I check my site’s speed?
After any change to the theme, a plugin, or the homepage, re-test the affected pages. Otherwise, a monthly check of Search Console’s Core Web Vitals report is enough to catch regressions early.
