Fix a slow WordPress site by running a speed audit to find the bottleneck, enabling caching, updating to a modern PHP version, and compressing images. These steps can address common causes of slow WordPress sites. If server response time (TTFB) stays high after that, the remaining problem is almost always the host, and moving to WordPress-optimized hosting with server-level caching and a persistent object cache fixes it.
TL;DR:
- Use PageSpeed Insights and field data; target LCP at 2,500 milliseconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less.
- Back up before changes, enable page caching and a CDN, then test each major change against baseline TTFB, LCP, and CLS.
- On busy sites, OPcache can cut PHP response time by 30 to 50 percent; a Redis or Memcached object cache requires host support.
- Compress images, use responsive image sizes and lazy loading, and remove unused plugins; Query Monitor can identify plugins that slow database queries.
- Recheck every 4 to 12 weeks and after major site changes, using 75th percentile real visitor data rather than relying on a single lab run.
Table of Contents
- Run a Speed Audit and Read the Right Metrics
- Common Causes and How to Fix Each
- Prioritized Quick-Fix Checklist You Can Complete in One Session
- Persistent Object Cache, OPcache, and Server-Level Caching
- Verify Fixes and Set Up Simple Monitoring
- Ihor's Practical Takeaways and Triage Rules
- How InSave Hosting Helps Speed Up WordPress Sites
- FAQ
- Sources
Run a Speed Audit and Read the Right Metrics
Guessing wastes time. Before touching a single plugin, run a free PageSpeed Insights report on the slow page. It shows lab test results and field data from real visitors through the Chrome User Experience Report. For deeper diagnostics, pair it with Lighthouse or WebPageTest, which can help identify where time gets lost, such as server response, render-blocking scripts, or oversized images.
Several metrics are useful:
- TTFB (Time to First Byte): how fast your server starts responding; high TTFB almost always points to hosting or an unoptimized backend.
- LCP (Largest Contentful Paint): how long the main visible element takes to load; a high LCP with a low TTFB usually means render-blocking CSS/JS or an unoptimized hero image.
- INP (Interaction to Next Paint) and TBT (Total Blocking Time): how responsive the page feels when someone clicks or taps.
- CLS (Cumulative Layout Shift): how much the page jumps around as it loads.
Core Web Vitals have defined "good" thresholds: LCP at or under 2,500 milliseconds, INP at or under 200 milliseconds, and CLS at or under 0.1. Anything above those numbers is a real, measurable problem worth fixing, not a vague sense that the site "feels slow."
Lab data is useful because it is repeatable and lets you test a single page under controlled conditions. Field data matters more for prioritization because it reflects the 75th-percentile experience of actual visitors on real devices and real connections. A page that scores well in a lab test but poorly in field data usually has a problem that only shows up on slower phones or weaker connections, which is common with image-heavy blog posts and product pages. Check both before deciding what to fix first.
Common Causes and How to Fix Each
Once the audit tells you where the time is going, the fix usually falls into one of several categories.
Images are the most common offender on content-heavy sites. Run a bulk compression pass, convert JPEGs and PNGs to next-gen formats like WebP, add responsive srcset attributes so phones do not download desktop-sized files, and enable lazy loading for anything below the fold. Plugin-based tools built for this job, such as those listed on the official WordPress plugin directory, handle compression and format conversion automatically on upload.
Plugins and themes pile up hidden cost. A plugin that queries the database on every page load, even on pages where it does nothing, can add noticeable delay to every request. Install Query Monitor to see which plugins are slow, then deactivate suspects one at a time on a staging copy of the site to isolate the culprit. Favor lightweight alternatives over bloated all-in-one plugins, and keep both plugins and the theme updated, since performance patches ship regularly.
Caching is the single highest-leverage fix for most WordPress sites. Page caching serves a pre-built static version of a page instead of rebuilding it from the database every time, which removes most of the server-side work for repeat visits. Plugins such as W3 Total Cache, WP Super Cache, and Cache Enabler handle this at the application level, and WordPress's own performance documentation notes that combining a plugin cache with a system-level cache like Varnish produces stronger results than either alone. Set proper Cache-Control headers so browsers also cache static assets locally instead of re-downloading them on every visit.
Hosting and PHP version can affect TTFB. If your audit flagged a high TTFB and caching alone did not fix it, the server may be the bottleneck. Check whether your host supports modern PHP versions and OPcache, and whether server-level caching is available rather than relying only on a plugin.
Database bloat slows every query the site runs. Years of post revisions, expired transients, and orphaned tables add overhead that compounds over time. Clean revisions and transients, optimize database tables, and if you use a tool like WP-Optimize, run it carefully: schedule cleanups rather than running aggressive one-click optimizations on a live site without a backup.
Third-party scripts (chat widgets, trackers, embedded fonts, ad tags) often cost more than the entire rest of the page. Identify slow external scripts in your Lighthouse report, defer or load them asynchronously so they do not block rendering, and remove any widget or tracker that is not earning its keep.
Pro Tip: Fix server-side issues before touching anything client-side. A beautifully optimized image gallery still loads slowly if the server takes two seconds to respond before the browser even starts rendering.
Prioritized Quick-Fix Checklist You Can Complete in One Session
This sequence is designed to produce a measurable improvement, in an order that helps avoid breaking the site.
- Take a full backup first, every time, before making any change. This is non-negotiable; caching and database changes are reversible only if you planned for it.
- Enable caching and a CDN. Turn on a caching plugin or your host's server-level cache, then connect a CDN so static assets like images, CSS, and JavaScript load from a server near the visitor.
- Update PHP and turn on OPcache. Most host control panels let you select the PHP version; choose the latest version your plugins support and enable OPcache if it is not already on.
- Optimize images and clean up plugins. Bulk-compress existing images, add lazy loading and
srcset, then deactivate and delete any plugin or inactive theme you are not using. - Clean the database and re-check slow queries. Remove old revisions and transients, run Query Monitor again to confirm the slow queries you found earlier are gone, then optimize the tables.
- Re-run your speed audit. Compare the new TTFB, LCP, and CLS numbers against your first test to confirm the changes actually moved the needle.
Pro Tip: Make one change at a time when possible and re-test after each major step. Stacking five changes at once and seeing a big improvement feels great, but it tells you nothing about which change actually mattered if something regresses later.
Most sites see their biggest single jump after step 2, since caching removes repeated database work on every page view. Steps 3 through 5 tend to produce smaller, compounding gains rather than one dramatic shift.
Persistent Object Cache, OPcache, and Server-Level Caching
Some fixes need host support or a developer's hands on the server, but the payoff is worth understanding even if someone else implements it for you.
- Persistent object cache (Redis or Memcached): WordPress's built-in object cache is non-persistent by default, meaning it resets with every page load, as WordPress's own class reference explains. A persistent backend like Redis keeps that cached data in memory across requests, and WordPress's performance documentation notes this can turn a 50-millisecond MySQL query into a roughly 0.5-millisecond memory read. It requires a server component and a plugin to connect WordPress to it; our guide to enabling object cache walks through the setup where the host supports it.
- PHP OPcache: this stores precompiled PHP code in memory instead of recompiling it on every request. Enabling it at the server level can cut PHP response time by 30 to 50 percent on busy sites.
- Server-level caching (LiteSpeed, Varnish): unlike a plugin cache, which runs inside WordPress, server-level caching sits in front of PHP entirely and can serve a cached page without WordPress ever loading. It is the better choice for high-traffic sites, but it needs the host to support it, and someone needs to set sensible TTL and purge rules so visitors do not see stale content after you publish an update.
- CDN edge caching and Cache-Control headers: a CDN caches static assets (images, CSS, JavaScript) at servers closer to each visitor, cutting the distance data has to travel. Proper
Cache-Controlheaders tell both the CDN and the visitor's browser how long to keep a file before checking for a new version; some CDNs can also cache full HTML pages at the edge for anonymous visitors, which can further improve performance.
Pro Tip: If your host does not offer Redis or Memcached, ask what alternative it provides. Some hosts support SQLite-based object caching as a middle ground that still beats no persistent cache at all.
Verify Fixes and Set Up Simple Monitoring
A fix you cannot measure is a guess with extra steps. After each major change, re-run PageSpeed Insights and WebPageTest and compare the before-and-after numbers directly, paying closest attention to the 75th-percentile field data for LCP, INP, and CLS rather than a single lab run, since that field number is what Core Web Vitals actually measures.
- Check the CrUX report for your important pages to see how real visitors are experiencing them, not just how the test tool scores them.
- Schedule a full audit every 4 to 12 weeks, or immediately after any major plugin, theme, or content change.
- Watch server logs and uptime checks for new errors, and run Query Monitor periodically to catch a plugin update that quietly introduced a slow query.
A tool roundup like our guide to website speed test tools is worth bookmarking if you want a repeatable testing routine rather than reaching for a different tool every time.
Ihor's Practical Takeaways and Triage Rules
The triage order that saves the most time: check server-side response first, then caching, then assets and scripts. A high TTFB makes every other fix look weaker than it is, so fixing it first changes how much the rest of the checklist even matters. A 30-minute triage should run one PageSpeed test, check TTFB, flip on caching and OPcache if they are off, and test one suspect plugin in staging. That alone resolves most cases we see.
— Ihor
How InSave Hosting Helps Speed Up WordPress Sites
When the bottleneck turns out to be the server itself, our WordPress hosting plans offer an alternative to tuning server settings. We run a modern PHP version with LiteSpeed and LSCache built in, include a free CDN, and offer daily backups and a free migration, so moving over does not mean starting from scratch.
- WordPress-optimized plans (WP Start, WP Growth, WP Pro, WP Agency) with one-click installs and staging tools.
- Free migration handled for you, plus daily backups and automated security.
- Uptime monitoring and managed support if something needs a closer look.
Start on our WordPress hosting page to see which plan fits your traffic, or request a free migration.
FAQ
Why is my WordPress site running so slow?
The most common causes are a slow server response time (high TTFB), too many or poorly coded plugins, unoptimized images, and missing caching. Run a PageSpeed Insights test to see which of these is driving the slowdown on your specific site.
How do I make WordPress run faster?
Enable page caching and a CDN, update to a current PHP version, compress and lazy-load your images, and remove plugins you are not using. If server response time stays high after those steps, the host itself is usually the limiting factor.
Why is WordPress so slow today specifically?
A sudden slowdown that was not there before usually points to a recent plugin or theme update, a spike in traffic, or a new third-party script someone added. Check Query Monitor for newly slow queries and compare today's PageSpeed Insights result against an older report to spot what changed.
Why is my website running so slow in general?
Beyond WordPress-specific causes, general slowness often comes from large unoptimized images, render-blocking CSS or JavaScript, or a hosting plan that is undersized for the site's traffic. Running both a lab test and checking real-user field data clarifies whether the problem is the page itself or the server behind it.
How often should I re-check my site's speed?
Re-run a full audit every 4 to 12 weeks, and always immediately after a major plugin, theme, or content update. Comparing the new result against your previous baseline is the only reliable way to confirm a fix actually worked.