Speed Up WordPress: 8 Checks That Actually Move the Needle

Contents9 sections

Before you change a single setting, measure your site. Speed advice without a baseline is guessing: you cannot tell whether a change helped, hurt, or did nothing. A site with a slow server needs different work from a site with heavy images. So we start here, every time.

Go to PageSpeed Insights (Google’s free speed-testing tool), enter your homepage URL, and run the test. Write down the mobile and desktop results, especially the three Core Web Vitals — Google’s standard measures of how a page feels to load, use, and look at. Then test one more page — a busy product page or your most-read article. A fast homepage can hide a slow template. That baseline is what every check below gets judged against.

Work through the eight checks in order. Each covers what to check, what good looks like, and the fix.

1. Measure properly: field data first

What to check. PageSpeed Insights shows two kinds of data. The section at the top is field data: real measurements from real Chrome visitors over the previous 28 days. Below it is lab data: a single simulated test run on the spot. Lab data is useful for diagnosing a problem. Field data is what Google actually assesses, so treat field data as your scoreboard.

What good looks like. Google judges each vital at the 75th percentile of visits — at least three out of four visits must be good — separately for mobile and desktop:

• Largest Contentful Paint (LCP) — how fast the main content appears: 2.5 seconds or less.
• Interaction to Next Paint (INP) — how quickly the page responds when a visitor taps, clicks, or types: 200 milliseconds or less. (INP replaced the older First Input Delay metric in March 2024.)
• Cumulative Layout Shift (CLS) — how much the page jumps around while loading: 0.1 or less.

The fix if it is bad. If a page has too little traffic, PageSpeed may show no field data. Then work from the lab data and the opportunities list under it, and check again after a few weeks of visits. Note which vital is failing: a poor LCP usually points at the server, the top image, or missing caching. A poor INP usually points at heavy JavaScript, often from plugins. A poor CLS usually points at images without dimensions or content injected late.

2. Check your hosting and server response time

What to check. Time to First Byte (TTFB): how long the server takes to send the first byte of the page. Nothing else can start until that byte arrives.

How to check it. PageSpeed Insights reports TTFB in its diagnostics. Or open Chrome DevTools, load your page with the Network tab open, click the first document request, and read the “Waiting for server response” time.

What good looks like. web.dev’s rough guide: aim for a TTFB of 0.8 seconds or less. Over 1.8 seconds is poor.

The fix if it is bad. First, make sure caching is on (check 5) — an uncached page forces the server to rebuild it on every visit, which inflates TTFB. If TTFB is still slow with caching working, the hosting plan itself is the limit: too little CPU or memory for your traffic, or a server far from most visitors. Moving plans then does more than any plugin. If you are still choosing where a store should live, our guide to WordPress or Joomla for a small store covers how hosting and platform choices interact.

3. Check your PHP version

What to check. WordPress runs on PHP, the programming language WordPress is written in, and the version underneath your site affects both speed and safety. Go to Tools → Site Health → Info → Server in your dashboard to see the version you are running.

What good looks like. As of October 2026, the PHP project supports four branches: 8.2, 8.3, 8.4, and 8.5. PHP 8.4 and 8.5 receive full support (bug and security fixes). PHP 8.2 and 8.3 receive security fixes only, and 8.2’s security support ends on 31 December 2026. Anything older — 8.1 and below — is end of life: no patches at all.

The fix if it is bad. Newer PHP versions execute WordPress code faster and use less memory, so an upgrade is one of the few changes that speeds up every page at once. Most hosts let you switch PHP version from the hosting control panel. Take a full backup first, switch, then click through your key pages — homepage, a product page, checkout, contact form. If something breaks, switch back and update the plugin or theme that is not ready.

4. Fix your images

What to check. Images are usually the largest part of a page by weight. Check three things: file size, format, and dimensions.

How to check it. In PageSpeed Insights, look for warnings about properly sized images and modern formats. In your media library, open a few recent uploads and check their file sizes. Then compare each image’s pixel dimensions with the space it occupies on the page: a 3000-pixel photo in a 600-pixel column is far more than the job needs.

What good looks like. Photographs are compressed, in a modern format, and no larger than the slot they fill. WordPress helps more than it used to: it has supported WebP uploads since version 5.8 and AVIF since 6.5, it creates resized versions of every upload, and it lazy-loads images below the fold by default — all in core, no plugin required. AVIF can be up to 50% smaller than JPEG at the same quality, per the WordPress core team, and WebP is smaller than JPEG too.

