“Install a caching plugin” is usually the first (and sometimes only) piece of WordPress speed advice people get. It helps, but it’s rarely the biggest lever. Here’s the order we actually work through when a WordPress site’s Core Web Vitals need fixing.
1. Find out what’s actually slow first
Before changing anything, we profile the site — server response time (TTFB), largest contentful paint, and what’s blocking render. Guessing at fixes without this step means optimizing things that were never the bottleneck.
2. Server response time (TTFB)
If the server itself is slow to respond, no amount of front-end optimization fixes it. This usually comes down to hosting quality, PHP/object caching (like Redis), and database query efficiency — often the single biggest win available.
3. Images, properly
Unoptimized, oversized images are still one of the most common causes of a slow Largest Contentful Paint. Correct sizing, modern formats (WebP/AVIF), and lazy-loading everything below the fold usually produces a bigger visible improvement than most plugin settings combined.
4. What’s blocking render
Render-blocking CSS and JavaScript — often from page builders and a stack of plugins each loading their own assets — delay when a page becomes visible and interactive. Deferring non-critical scripts and trimming unused CSS is where a lot of “my site feels slow” complaints actually get solved.
5. Caching, last
Page caching is genuinely valuable, but it’s a multiplier on top of the fixes above, not a replacement for them. A cached page built on a slow, bloated foundation is still a slow, bloated page — just cached.
We build performance budgets into every WordPress project from day one rather than retrofitting them after launch. If your current site’s Core Web Vitals need a real diagnosis rather than another caching plugin, we can help.