A slow WordPress site costs you twice. It costs you visitors who close the tab before the page finishes rendering, and it costs you search visibility, because page experience is now part of how Google evaluates a site. The frustrating part is that most WordPress performance problems trace back to a short, predictable list of causes. You rarely need a rebuild — you need to work through the right list in the right order. This checklist is organized roughly by impact versus effort, so you can start at the top and stop once the problems that actually matter for your site are handled.
Measure before you touch anything
Before changing a single setting, get a baseline. Tools like PageSpeed Insights and GTmetrix will give you two different kinds of data: a lab test, which simulates a page load under controlled conditions, and, where there's enough traffic, field data pulled from real visitors through the Chrome User Experience Report. The lab score is a diagnostic checklist — it tells you what's technically wrong with a specific page. The field data tells you what real visitors on real networks and real devices are actually experiencing. A site that scores well in the lab but shows poor field data for mobile users on average connections still has a genuine problem, and it's the one that affects rankings and conversions.
Test more than the homepage. A product page loaded with a slider, a blog post with embedded video, and a checkout page can behave very differently from each other even on the same install. Re-test after every significant change so you know which fix actually moved the needle instead of guessing.
Core Web Vitals, in plain language
Core Web Vitals are the three metrics Google uses as a proxy for how a page actually feels to use. You don't need to memorize the scoring thresholds, but understanding what each one measures makes every item further down this checklist easier to reason about.
LCP — Largest Contentful Paint
LCP measures how long it takes for the largest visible element — usually a hero image, a banner, or a large block of text — to render. It's a proxy for "when does this page feel loaded." Slow servers, unoptimized images, and render-blocking CSS or JavaScript are the usual culprits.
CLS — Cumulative Layout Shift
CLS measures visual stability: how much content jumps around as the page loads. It's what happens when an image without a defined width and height pops in and pushes everything below it down, or when a cookie banner or ad slot injects itself after the fact and shoves the button you were about to click. It's measured as a score, not a time, and it's usually one of the cheapest problems to fix once you know where it's coming from.
INP — Interaction to Next Paint
INP replaced First Input Delay as the responsiveness metric and measures the delay between a visitor's click, tap, or keypress and the page visibly responding. Heavy JavaScript — bloated theme scripts, third-party trackers, badly written plugins running on every interaction — is almost always the cause of poor INP. This one tends to get worse as a site accumulates plugins over the years, which is exactly the kind of drift a proper ongoing maintenance routine is meant to catch before it compounds.
All three matter for UX on their own merits, and Google has been explicit that they factor into ranking as part of page experience. Optimizing for Core Web Vitals and optimizing for a site that feels fast to a human are, in practice, the same project.
1. Hosting and server tier
This is the single biggest lever most site owners underuse, and it's also the one people are most reluctant to touch because it means spending money or migrating. Shared hosting puts your site on a server with hundreds of other accounts competing for the same CPU, memory, and I/O. No amount of caching plugin configuration fixes a server that's resource-starved at the PHP execution level. Managed WordPress hosting — where the host runs a WordPress-tuned stack with server-level caching, current PHP versions, and isolated resources — is usually a meaningfully better starting point than generic shared hosting at a similar price. A VPS or dedicated environment goes further, giving you control over PHP-FPM worker counts, memory limits, and the ability to run a proper object cache.
Two settings worth checking regardless of host: confirm you're on a current, supported PHP version (each major PHP release has brought real performance gains for WordPress specifically), and confirm your host isn't silently throttling or oversubscribing CPU during traffic spikes.
2. Page caching and object caching
WordPress builds most pages dynamically on every request — querying the database, running template logic, assembling the HTML — unless something intercepts that process. Page caching stores the fully rendered HTML output and serves that static copy to subsequent visitors instead of rebuilding the page from scratch every time. This is usually the single highest-impact, lowest-effort change you can make, and it's why most managed WordPress hosts enable it at the server level by default.
Object caching is a second, complementary layer. It caches the results of expensive database queries in memory (via Redis or Memcached) so that repeated queries — the kind WooCommerce and complex plugins generate constantly — don't hit the database every single time. Page caching helps anonymous visitors browsing static content; object caching helps logged-in users, dynamic pages, and anything running behind a shopping cart or membership gate where full-page caching isn't safe to use. If your site has an account area, a cart, or personalized content, object caching is often what actually moves your logged-in performance, since full-page caching typically can't be applied there.
3. Image optimization
Images are usually the single largest contributor to total page weight, and they're also one of the most mechanical things to fix. Work through these in order:
- Compress everything. Most images uploaded straight from a camera or a stock library carry far more data than a browser needs to display them at web resolution.
- Serve modern formats. WebP, and increasingly AVIF, produce smaller files than JPEG or PNG at equivalent visual quality. Most current image optimization plugins and CDNs can do this conversion automatically and serve the right format based on browser support.
- Size images correctly. Don't upload a 4000px-wide photo and let CSS scale it down to 400px in the browser — the visitor still downloads the full file. Generate and serve appropriately sized versions for different breakpoints.
- Lazy-load below-the-fold images so the browser doesn't spend bandwidth on images the visitor hasn't scrolled to yet. Just make sure your LCP image — usually a hero or banner near the top — is explicitly excluded from lazy loading, since lazy-loading the one image LCP is measuring will make that metric worse, not better.
- Set explicit width and height attributes on every image so the browser reserves the right amount of space before the image loads. This is one of the most common and cheapest fixes for CLS.
4. Audit and reduce plugin bloat
Every active plugin adds PHP execution time, and many add their own CSS and JavaScript to every page load whether that page needs it or not — a contact form plugin loading its scripts sitewide instead of only on the page with the form is a common offender. Go through your active plugin list and ask, for each one, whether it's still doing something the site needs, whether its functionality could be handled by something already installed, and whether it's actively maintained. Plugins that haven't been updated in a long time are both a performance risk and a security risk.
Use your browser's network tab, or a plugin performance profiler, to see which plugins are actually loading assets on pages where they aren't needed. It's common to find analytics scripts, page builders, and marketing plugins injecting JavaScript on every single page of a site when they're genuinely only used on two or three. If a plugin exists to solve one narrow business requirement and nothing on the market fits without dragging in unrelated bloat, that's often a sign it's worth having something built to spec — see our guide on custom WordPress plugin development for when that trade-off makes sense.
5. Database cleanup
WordPress accumulates database weight over time in ways that don't show up anywhere in the admin UI unless you go looking. Post revisions pile up (WordPress saves a new revision row every time you save a draft, by default with no limit). Transients — WordPress's mechanism for temporary cached data — regularly get left behind by plugins that were removed without cleaning up after themselves. Spam and unapproved comments sit in the database indefinitely. None of this necessarily makes pages render slower directly, but it bloats every database backup, slows down admin queries, and on high-traffic or WooCommerce sites where the database is queried constantly, it adds up. Clean out old revisions, expired transients, and orphaned metadata periodically, and consider limiting how many revisions WordPress keeps per post going forward.
6. Use a CDN
A content delivery network caches your static assets — images, CSS, JavaScript, fonts — on servers distributed geographically, so a visitor in a different region from your host isn't waiting on a round trip to a single origin server for every file. Beyond raw distance, a CDN also absorbs traffic spikes and reduces load on your origin server directly, which indirectly improves everything else on this list since your server has more headroom for the requests it does have to handle. Most CDNs also offer image optimization and modern format conversion as part of the same service, which overlaps usefully with item three above.
7. Minify and defer assets
Minification strips whitespace and comments from CSS and JavaScript files, and combining files reduces the number of separate requests a browser has to make — though with HTTP/2 and HTTP/3, the request-count problem matters less than it used to, and minification's main value now is simply reducing bytes transferred. More impactful than minification alone is dealing with render-blocking resources: CSS and JavaScript that the browser must download and process before it can paint anything on screen. Deferring non-critical JavaScript so it loads after the initial render, and inlining or prioritizing the CSS needed for above-the-fold content, directly targets LCP. Web fonts deserve the same attention — a font-loading strategy that avoids invisible text while fonts download, and avoids the visible re-flow when they swap in, addresses both LCP and CLS at once.
Putting it together
None of these seven items is exotic, and none requires rebuilding the site. Start with hosting and caching, since they affect every single page and every single visitor with no ongoing effort once set up. Then work through images and plugin bloat, since those are usually where the most waste has quietly accumulated. Database cleanup, a CDN, and asset optimization round things out and tend to deliver smaller but real gains.
The harder part isn't the first optimization pass — it's keeping the site from drifting back toward slow as new plugins get added, new content gets published, and updates change how existing code behaves. That's the gap that ongoing WordPress maintenance is meant to close, and it's also worth revisiting your performance checklist any time you're planning a site migration, since a move to new hosting is the natural point to fix problems you've been putting off. If your site needs more than configuration changes — a page builder that's outgrown itself, or custom functionality that's being forced through the wrong tool — it may be worth comparing that path against custom WordPress development before investing more time patching around the underlying problem. And if you'd rather have someone else run this checklist against your actual site, our team is available through our contact page.