The fix if it is bad. Resize images to the largest size they will ever be shown at before uploading, and compress them as you go. Prefer WebP or AVIF where your hosting supports it (Site Health’s Media Handling section tells you). One exception: never lazy-load the main image at the top of the page. That image is usually your LCP, and delaying it makes your headline metric worse. WordPress tries to exclude it automatically; if a plugin adds lazy loading of its own, check it does the same.

5. Turn on page caching

What to check. Whether your site serves a stored copy of each page, or rebuilds it from scratch for every visitor.

How it works, plainly. Without caching, every visit triggers the same work: WordPress loads, the theme assembles the page, plugins run their code, the database answers its questions, and only then does the visitor see anything. A page cache stores the finished page the first time it is built and hands that copy to the next visitors. The server does a fraction of the work, TTFB drops, and the page survives traffic spikes. Caching does not fix heavy images or a failing INP — it removes repeated server work, so it is not the whole list.

What good looks like. Caching is active, and a repeat visit is visibly faster than the first. Logged-in visitors and checkout pages are excluded from the cache, as they must be — a cached checkout is a broken checkout.

The fix if it is bad. Many hosts provide page caching at the server level. Check your hosting panel or ask support before adding anything, because a caching plugin on top of a server cache can cause conflicts. If your host offers neither, a well-maintained caching plugin is the standard route. Either way, use one caching method, not two. You can browse our downloads library for the tools we build and maintain.

6. Audit your plugins

What to check. Every active plugin adds code that runs on some or all of your pages. A plugin you installed for a one-off job, replaced, or stopped using still runs if it is still active.

How to check it. Go to Plugins → Installed Plugins and read the list honestly. For each one, answer: what does this do, and do I still need it? Then measure rather than guess. Take a PageSpeed reading, deactivate one suspect plugin, and read again. If nothing changes, reactivate it and try the next suspect. If the score jumps, you found weight you were carrying for nothing.

What good looks like. Every active plugin has a current job, there are no duplicates doing the same task (common with security, forms, and image tools), and nothing is active “just in case.”

The fix if it is bad. Deactivate what you do not need, then delete it: inactive code in your plugins folder is still a security consideration. Where a heavy plugin is genuinely needed, check its settings first — many load their scripts on every page when they only need to run on one.

7. Clean the database and cruft

What to check. Over time a WordPress database collects things nobody needs: leftover transients (temporary cached values), autoloaded options that load on every page whether they are used or not, dozens of saved revisions for every post, and spam or trashed comments.

How to check it. Site Health flags autoloaded options when they grow large enough to matter, and reports your database size. For revisions, open a busy post in the editor and look at the revision count.

What good looks like. Autoloaded data stays modest, revisions stay in single figures per post rather than hundreds, and spam comments are emptied, not stored.

The fix if it is bad. Empty spam and trash. Trim old revisions — you can limit how many WordPress keeps by adding define('WP_POST_REVISIONS', 10); to your wp-config.php file (the main settings file in your WordPress folder). Clear expired transients and bloated autoloaded options carefully, and always back up the database first. This check rarely transforms a score on its own; treat it as housekeeping that stops small problems compounding.

8. Update everything, and mind your theme’s weight

What to check. WordPress core, your theme, and every plugin should be current. Updates are not only about features: releases regularly include performance improvements and security fixes, and old versions miss both.

How to check it. Dashboard → Updates shows everything waiting in one place. We recommend turning on automatic updates for plugins and themes you trust.

What good looks like. Nothing is more than one release behind, and your theme earns its weight. A theme decides how much CSS and JavaScript every page carries before you add a single plugin. If you use a block theme, understanding how block theme patterns work helps you build pages from pieces the theme already loads, instead of stacking new styles onto every page.

The fix if it is bad. Update in a safe order: back up first, then plugins, then theme, then core, checking the site after each stage. Then look at your fonts — the quiet weight in many themes. Prefer a small number of font weights, and set font-display: swap so a built-in fallback font shows until yours finishes loading. A well-chosen system font stack — the fonts already on your visitor’s device — can serve readers just as well, with no download at all.

Finish the way you started: measure again

Go back to PageSpeed Insights and run the same pages you tested at the start. Compare the results with your baseline.

Two habits make this stick. First, change one thing at a time, then re-measure — change five things at once and you will not know which one moved the score, or broke something. Second, re-check after big changes: a new plugin, a theme update, a traffic spike. We treat speed as a short list of checks we return to, not a project with an end date. You now have the list.