WordPress speed checklist

1. Before you start

• Open Site Health: Tools, then Site Health, then the Status tab. Write down everything marked critical or recommended. See WordPress hosting for speed.
• Test your two most important pages on the mobile tab of PageSpeed Insights. Write down the real-visitor numbers, the lab numbers and the server response time.
• Time a cached page and an uncached one. A cached page is one a logged-out visitor sees. An uncached one is a search result page, or a page while you are logged in. The gap between them shows where the work is.
• Take a full backup, and make a staging copy if the host offers one. See how to test speed changes safely.
• List the theme and every plugin, with what each is for and who uses it.

2. Host and PHP

• Move to the PHP version Site Health recommends, after testing on the staging copy. Older plugins and themes may not work on a newer version.
• Check that an opcode cache is on. Recent versions of Site Health test for it. Otherwise ask the host.
• Check the page cache test in Site Health, and confirm it yourself with the response headers. See WordPress caching.
• Ask about a persistent object cache (Redis or Memcached) if the site is busy or dynamic.
• Look at the server response time. Site Health uses a median of 600 milliseconds as its threshold. Aim well below it for cached pages. See server response time.
• If the site slows only at busy times, ask the host which resource limit you reach: memory, processes or disk input and output.
• Check that the loopback and scheduled event tests pass. WordPress runs its scheduled tasks by calling itself.
• Add a CDN if visitors are far from the server. See what is a CDN.

3. Page cache

• Run one caching solution, the host's or one plugin. Two do the same job and fight each other.
• Exclude the cart, checkout and account pages, and anything else that is personal.
• Check that publishing or updating a page clears its cache.
• Check that an address with tracking parameters still gets the cached copy.
• Look at a response header that shows a cache hit, and watch the server response time fall.
• Test as a logged-out and a logged-in visitor. Many caches do not apply to logged-in users.

4. Theme and page builder

• Try a default theme on staging and test again. A big jump in speed means your theme is a large part of the problem.
• Switch off the theme features you do not use, such as sliders, extra icon sets and animations.
• If you use a page builder, keep the pages simple, avoid stacking widgets and look for its performance settings. See Elementor and page builders.
• Keep heavy things off the top of the page: auto-playing video, sliders and parallax. They are a usual reason for a poor LCP.

5. Plugins

• Delete the plugins nobody needs. An inactive plugin does not run, but it can still be a risk.
• Find the heavy ones. On staging, switch plugins off one at a time and test, or use Query Monitor to see which plugin runs which queries, scripts and requests.
• Check where each plugin loads its files. A form plugin that loads on every page when the form is on one is a common find. Many have a setting to load only where needed.
• Remove duplicates: two sliders, two SEO plugins, two backup plugins.
• Replace the worst offenders with a lighter plugin or a few lines of code. See themes and plugins.
• Switch on optimization features one at a time. A plugin that combines, delays and rewrites scripts can break pages. Test like a visitor after each.
• Look before removing jQuery. Many plugins depend on it. See removing jQuery.

6. Images

• Resize before you upload, to about twice the largest size the image is shown. WordPress scales down uploads over 2,560 pixels by default.
• Use WebP or AVIF. Convert on upload with a plugin, or let the host or CDN do it. See WordPress image optimization.
• View the page source for the top image. It should be a normal img without loading="lazy", ideally with fetchpriority="high". Sliders and page builders often break this.
• Check images that the theme adds itself. The editor adds srcset and sizes automatically, and theme code may skip them.
• Make sure every image has `width` and `height`. WordPress needs them to mark the first large image as high priority.
• Do not use a huge picture as a CSS background when an img would do.
• Give video a poster, and put a facade in front of an embed. See video and speed.

7. Scripts, styles and fonts

• Defer the scripts your own theme loads. WordPress lets themes and plugins register a script with a defer or async strategy.
• Remove unused scripts and styles, page by page. Test every one.
• Do not combine every file by default. On HTTP/2 and HTTP/3 the number of files matters much less, and combining can hurt caching. Check the protocol first: on HTTP/1.1 it still matters. See the Speed Lab test.
• Limit the fonts, and serve WOFF2 files from your own domain. See web fonts and speed.
• Review third-party scripts: analytics, chat, ads and embeds. See third-party scripts.
• Know what speculative loading does. Since WordPress 6.8 it can prefetch or prerender links for logged-out visitors on sites with pretty permalinks. See speculation rules.

8. Database and background work

• Check autoloaded options in Site Health. The test reports a problem when they reach 800,000 bytes. See database cleanup.
• Find the owner of the large ones before deleting anything.
• Cap the number of revisions kept, and empty the trash and spam.
• Clear expired transients, and look for tables left by plugins you removed. Do not delete a table you cannot identify.
• On a busy site, run WP-Cron from a server-level scheduled job instead of from visits.
• Back up before, and test after.

9. If you run WooCommerce

• Cache the shop, category and product pages for logged-out visitors, and leave the cart, checkout and account pages uncached. See WooCommerce speed.
• Check that a price or stock change clears the right pages.
• Turn on a persistent object cache. A store repeats many database queries.
• Take WooCommerce files off pages that are not part of the store, with care. Test the cart and checkout afterwards.
• Look for a redirect on the first visit. The location setting that supports page caching can send the first visit through a 307 redirect. Check the Network panel.
• Before changing order storage, check that your plugins support it, test on a copy and back up.
• Keep the checkout quiet: drop fields you do not need, remove chat and pop-ups, offer the payment methods your customers use, and exclude it from speculative loading. See WooCommerce checkout speed.
• Run a test purchase from the product page to the confirmation after every change.

10. Keep it fast

• Test again after each change, and compare the real-visitor numbers after 28 days.
• Check your top pages once a month, and after every plugin or theme update.
• Keep a short record of what you changed and what the numbers were. See why websites get slower over time.

Mistakes to avoid

• Installing five optimization plugins. Each one changes things the others touch.
• Delaying all JavaScript until the first tap without testing the first tap, the cart and the payment button.
• Editing the live site without a backup.
• Working on images while the server is slow.
• Cleaning the database first. It rarely changes the front end, and it is the riskiest step.
• Aiming for a perfect score. The goal is real visitors who pass the Core Web Vitals.

Check your own page

Run the free audit on your home page and see how large the server response is next to everything else. A big first byte points to groups 2 and 3. A small one points to groups 6 and 7.

Sources

• The WordPress Advanced Administration Handbook, Optimization: the factors that affect performance, caching and the server environment.
• WordPress core: media.php and speculative-loading.php: lazy loading, fetchpriority, srcset and the large-image threshold, and speculative loading.
• The WordPress and WooCommerce guides on this site, which carry the sources for each line.