How to Speed Up a WordPress Site (Server Side First)

Quick answer To speed up a WordPress site, work in this order: measure first, fix images, enable server-level page caching, move to a current PHP version with enough memory, add object caching if your pages are dynamic, then reduce plugins. Most guides start at plugins. That is the least effective end of the list.

First, measure the right thing

Before changing anything, get a baseline. Otherwise you will not know which change helped.

Three numbers matter.

Time to first byte. How long the server takes to start responding. This is the purely server-side number and it is the one hosting affects most directly. Anything consistently above about 600 milliseconds points at the server, PHP or the database rather than at your front end.

Largest Contentful Paint. How long until the main content appears. Usually dominated by images and render-blocking resources.

Interaction to Next Paint. How quickly the page responds to input. Usually a JavaScript problem.

Measure a real page, not the homepage alone, and measure logged out. Logged-in pages bypass caching and will mislead you.

Use field data where you have it. Lab tools give you a controlled score; field data tells you what visitors actually experienced.

Step 1: fix your images

This is first because it is the biggest win on most sites and it costs nothing.

Images are typically the majority of a page’s weight. A single uncompressed hero image can outweigh everything else on the page combined.

• Resize before upload. An image displayed at 800 pixels wide does not need to be 4000 pixels wide. This single habit fixes more sites than any plugin.
• Serve WebP or AVIF. Both are substantially smaller than JPEG at equivalent quality and are supported by every current browser.
• Compress. Quality settings around 80 percent are visually indistinguishable for photographs and much smaller.
• Lazy load below-the-fold images. WordPress does this natively now, but check your theme has not disabled it.
• Do not lazy load your LCP image. Lazy loading the main hero image delays the exact thing the metric measures. This is a common and self-defeating mistake.
• Set width and height attributes. Prevents layout shift.

Re-measure after this step. On image-heavy sites the improvement is often large enough to make the rest optional.

Step 2: get on a current PHP version

Newer PHP versions are meaningfully faster than older ones at the same workload, and they receive security patches that older versions do not.

Check your current version under Tools then Site Health in WordPress. If you are more than one major version behind current, this is a free speed improvement waiting to be collected.

Change it from your hosting control panel rather than by support ticket where possible. Before you switch:

1. Take a backup.
2. Test on staging if you have it.
3. Check that your theme and plugins support the target version.

Old, abandoned plugins are the usual blocker. That is itself useful information about what you are running.

While you are there, check your PHP memory limit. 256 MB is a comfortable working figure for a site with a normal plugin load. A low limit causes failures during updates and imports rather than slowness, but it is worth fixing in the same pass. The rest of the specification detail is in our WordPress hosting guide.

Step 3: turn on page caching at server level

This is the largest server-side gain available to a WordPress site.

Without caching, every visitor triggers PHP execution and database queries to build a page that is identical for everyone. With page caching, the server stores the finished HTML and serves it directly.

Server-level caching is faster than a plugin doing the same job, because the request is answered before it reaches PHP at all. If your host offers it, use it and remove any caching plugin doing the same work. Running two page caches simultaneously causes stale content and strange bugs.

If your host does not offer server-level caching, a caching plugin is a reasonable substitute and still a major improvement over nothing.

Two things to configure carefully:

• Exclude the right pages. Cart, checkout, account and any personalised page must never be cached. Ecommerce plugins usually handle this, but verify it.
• Set a sensible expiry. Long enough to be useful, short enough that updates appear.

Step 4: add object caching if your pages are dynamic

Page caching cannot help pages that differ per visitor. Object caching can.

Object caching stores the results of database queries in memory using Redis or Memcached, so repeated queries do not hit the database again. This is what speeds up the WordPress admin area, the cart, the account page, and anything behind a login.

If you run a content site with mostly cacheable pages, the gain is modest. If you run a store, a membership site or a large site with a heavy admin area, it is substantial.

This requires host support. It is one of the features worth checking for when comparing plans, and it is a real distinction between tiers rather than a marketing one.

Step 5: clean up the database

WordPress databases accumulate weight quietly.

• Post revisions. Unlimited by default. A long post can carry dozens.
• Expired transients. Cached data that should have been removed and often is not.
• Orphaned metadata. Left behind by deleted posts and removed plugins.
• Spam and trashed comments.
• Missing indexes. Some plugins create tables without indexing the columns they query.

Back up before any database cleanup, without exception.

The largest single gain is usually limiting revisions going forward rather than deleting what exists. On most sites this step matters less than the first four, but on old sites with years of history it can be significant.

Step 6: reduce and audit plugins

Plugin count is a weak signal. Plugin quality is a strong one. Twenty light plugins can outperform four heavy ones.

Use a query profiler to find the real cost. It will show you which plugin is firing hundreds of database queries per page or loading assets on pages that do not use them.

Then act on what you find:

• Remove plugins you do not use. Deactivated is not removed.
• Replace one heavy plugin rather than five light ones. Page builders, some slider plugins, and related-posts plugins are common offenders.
• Stop plugins loading everywhere. A contact form plugin should not load its assets on every page. Several tools allow conditional loading.
• Check for abandoned plugins. Unmaintained plugins are both a performance and a security problem, which is covered in WordPress security hardening.

Do this on staging. Deactivating plugins on a live site to test is how sites break at lunchtime.

Step 7: handle the front end

By this point the server side is in order. What remains is what the browser does.

• Minify and combine CSS and JavaScript where it helps. With HTTP/2 and HTTP/3, combining matters less than it used to. Minifying still helps.
• Defer non-critical JavaScript so it does not block rendering.
• Limit web fonts. Two weights of one family is usually enough. Self-host them and preload the one used above the fold.
• Audit third-party scripts. Analytics, chat widgets, ad tags and heat mapping tools are frequently the largest remaining cost, and they are the easiest to forget. Each one is a request to someone else’s server on your critical path.
• Add a CDN if your audience is geographically spread.

Third-party scripts deserve particular attention. It is common to optimise a site carefully and then undo the gain with three marketing tags.

When hosting is genuinely the problem

Work through the steps above first. If you have, and the site is still slow, these are the signs the ceiling is the server:

• Time to first byte is consistently high even on a cached page.
• The site is fast at 4am and slow at 8pm.
• Resource faults appear in your control panel.
• The admin area drags while the front end is fine.

Those are diagnostic, and we cover them properly in the signs you have outgrown shared hosting. If the diagnosis holds, moving to a plan with object caching, a higher CPU allowance and server-level page caching will help. Our WordPress hosting plans publish those specifics, and migrating without downtime explains how to move safely.

An honest word about scores

A perfect score in a speed testing tool is not the objective, and chasing one produces bad decisions.

Lab tools measure a simulated load on a simulated connection. Your visitors are real, on varied devices and networks. It is entirely possible to improve a lab score while making the real experience worse, usually by deferring something the page actually needed immediately.

Optimise for field data where you have it. Where you do not, optimise for time to first byte and Largest Contentful Paint on a real page, and treat the overall score as a rough indicator rather than a target.And to be direct about our own interest: most WordPress sites we see are slow because of images and third-party scripts , not because of their hosting plan. Work the list before you buy anything.

Frequently asked questions