WordPress performance quick wins

Symptoms

The site takes multiple seconds to load, the admin feels sluggish, or a WooCommerce store struggles under traffic. PageSpeed Insights shows a slow LCP and a long "Reduce main thread work". The same lessons that apply to any WordPress install (the Core Web Vitals thresholds are the benchmark) apply here, but the architecture adds its own hot spots: shared hosting, dozens of plugins, an autoloaded options table, and a PHP runtime that starts from scratch on every request.

The fix order

Step 1: Turn on a page cache

WordPress boots the PHP runtime, loads the theme, and runs the query stack on every uncached request. A full-page cache (a host-level page cache, or a caching plugin) answers most visits from disk without booting WordPress at all. This single step removes the biggest contributor to TTFB for logged-out visitors.

Step 2: Compress your media

Images are the biggest weight on most sites. Convert uploads to WebP or AVIF, use the dimensions the theme actually renders, and stop lazy-loading above the fold (a hero image should fetch immediately). The image optimisation guide is the detail; the short list: recompress, resize, lazy-load below the fold only.

Step 3: Trim autoloaded data

The wp_options table holds autoloaded rows WordPress loads on every request, no matter the page. A theme or plugin that piles transient settings here adds real cost per request. Look for the autoload column in wp_options, identify the heavy rows, and clear or delete obsolete ones. Verify first, then remove, because some plugins rebuild them.

Step 4: Cut the plugin bill

Every active plugin adds its own front-end scripts, hooks, and database calls. Triaged list:

• Remove plugins installed but inactive; they still populate hooks if active.
• Look at plugins that load a builder everywhere, inject CSS/JS into every page, or communicate with an external API.
• A lazily loaded, unused analytics tracker adds main-thread time too.

You measure, not ban: the front-end network tab and the Lighthouse "Reduce main thread work" audit are the evidence, covered in the heavy site route.

Step 5: Hosting to fit

If the cache is on and the plugins are safe but TTFB stays high, the host is the bottleneck: oversubscribed shared resources, an under-sized PHP pool, or a distant region. Move to a host with PHP-FPM, match the plan to the traffic, or put the site behind a CDN for static assets.

Step 6: A CDN when the pattern fits

A reverse proxy or CDN edge caches responses at the network edge, and for WordPress it works best when the page-cache HTML is the thing being cached. Add the CDN after the page cache, then test that the purge behaviour works and a logged-in admin never sees a cached login.

Verify with LCP

Re-run PageSpeed Insights and check the LCP moved. A flat LCP that does not respond to cache and image steps points at a server or third-party ceiling. Each step above should show a visible drop, moving the page toward a good 2.5s LCP. The LCP optimisation page shows what the element-specific route looks like after these general wins.