How to speed up a WordPress website, step by step

Why WordPress sites get slow

WordPress is built to be flexible, and every bit of flexibility costs work. For each visit, the server runs PHP code from WordPress, your theme and every active plugin, asks the database many questions, builds the page and sends it. The browser then loads whatever the theme and plugins add: stylesheets, scripts, fonts, images. Nothing in that chain is slow by design, but all of it adds up as a site grows.

Three facts explain most of what follows:

• WordPress does not cache finished pages. It provides a hook for a page cache and an object cache, but you, your host or a plugin have to supply them. A site without one rebuilds every page on every visit.
• Plugins and themes decide most of the front-end cost. The number of plugins matters less than what each one loads and runs, and on which pages.
• Defaults help, but only if nothing overrides them. Core adds lazy loading, sizes and image priorities for you, and a theme or page builder can undo them.

For what the 2025 data says about WordPress sites as a group, see is WordPress slow?

Step 0: measure before you touch anything

Run your home page and your most important page through PageSpeed Insights on the mobile tab. Write down:

• the real-visitor Core Web Vitals and which one fails;
• the lab values for LCP, TBT and CLS;
• the server response time and the page's size.

Then take a full backup, and do the work on a staging copy if your host offers one. Without numbers you will not know what helped, and without a backup one wrong change can cost you the site.

Step 1: hosting and PHP

Everything starts with the server's answer. If the first byte takes more than about 600 milliseconds, the host is the limit. Read choosing hosting for speed, and at minimum check these:

• A supported PHP version. WordPress runs on old PHP versions that PHP itself no longer supports, and newer versions are usually faster. Your host's control panel shows and changes the version. Check the list of supported versions on the PHP website, switch on staging first, and test.
• Enough memory and workers for your traffic.
• A server-level page cache. Many managed WordPress hosts include one.
• A CDN if your visitors are far from the server (see what a CDN is).

Step 2: add a page cache

Because core does not cache pages, the single biggest change for most slow sites is adding a cache. Core provides the mechanism: a drop-in file in the content folder that WordPress loads very early when caching is switched on, which is how caching plugins work. Use the cache your host provides if it has one. Otherwise use one well-maintained caching plugin, not two: two plugins doing the same job fight each other.

What to look for, and to set:

• Pages are served to logged-out visitors from a saved copy.
• The cart, checkout and account pages are excluded, along with anything that is personal.
• The cache is cleared automatically when you publish or update a page.
• Pages with tracking parameters in the address still use the cached copy.
• The cache can be warmed up after a clear, so the first visitor does not pay for it.

Check that it works: reload a page and look at the response headers in DevTools for the cache's header, and watch the server response time fall. Then check what logged-in visitors see, because many caches do not apply to them.

For a dynamic site, such as a store or a membership site, also add an object cache. It keeps the results of database queries in memory, and WordPress loads it from a drop-in file when one is present. Ask your host whether Redis or Memcached is available.

Read caching explained for the layers and what each one does.

Step 3: look at the theme and any page builder

A theme decides the markup, the CSS and the JavaScript on every page.

• Test the theme. Switch temporarily to a default theme on staging and run the test again. If the speed jumps, the theme is a big part of the problem.
• Prefer a light, well-built theme over one that bundles dozens of features, sliders and fonts you do not use. Turn off the features you do not need in its settings.
• Page builders add weight. Each builder loads its own CSS and JavaScript, often on every page, and wraps content in many extra elements. They are a trade: easier editing against a heavier page. If you use one, keep pages simple, avoid stacking widgets and animations, and look for its performance settings.
• Avoid heavy elements at the top of the page: auto-playing video, sliders, parallax. They are the usual reason for a poor LCP.

Step 4: audit the plugins

The number of plugins is not the measure. Their cost is.

1. List them and write down what each one does and who needs it.
2. Delete what is not used. An inactive plugin does not run, but it can still be a risk, so remove it.
3. Find the heavy ones. On staging, switch plugins off one at a time and test the page, or use a debugging plugin such as Query Monitor to see which plugin runs which queries, scripts and requests on a page.
4. Check what each loads where. A contact form plugin that loads its scripts and styles on every page, though the form is on one, is a common find. Many plugins have a setting to load assets only where needed.
5. Replace the worst offenders with lighter ones, or with a few lines of code. Many plugins depend on jQuery, which WordPress then loads on that page; see removing jQuery and other legacy libraries before you try to change that.
6. Avoid duplicates. Two slider plugins, two SEO plugins, two backup plugins.

