How to Speed Up a WordPress Site, Step by Step
A slow WordPress site loses visitors and makes Google’s Core Web Vitals harder to pass. The good news: most speed problems come from a short list of causes, and fixing them in the right order matters more than installing more plugins. This guide shows how to measure, what to fix first, and how to confirm it worked.
- Measure before touching anything
- Fix order by real impact
- Hosting, cache, images, scripts, fonts
- How to verify results
Target split for a well-optimised page, from Google’s web.dev.
Test your key pages in PageSpeed Insights, then work in this order: better hosting and caching, smaller images, fewer and lighter scripts and styles, then fonts. Do not lazy-load the main image at the top of the page. Re-test after each change so you know what worked.
Why speed matters for SEO and visitors
Page speed is part of Google’s page experience, measured through Core Web Vitals: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for stability. Google’s web.dev sets the good thresholds at LCP of 2.5 seconds or less, INP under 200 milliseconds and CLS below 0.1, judged at the 75th percentile of real visits. Speed will not outrank great content, but a slow page hurts users first and rankings second.
For the full metric explanation see Core Web Vitals for WordPress.
Step 1: measure before you change anything
Test 3 to 5 key pages
Your homepage, your top service page and your best-traffic post. Homepages are often slowest because first-time visitors arrive with nothing cached.
Use PageSpeed Insights
It shows real-user field data (from Chrome UX Report) next to lab data. If lab and field disagree, trust the field data.
Check mobile and desktop
Mobile is usually worse and matters most.
Record LCP, INP, CLS and server response
Without a baseline you cannot prove anything improved. See site audit tools and Chrome extensions for more checkers.
Step 2: fix in the right order
Google’s LCP guidance breaks load time into four parts: server response (TTFB), delay before the main resource starts loading, the download itself, and render delay. On a healthy page the shares are about 40%, under 10%, about 40% and under 10%. That tells you where the time must go: into actually delivering the page and its main image, not waiting.
| Fix | Typical impact | Effort | Where |
|---|---|---|---|
| Better hosting and server cache | High | Low to medium | Section 4 |
| Compress and resize images | High | Low | Section 5 |
| Do not lazy-load the main image | Medium to high | Low | Section 5 |
| Remove render-blocking scripts and CSS | Medium | Medium | Section 6 |
| Fonts and layout shift | Medium | Low | Section 7 |
| Delete unused plugins | Varies | Low | Section 6 |
Impact ratings are my own experience. Results vary by site.
Fix 1: hosting, server response and caching
If the server is slow to send the first byte, nothing else can fully compensate. Google notes that a high TTFB can make a 2.5 second LCP very hard to reach, and common causes include redirect chains, distant servers and URL parameters that prevent cache hits.
- Use a host with fast servers near your visitors. See LiteSpeed hosting and VPS hosting
- Turn on page caching (for example a cache plugin that works with your server)
- Use a CDN so files come from nearby
- Use a current PHP version your plugins support
- Stacking several cache plugins
- Redirect chains from old URLs
- Cheap overcrowded hosting for a busy site
Fix 2: images (the biggest quick win)
Google’s web.dev reports that at the 90th percentile sites send over 5 MB of images. Fix this and many pages get dramatically faster.
Resize before upload
Do not upload a 4000 pixel photo to show at 800 pixels.
Use modern formats
WebP or AVIF are smaller than JPEG and PNG at similar quality.
Lazy-load below the fold
Add loading=”lazy” to images further down. WordPress does this by default for many images.
Never lazy-load the top image
Google warns that lazy-loading the LCP image adds delay. Give that one image fetchpriority=”high” instead.
Set width and height
Without dimensions the page jumps as images load, which hurts CLS.
Heavy
Light
Fix 3: scripts, styles and plugins
Browsers must load CSS before painting. Google says render-blocking stylesheets can keep the main image hidden and recommends shrinking them, removing unused rules and avoiding synchronous scripts in the head, using async or defer where possible.
Fix 4: fonts, layout shift and the rest
Use fewer
Limit families and weights, and host them yourself where possible. Avoid settings that hide text while a font loads.
Reserve space
Give ads, embeds and images fixed dimensions so content does not jump.
Tidy occasionally
Remove spam and old revisions. A small gain on most sites.
Verify the improvement
Lab scores change right away. Field data in PageSpeed Insights and Search Console reflects the past period, so it moves slowly. Keep notes on every change so you can undo one that caused a problem. Slow pages also waste crawl time; see discovered, currently not indexed.
WordPress speed questions
What is a good load time?
Google’s benchmark is an LCP of 2.5 seconds or less for at least 75% of visits.
Do I need a caching plugin?
Usually yes, or server-level caching from your host. Use one caching solution, not several.
Does speed affect rankings?
Page experience is considered by Google, but helpful content remains the main factor. Speed mainly protects the user experience.
Should I lazy-load all images?
No. Lazy-load images below the fold, never the top image.
Why is my mobile score worse?
Mobile devices and networks are slower, so the same page takes longer.
Can too many plugins slow my site?
Yes, if they load heavy scripts. Quality matters more than count.
Is a CDN worth it?
For visitors far from your server, yes. It shortens delivery distance.
Thresholds and the LCP breakdown come from web.dev. The fix ranking and WordPress tips are my own experience.