7 WordPress Performance Fixes That Actually Move the Needle

After more than a decade of performance work on client sites, these are the seven fixes that consistently deliver the biggest wins – in the order I apply them.
Measure first, then fix
Before touching anything, find out where time is actually being spent. Run the site through PageSpeed Insights and look at the two numbers separately:
- TTFB (Time to First Byte) – if this is over 600ms, your problem is on the server: slow PHP, slow database queries, or no page caching.
- LCP (Largest Contentful Paint) – if TTFB is fine but LCP is slow, your problem is on the front end: images, render-blocking CSS/JS, or fonts.
These two problems have completely different solutions. Installing an image optimization plugin won’t fix a 2-second TTFB, and upgrading your server won’t fix a 4MB hero image.
Get page caching right (one plugin, configured properly)
A single well-configured caching plugin outperforms three overlapping ones every time. Whether you use WP Rocket, a host-level cache, or a hand-rolled Nginx FastCGI cache, the goal is the same: anonymous visitors should never trigger PHP at all.
Common mistakes I fix constantly:
- Cache being bypassed because a plugin sets a cookie on every visitor
- WooCommerce cart fragments loading on every page, including the blog
- Query strings (UTM parameters) creating a separate cache entry per campaign link
Remove the plugins you don’t need
Every active plugin potentially adds queries, scripts, and hooks to every page load. On most audits I find 5-10 plugins that are deactivated in spirit but still running: an old slider on a page that no longer exists, a forms plugin replaced by another one, an analytics tool nobody checks.
Use Query Monitor to see exactly which plugins are adding the slowest database queries and the most HTTP requests. The results usually surprise site owners.
Serve images like it’s 2026
Images are still the #1 cause of slow LCP. The fix is a combination, not a single step:
- Convert to WebP or AVIF (most optimization plugins and CDNs do this automatically now)
- Set explicit
widthandheightattributes so the layout doesn’t shift - Don’t lazy-load the hero image. Lazy-loading your LCP element makes it slower, not faster. Add
fetchpriority="high"to it instead.
Deal with render-blocking CSS and JS surgically
“Minify and combine everything” is outdated advice under HTTP/2. What matters now:
- Defer non-critical JavaScript
- Delay third-party scripts (chat widgets, tracking pixels) until user interaction – this alone often improves Total Blocking Time dramatically
- Remove unused CSS where practical, but test carefully – automated “remove unused CSS” features break more sites than any other optimization
Clean up the database
Post revisions, expired transients, and orphaned meta rows accumulate for years. On older sites I regularly find wp_options tables where autoloaded data has grown past several megabytes – meaning every single page load drags that data out of the database.
Check your autoloaded options size, clean out transients, and limit post revisions in wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
Fix the hosting last – but do fix it
If you’ve done all of the above and TTFB is still slow, the server itself is the bottleneck. Shared hosting with hundreds of neighbours, PHP 7.x still running in 2026, no object cache – these are problems no plugin can solve.
A properly configured VPS with PHP 8.3+, OPcache, and Redis object caching costs less than most “premium” shared hosting and outperforms it by a wide margin.
The order matters
Notice the sequence: measure, cache, remove, optimize assets, then infrastructure. Most site owners do it backwards – they buy a bigger server to compensate for a 6MB page. Fix the page first.
Enjoyed this article?
Check out more articles on web development, WordPress, and modern technologies.
View All Articles