A slow WordPress site loses people before they read a word. The good news: most slow sites share the same few problems, and you can fix them in a set order. This guide shows you how to speed up WordPress in 2026 with current numbers from Google and WordPress.org, not guesses from an old blog post.
You will learn what “fast” means today, how to read your test results without getting fooled, and a 12-step checklist you can work through one step at a time. There is a printable version near the end.
The short answer
Test first, then fix in this order: back up, update WordPress and plugins, move to a supported PHP version (WordPress recommends 8.3 or newer), check your hosting, turn on one page cache, shrink and convert your images to WebP or AVIF, lazy-load only images below the first screen, cut plugins and scripts you do not need, add a CDN, and clean the database. Test again after each step. Aim for Google’s “good” Core Web Vitals: LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less.
What “fast” means in 2026
Google measures how a page feels to real people with three numbers called Core Web Vitals. Per Google’s Core Web Vitals guide on web.dev, these are the targets for a “good” experience:
| Metric | What it measures in plain words | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How fast the biggest thing on screen shows up, often your hero photo or headline | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | How fast the page reacts when someone taps a button or opens a menu | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much the page jumps around while it loads | 0.1 or less | Over 0.25 |
Two details matter here. First, Google looks at the 75th percentile. That means most of your visitors, not just the lucky ones on fast wifi, need a good experience. Second, INP is fairly new. It replaced an older metric called First Input Delay in March 2024. If a guide you are reading still talks about “FID,” it is out of date.
Does speed help you in Google? Google says it “highly recommend[s]” good Core Web Vitals for success in Search, and that page experience lines up with what its ranking systems reward. It does not promise that a good score will move you up. Treat speed as one part of a good site, not a magic switch.
Lab data and field data are not the same thing
This is where most owners get confused. A PageSpeed Insights report shows two kinds of results, as Google’s PageSpeed Insights documentation explains:
- Lab data is one test run by a tool called Lighthouse in a simulated setting. It gives the 0 to 100 Performance score. A score of 90 or above is “good,” 50 to 89 “needs improvement,” and below 50 is “poor.” Lab data is great for finding problems.
- Field data comes from real Chrome users who visited your page over the last 28 days. This is the data behind your Core Web Vitals pass or fail.
Why your score jumps around, and why you may see “no data”
Lab scores move from run to run because network and server timing change. Run each test three times and use the middle result. Do not panic over a few points.
Many small business sites do not get enough visits for field data. When that happens, PageSpeed Insights falls back to data for your whole site. If there is still not enough, it shows no real-user data at all. Search Console’s Core Web Vitals report works the same way and may say “No data available.” That is normal for a small site. Use lab data to guide fixes, and test on a real phone.
How to test your WordPress speed
Before you change anything, write down where you start. Without a baseline you cannot tell which fix helped.
- Pick three pages: your home page, your top service page and one blog post or gallery page.
- Run each page through PageSpeed Insights. Look at the mobile tab first. Write down LCP, INP (if field data exists), CLS and the Performance score.
- Note the top items under “Diagnose performance issues.” These tell you where the time goes.
- In WordPress, open Tools > Site Health. It flags an outdated PHP version and plugins that need updates.
- Open your site on your own phone using mobile data, not office wifi. Tap the menu and the call button. Does anything lag or jump?
- If you use Search Console, open the Core Web Vitals report and note any URL groups marked Poor or Need improvement.
Want a quick outside look first? Our free Website Teardown checks your home page and includes a mobile speed reading pulled from Google PageSpeed. It is a quick screen, not a full audit, but it tells you whether speed is a real problem before you spend an afternoon on it.
Why WordPress sites get slow: a decision table
Match what you see in your test to the most likely cause. Start with the first fix in that row before you try anything fancy.
| What you see | Likely cause | First fix | Who usually handles it |
|---|---|---|---|
| Slow start before anything shows (“reduce initial server response time,” high TTFB) | Slow or crowded hosting, old PHP, no page cache | Turn on page caching, then check PHP version and hosting | Host or developer |
| Poor LCP and “properly size images” or “serve images in next-gen formats” | Huge photos, old JPEG and PNG files, hero image lazy-loaded | Resize, convert to WebP or AVIF, make sure the hero image is not lazy-loaded | Owner with a plugin, or developer |
| Poor INP, menus or buttons feel sticky | Heavy JavaScript from plugins, page builders, chat widgets and trackers | Remove scripts you do not need; delay the rest | Developer |
| Poor CLS, text jumps while loading | Images, ads or embeds without set sizes; web fonts swapping | Set width and height on images and embeds; reserve space for banners | Developer |
| Admin area slow, site slows over time | Bloated database, large autoloaded options, too many revisions | Back up, then clean the database and cap revisions | Developer or maintenance plan |
| Fast for you, slow for people far away | No CDN, server far from visitors | Add a CDN | Owner or host |
Notice TTFB in the first row. That is Time to First Byte, how long the server takes to start answering. Google’s rough guide is 0.8 seconds or less. It is not a Core Web Vital, but a slow TTFB makes a good LCP very hard.
The 12-step checklist to speed up WordPress
Work in this order. The early steps are safe and often fix the most. Test after each step so you know what helped.
1. Record a baseline and take a full backup
Save your test numbers from the section above. Then back up. WordPress.org notes that a backup has two parts, the database and the files, and you need both to restore a site. Back up always before an update or a big change. Confirm you can actually download the backup.
2. Update WordPress, your theme and your plugins
Updates often include speed fixes as well as security patches. Update on a staging copy first if your host offers one. Update plugins one at a time on busy sites, and check the site after each one. If you have not logged in for months, this step alone may change your numbers.
3. Move to a supported PHP version
PHP is the language WordPress runs on. The WordPress.org requirements page recommends PHP 8.3 or greater. WordPress still runs on PHP 7.4, but those old versions are past end of life and may leave your site open to security holes.
Check the dates too. The PHP supported versions page shows PHP 8.2 gets security fixes only until December 31, 2026. PHP 8.3 is covered until December 31, 2027, and 8.4 until December 31, 2028. If your host still runs 8.2 or older, plan the move now. Most hosts let you switch PHP in the control panel. Test on staging first, because an old plugin may break on a newer PHP.
4. Check your hosting and server response
If TTFB is slow even with caching on, the server is the bottleneck. No plugin fully fixes a slow server. WordPress.org’s own guide notes that paying for a better level of hosting can be very effective. Ask your host three questions: which PHP version you are on, whether server-level caching is included, and whether a persistent object cache is available.
5. Turn on one page cache
Without a cache, WordPress builds each page from scratch for every visitor. A page cache saves a ready-made copy. Per WordPress.org’s own optimization guide, caching plugins “will cache your WordPress posts and pages as static files.” Many hosts include server caching. Use your host’s cache or one caching plugin, never two at once. Two caches fight each other and can show visitors old or broken pages.
If your host offers a persistent object cache (often called Redis or Memcached), WordPress says it can speed up page loads by saving trips to the database. This helps most on busy or logged-in sites like stores and member areas.
6. Resize images and switch to WebP or AVIF
Photos are often the heaviest thing on a small business site. Do two things. First, resize each photo to about the largest size it will show on screen. A phone photo can be several times wider than any screen needs. Second, use a modern format.
WordPress has supported WebP uploads since version 5.8 and AVIF since 6.5, as long as your server’s image library supports it (check under Tools > Site Health > Info > Media Handling). According to MDN’s image format guide, lossy WebP files are on average 25 to 35 percent smaller than JPEGs of similar quality, and lossy AVIF files are around 50 percent smaller. MDN suggests keeping a fallback format for AVIF, so ask your image plugin or developer to set one.
7. Lazy-load below the fold, but never the hero image
Lazy loading means an image waits to load until the visitor scrolls near it. WordPress has added this by default since version 5.5 for images with a set width and height. Since 6.3, it also skips lazy loading for the first images and adds a “load this first” hint, called fetchpriority, to the image most likely to be your LCP.
The catch: Google’s web.dev guide says to never lazy-load your LCP image, because it delays the most important thing on the screen. Some older lazy-load plugins and page builders lazy-load everything, including the hero. If your LCP got worse after adding a speed plugin, check this first.
8. Audit your plugins
WordPress.org’s advice is short: “Deactivate and delete any unnecessary plugins.” The count matters less than what each plugin does. One heavy plugin that loads scripts on every page can hurt more than ten light ones. Go through your list and sort each plugin into keep, replace or delete.
- Delete anything inactive. Inactive plugins still sit on the server and still need updates.
- Replace plugins that do the same job twice, such as two SEO plugins or two form plugins.
- Question plugins that load on every page but are used on one page, like a slider or a booking widget.
- Keep the rest, and keep them updated.
9. Check your theme and page builder
A theme packed with sliders, animations and features you do not use adds code to every page. Heavy page builders can do the same. You do not always need to rebuild. Start by turning off unused theme features and builder modules. If the theme still drags after steps 1 to 8, a lighter theme or a rebuild may cost less over time than fighting it.
10. Cut third-party scripts that slow taps and clicks
This is the main fix for a poor INP. Google’s web.dev guide explains that slow responses come from long tasks on the main thread, heavy JavaScript and very large pages. On a small business site, the usual sources are chat widgets, extra tracking tags, social feeds, video embeds and pop-up tools. Google’s advice on third-party scripts is plain: remove a script if it does not add clear value. For the rest, load them later so they do not block the page.
11. Add a CDN
A CDN (content delivery network) is a group of servers in many places that keep copies of your files and serve each visitor from the closest one. WordPress.org says using a CDN “can greatly reduce the load on your website.” Many hosts include one. If most of your customers are in Central PA, a CDN still helps by taking load off your server, but a good host close to your visitors matters more.
12. Clean the database, after a backup
By default, WordPress saves a copy of every edit to a post or page. Over years, that adds up, along with spam comments and data left behind by deleted plugins. After a fresh backup:
- Empty spam and trash comments.
- Delete old revisions, then cap them. Adding
define( 'WP_POST_REVISIONS', 3 );to wp-config.php keeps three per post. That example comes from the WordPress.org docs. - Check autoloaded options. These are settings WordPress loads on every page view. WordPress.org says to try to keep them under 800 KB.
- Remove tables left by plugins you no longer use. Only do this if you are sure what a table belongs to.
Then run your three-page test again and compare it with your baseline.
A worked example: the photo problem
This is a hypothetical example with round numbers to show the math. It is not a client result.
Say a contractor’s home page has a gallery of 10 project photos. Each one came straight from a phone at about 4 MB. That is about 40 MB of images on one page. On a weak phone signal at a job site, that page will crawl.
Now resize each photo to the width it actually shows at and save it as WebP. Say each file lands around 200 KB. Ten photos now weigh about 2 MB. That is about one twentieth of the starting weight, with no change to how the page looks. Add lazy loading for the photos below the first screen, and the first screen only needs the hero image to load.
| Before | After | |
|---|---|---|
| Photos on the page | 10 | 10 |
| Size per photo (round numbers) | About 4 MB | About 200 KB |
| Total image weight | About 40 MB | About 2 MB |
| Loaded on first screen | All of them | The hero image only |
Printable checklist
Print this or copy it into your notes. Check off each line and write your test numbers next to step 1 and step 13.
WordPress speed checklist
- ☐ 1. Test 3 pages on mobile. Write down LCP, INP, CLS and score.
- ☐ 2. Full backup of files and database. Confirm you can download it.
- ☐ 3. Update WordPress core, theme and plugins (staging first if you can).
- ☐ 4. Check PHP version in Site Health. Plan a move to 8.3 or newer.
- ☐ 5. Ask your host about server caching and object cache.
- ☐ 6. Turn on one page cache. Only one.
- ☐ 7. Resize big photos. Convert to WebP or AVIF.
- ☐ 8. Confirm the hero image is not lazy-loaded.
- ☐ 9. Delete inactive and duplicate plugins.
- ☐ 10. Turn off unused theme and builder features.
- ☐ 11. Remove chat, tracking and social scripts you do not need.
- ☐ 12. Turn on a CDN. Clean the database and cap revisions.
- ☐ 13. Test the same 3 pages again. Compare with step 1.
Common mistakes that waste your time
- Chasing a perfect 100. The lab score is a guide. Real visitors and the Core Web Vitals matter more. A site at 85 that feels fast on a phone is in good shape.
- Running two caching tools. A host cache plus a cache plugin, or two plugins, can conflict and serve stale pages.
- Lazy-loading the hero image. It makes LCP worse, not better.
- Installing a speed plugin to fix a slow server. If TTFB is slow, fix hosting or PHP first.
- Testing once on office wifi. Test on mobile, more than once, from a phone on mobile data.
- Cleaning the database with no backup. One wrong click can delete real content.
- Turning on every option in a speed plugin. Settings that combine or delay scripts can break menus, forms and checkout. Change one setting at a time and test your forms.
- Only testing the home page. Your service pages and galleries are often the slow ones.
- Fixing speed once and forgetting it. New plugins, photos and scripts creep back in. Speed is part of regular upkeep.
What to do yourself and what to hand off
| Task | Most owners can do it | Better with a host or developer |
|---|---|---|
| Run tests and record numbers | Yes | |
| Backups and updates | Yes, with a backup you can restore | On busy sites or stores, test on staging first |
| Resize and convert photos | Yes, with an image plugin | |
| Delete inactive plugins | Yes | |
| Change PHP version | Sometimes, in the host panel | Yes, if old plugins may break |
| Delay or remove scripts for INP | Yes, since it can break forms and tracking | |
| Database cleanup and autoload fixes | Yes | |
| Theme or builder change | Yes |
If you would rather not touch any of this, our website maintenance service covers updates, backups and ongoing checks, and our WordPress development help handles the deeper fixes like scripts, themes and database work.
FAQ
Why is my WordPress site so slow?
Usually a mix of a few things: slow or crowded hosting, no page cache, large photos, too many heavy plugins or scripts, and an old PHP version. Run PageSpeed Insights and use the decision table above to find which one is yours.
How do I check my WordPress site speed?
Run your key pages through PageSpeed Insights on mobile, check Tools > Site Health in WordPress, and look at the Core Web Vitals report in Search Console if you have enough traffic. Then open the site on your own phone using mobile data.
What is a good PageSpeed score?
Google calls a lab Performance score of 90 or above good, 50 to 89 needs improvement, and below 50 poor. The Core Web Vitals matter more: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less.
How many plugins is too many?
There is no magic number. One heavy plugin can slow a site more than ten light ones. Delete what you do not use, remove duplicates, and watch for plugins that load scripts on every page.
Do I need a caching plugin?
You need page caching, but not always a plugin. Many hosts cache at the server level. Use your host’s cache or one plugin, not both.
Does site speed affect SEO?
Google highly recommends good Core Web Vitals for success in Search, but it does not promise rankings for a good score. Speed helps visitors stay and contact you, which is the bigger reason to fix it.
What PHP version should WordPress use in 2026?
WordPress recommends PHP 8.3 or greater. PHP 8.2 security support ends December 31, 2026, so sites on 8.2 or older should plan a move now.
Should I use WebP or AVIF?
Both are much smaller than JPEG. WebP is the safe default. AVIF is often smaller still, and WordPress supports it since 6.5 if your server does. Keep a WebP or JPEG fallback when you serve AVIF.
What to do first
If you only have one hour this week, do steps 1, 2 and 6: test, back up and update, then fix your biggest photos. Those three often make the most visible change. Next week, check PHP and caching with your host.
If your site is a lead source for ads, also run our 12-point landing page speed and mobile check. For the routine that keeps a site fast after launch, see our website maintenance checklist for after launch. And for how speed fits the bigger picture of a site that brings in calls, read our small business web design guide.
Want a second set of eyes on your WordPress site? Book your strategy call and we will look at what is slowing it down and what to fix first.
Keep reading
- Landing Page Speed and Mobile: 12-Point Check Before Ads
- Website Maintenance Checklist: What to Do After Your Site Launches
- Small Business Web Design Guide
- Free Website Teardown: what is costing you calls
- Website Maintenance services
Want help with this in Carlisle or Central PA?
Webfactory Media is a Carlisle, PA agency. See our WordPress development in Carlisle and website maintenance pages, or call (888) 849-2397 and we will look at your site for free.