Be careful with optimization plugins that promise everything: one that combines, delays and rewrites scripts and styles can break pages. Turn on one feature at a time, and test the site like a visitor after each.

Step 5: images

Images are usually the biggest part of a page. WordPress helps with several defaults, and a theme or builder can override them:

• Images added through the editor get srcset and sizes automatically, so the browser can choose a size.
• Uploaded images wider or taller than 2,560 pixels are scaled down by default.
• Uploaded JPEGs are re-saved at a quality of 82 by default.
• WordPress supports WebP and AVIF files.
• Images get loading="lazy", except the first few in the content. Since version 6.3, WordPress also gives the first large image fetchpriority="high" when it has its width and height set.

What you still have to do:

• Upload at the right size. A photo from a phone can be 4,000 pixels wide; resize it before uploading to about twice the largest size it will be shown.
• Use WebP or AVIF. Convert on upload with a plugin or let your host or CDN do it. See image optimization.
• Check the top image. In the page's source, make sure the image at the top is a normal <img> without loading="lazy", ideally with fetchpriority="high". Sliders and page builders often break this.
• Do not use a huge image as a CSS background when a normal image would do.

Step 6: scripts, styles and fonts

• Defer what can wait. Modern WordPress lets themes and plugins register scripts with a defer or async strategy. You can add it for scripts that your own theme loads, and some plugins have an option for theirs.
• Remove unused scripts and styles page by page, for features a page does not use. This needs care, so test each one.
• Do not combine everything by default. On HTTP/2 and HTTP/3 the number of files matters much less, and combining can hurt caching. On HTTP/1.1 it still matters, so check the protocol first. See the Speed Lab test of many small files.
• Limit the fonts, as in web fonts and speed, and serve them from your own domain.
• Review the third-party scripts: analytics, chat, ads and embeds. See third-party scripts. They are the most common reason for a poor INP on a WordPress site.
• Speculative loading. Since version 6.8, WordPress can prefetch or prerender links a visitor is likely to click, for logged-out visitors on sites with pretty permalinks. It is on by default, and some plugins can change it. See speculation rules for what it does and how to change it.

Step 7: the database and background work

This is the last step for a reason: it rarely changes the front end, and it needs a backup.

• Autoloaded options. WordPress loads options marked to autoload on every request. Plugins that you removed years ago sometimes leave large ones behind. If your site has hundreds of kilobytes of autoloaded data, clean it.
• Revisions, spam comments and expired transients can be cleared. Limit the number of revisions kept.
• WP-Cron. Scheduled tasks are started by visits to the site. On busy or heavy sites, move them to a real scheduled job at the server level.

Step 8: a CDN and compression

A CDN serves your images, scripts and styles, and possibly the cached HTML, from locations close to visitors. Make sure compression (Brotli or gzip) is on for text files, as described in text compression. Most managed hosts and CDNs do both. If the server itself is slow to answer, see how to reduce server response time.

A quick diagnosis

What not to do

• Install five optimization plugins. Each one changes things the others touch.
• Delay all JavaScript until the first tap without testing the first tap.
• Edit the live site without a backup or a staging copy.
• Chase a score of 100. Pass the Core Web Vitals for real visitors, and stop when the report is green and the real numbers are good.
• Fix the front end while the server is slow.

Keep it fast

Speed slips. Every new plugin, script and large image makes it a little worse. Test your top pages once a month, and every time you add a plugin or change the theme. Keep a short record of what you changed and what the numbers were.

Check your own page

Run the free audit on your home page and your most important page. Compare the server response time with the rest of the load: if the first byte is the biggest part, start at Step 1 and Step 2. If it is small, start with the main image and the scripts.

Sources

• WordPress core: media.php: lazy loading, fetchpriority, srcset and the large-image threshold.
• WordPress core: speculative-loading.php: how speculative loading is configured.
• WordPress core: wp-settings.php and load.php: the cache drop-ins.
• Optimize Time to First Byte on web.dev: hosting, CDN and caching.