How to speed up a WP site without breaking it

Key takeaways

  • Check Time to First Byte (TTFB) first. If it is slow, look at hosting, PHP or a missing page cache. If TTFB is fast but the main content appears late, look at images, CSS and scripts.
  • In SpinupWP’s 2023 lab test, page caching raised server throughput from 42 to between 213 and 287 requests per second. Caching does nothing about heavy pages or too many scripts.
  • Don’t lazy-load the hero image. Resize images to the size they actually display at. The weight of each image matters more than how many there are.
  • On WooCommerce, keep Cart, Checkout, My Account, AJAX and Store API requests out of every cache. Place a full test order after each change.
  • Run one page cache, one CDN and one optimization tool. Find out what your host already does before you add anything.

HTTP Archive’s 2025 Web Almanac found that 45% of WordPress sites passed all three Core Web Vitals on mobile, and 53% had a good Largest Contentful Paint. So most WordPress sites are still slow on phones. The usual reaction is to install another speed plugin. In support threads, that is the most common way people make a site slower or break it.

The method that works is boring. Measure the page that is slow, find out where the time goes, make one change and test again. A speed setting that breaks a menu, a form or checkout is a bug, not an improvement. Stacked optimization features are also a common reason WordPress plugins stop working.

What do you need before you start?

You need an administrator login, access to your hosting dashboard (that is where server cache, PHP version and CDN settings usually live) and a recent backup you know you can restore. If your host offers a staging copy, test the risky steps there first.

You also need three free tools: PageSpeed Insights, your browser’s developer tools (the Network tab), and the Query Monitor plugin, which shows slow database queries and outside HTTP calls. Most image and plugin work happens in the WordPress admin. Changing caching rules, PHP or theme files needs hosting access.

Step 1. Measure the page that matters, on mobile

Test the page that earns money or leads, such as a product page, a service page or the booking form. The homepage alone doesn’t tell you enough. Run it through PageSpeed Insights on the mobile setting.

A single run is noise. The WordPress Performance Team’s measurement best practices recommend taking several measurements with the same setup. Run the test at least three times and use the middle result. Write down LCP, INP, CLS, TTFB, total page weight and the LCP element (the image or text block the test flags).

MetricWhat it measuresGood
Largest Contentful Paint (LCP)When the main content appears2.5 s or less
Interaction to Next Paint (INP)How fast a tap or click gets a response200 ms or less
Cumulative Layout Shift (CLS)How much the page jumps while it loads0.1 or less

The thresholds come from Google’s Core Web Vitals documentation. Google also says that meeting them doesn’t guarantee better rankings. Aim for real visitors’ numbers (the field data at the top of the report). The lab score is there to help you diagnose.

Step 2. Work out whether the server or the page is slow

TTFB tells you which half of the problem you have. If the first byte takes a long time, the browser is waiting for WordPress to build the page. Compressing a stylesheet won’t help with that. If TTFB is fast but LCP is slow, the page itself is too heavy.

SymptomLikely causeWhere to look
High TTFBNo page cache, slow PHP, heavy queries, hosting limitsHost dashboard, Query Monitor
Fast TTFB, slow LCPOversized or lazy-loaded hero image, render-blocking CSSNetwork tab, LCP element
Poor INPHeavy JavaScript from the theme, a page builder or widgetsPerformance trace, plugin list
High CLSImages or ads without dimensions, late fontsMissing width and height

If a theme or plugin is the suspect, isolate it. WooCommerce’s slow site troubleshooting guide suggests switching to a default theme for a while and turning extensions off one at a time. Do that on staging, not on the live site.

Step 3. Fix server response with hosting, PHP and one page cache

Start by finding out what your host already caches. Many hosts run their own server or edge cache, and some won’t let you add a caching plugin. Kinsta’s technical FAQ says it doesn’t allow them. A second page cache on top of the host’s cache causes conflicts and old pages that won’t go away.

Page caching matters when TTFB is the problem. In SpinupWP’s 2023 lab test, uncached WordPress handled 42 requests per second. With WP Rocket, WP Super Cache or W3 Total Cache it handled 213 to 253, and with Nginx FastCGI Cache it handled 287. That was one setup measuring server capacity, not what a visitor feels. If your host doesn’t cache, add one plugin that suits your server, for example LiteSpeed Cache on a LiteSpeed server.

Then check that the cache is actually working. Open the page in a private window, reload it, and look at the response headers in the Network tab for a cache “HIT” from your plugin or host. An installed cache that never hits does nothing.

Next, check PHP. Go to Tools > Site Health > Info > Server. WordPress’s requirements page recommends PHP 8.3 or newer. Check that your theme and plugins support it, then switch PHP in your host’s dashboard. On stores and membership sites, which can’t serve every page from cache, a persistent object cache such as Redis can reduce repeated database work if your host supports it.

If TTFB is still high while the cache is hitting, or you see 502, 503 or 504 errors, the server is running out of capacity or a request is too slow. Our guide to the 504 error on WordPress explains how to read the logs. Only upgrade hosting once you have measured that the server is the bottleneck. A pricier plan doesn’t fix a heavy plugin.

Step 4. Make pages lighter, starting with images

The usual image problem is size, not number. A 4,000 by 3,000 pixel camera photo shown 800 pixels wide makes every visitor download pixels nobody sees. A large Media Library doesn’t slow a page. Only the images on that page count.

  1. In the Network tab, filter by images and sort by size. Fix the largest files first.
  2. Resize to the width the theme displays, compress, and use WebP or AVIF where your setup supports them. WordPress then serves smaller copies to small screens through srcset.
  3. Lazy-load images below the fold. Never lazy-load the hero image. Load it straight away and give it fetchpriority="high". Lazy-loading the LCP image delays the one thing the test measures.
  4. Give every image a width and height so the browser can save space for it. This keeps CLS down.

Our guide to optimizing pictures in WordPress covers formats, bulk tools and how WordPress decides which images to lazy-load.

Step 5. Remove scripts and plugins you can’t justify

Plugin count is a poor guide. One badly built plugin can do more damage than twenty small ones. Use Query Monitor and the Network tab to see what each plugin loads and which queries it runs. Then delete any plugin nobody can explain, especially abandoned ones. That is cheaper than faster hosting, and every deleted plugin is one less thing to keep patched.

Third-party scripts such as chat widgets, trackers and ad code are often the heaviest items on the page. Removing one can be a business decision, so ask whoever owns it before you cut it.

Front-end optimization features (minify, combine, delay JavaScript, remove unused CSS) break things more often than anything else in this list. Turn them on one at a time. WP Rocket’s documentation says to turn off Combine JavaScript files when Delay JavaScript Execution is on. If a feature breaks a script, exclude only that script. After each change, open the mobile menu, submit a form and press the main button with the keyboard as well as by tapping.

If a heavy theme or page builder is the cause, replacing it is a redesign, not a quick fix. A builder your team edits every week can be worth its overhead. In that case, turn off the builder features you don’t use.

Step 6. On WooCommerce, protect checkout first

A faster store that can’t take payment is broken. WooCommerce’s checkout spinner documentation says to keep Cart, Checkout and My Account out of page and edge caching, and to make sure AJAX and Store API requests are never served from cache. If they are, customers see the wrong cart, a spinner that never stops, or wrong shipping rates.

After every change, purge every cache layer and place a full test order using your payment provider’s test mode. Add a product, change the quantity, apply a coupon and check the shipping and tax totals. Turning off cart fragments can speed pages up, but it can also stop the header cart from updating, so test that on staging first.

Step 7. Test the same way again, then keep or undo

Retest the same page with the same settings and the same number of runs, and compare it with your baseline. Keep a change only if it improved the metric you aimed at and nothing broke. Otherwise undo it before you try the next one. Write each change down in one line, because three weeks later nobody remembers which setting broke the contact form.

If a change doesn’t show up, an old copy is being served from somewhere. Purge the plugin cache, the host cache, the CDN and then the browser, in that order. Our guide to a page that isn’t updating explains how to tell which layer answered. Field data in Search Console takes weeks to catch up, so judge field results over time.

What if it’s still slow, or only the admin is slow?

A slow wp-admin is a different problem. Common causes are a bloated wp_options table, very large numbers of posts or custom fields, no object cache, old PHP, host limits and outgoing calls that time out. WooCommerce’s wp_options and site speed guide points out that autoloaded options load on almost every page. Check what is autoloaded before you delete anything, because removing rows blind can wipe settings a plugin still needs.

Stop and get help if checkout breaks and you can’t trace why, if you’re unsure what a database table belongs to, or if a script conflict goes beyond what the plugin settings can fix. If you’d rather hand the work over, SiteSelf’s speed optimization work starts from your slow page URL in chat. The agent makes the change on your site using hosting (SSH) access and reports what it changed and what it checked. Speed also drifts as content and plugins change, so a website care plan should name who retests and when.

Frequently asked questions

Do too many plugins slow WordPress down?

Quality matters more than count. One plugin that loads heavy scripts on every page or runs slow queries can outweigh many small ones. Measure what each plugin loads instead of deleting by number.

Do inactive plugins slow my site?

No official source in our research settles this. Delete inactive plugins anyway if nobody needs them. They clutter the admin and can still be a security risk if they fall out of date.

What is the best caching plugin?

The one that suits your host and server. If your host already caches pages, you may not need one at all, and some hosts don’t allow them. In SpinupWP’s lab test, the three popular plugins it measured landed in a similar range.

Do I need a CDN?

A CDN serves static files from servers closer to your visitors. It helps with delivery but won’t fix a slow server or a heavy page. Use one CDN, not two.

Why is my site fast on desktop but slow on mobile?

Phones have slower processors and less steady connections, so heavy JavaScript and large images hurt more there. PageSpeed Insights tests mobile on a slowed-down profile on purpose. Always test mobile directly.

How often should I run a speed test?

There is no official schedule. Retest after any plugin, theme or major content change, and check your key pages now and then for slow drift.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *