WordPress speed optimization checklist (with Core Web Vitals)

This WordPress speed optimization checklist is the list I go through in audits, in the order I go through it. It has six parts: measurement, server, caching, database, front end and third parties, then a short section on keeping the site fast. Each item is a yes or no question you can check on your own site. Work from the top, because the server and cache items set the floor for everything below them. The checklist doubles as a Core Web Vitals checklist: every item maps to TTFB, LCP, INP or CLS, and the goal is to pass all three Core Web Vitals in field data, not to hit a lab score.

A checklist tells you what to check. It doesn’t tell you why the order matters or how to fix each item in depth. For that, read the engineer’s guide to speeding up WordPress. If you don’t yet know what is slow on your site, start with how to find why your WordPress site is slow and come back.

Before you change anything: measurement

1. Do you have field data? Check the Core Web Vitals report in Search Console and the field data block in PageSpeed Insights.
2. Do you know which metric fails? LCP good is 2.5 s or less, INP 200 ms or less, CLS 0.1 or less, all at the 75th percentile.
3. Have you tested one URL per template (home, post, page, archive, product, category, cart, checkout), not just the home page?
4. Did you write down a baseline for each template, including TTFB?
5. Is there a staging copy where you can test risky changes?

The tools for each of these, and what each one is good at, are compared in Core Web Vitals tools. Keep in mind that CrUX is a 28-day rolling window, so field data will lag your changes by about four weeks.

Server and hosting

1. Is the site on a PHP version that is still supported?
2. Is OPcache enabled, with enough memory that it isn’t constantly evicting scripts?
3. Does the plan have enough PHP workers for your uncached traffic (logged-in users, carts, search)?
4. Is the server, or a CDN, close to most of your visitors?
5. Is HTTP/2 or HTTP/3 enabled, along with Brotli or gzip compression?
6. Do you have access to error logs and the PHP slow log?
7. Is uncached TTFB on simple pages reasonable, ideally well under the 0.8 s that web.dev rates as good for TTFB overall?

The server items are covered in depth in PHP-FPM and OPcache tuning for WordPress and in the TTFB guide.

Caching

1. Is there a page cache, and do repeated anonymous requests show a cache HIT in the response headers?
2. Do your main landing pages still hit the cache with campaign parameters such as utm_source?
3. Are there cookies set for every visitor that make the cache bypass?
4. Is there only one page cache layer in charge, or are a plugin and a host cache fighting?
5. Does purging clear only what changed, rather than the whole cache on every edit?
6. Is there a persistent object cache (Redis or Memcached) for logged-in, cart and admin requests?
7. Are static files served from a CDN with long cache lifetimes?
8. Does WordPress Site Health (Tools, Site Health) stop warning about the page cache?

Which layers you actually need depends on the site: page cache, object cache, edge cache explains how to decide. For the plugin side, see best WordPress caching plugins.

Database

1. Is the total size of autoloaded options small? Since WordPress 6.6, Site Health warns when it isn’t.
2. Do you know which plugin owns each of the largest autoloaded options?
3. Have you removed leftover options and tables from plugins that are no longer installed?
4. Are expired transients being cleaned?
5. Are post revisions limited with WP_POST_REVISIONS?
6. Does Query Monitor show any slow or duplicated queries on your main templates?
7. On a busy site, is WP-Cron disabled for visitor requests (DISABLE_WP_CRON) and run by a system cron instead?
8. On WooCommerce, is the store using High-Performance Order Storage?

How to do each of these safely, with WP-CLI, is in WordPress database optimization.

Front end: LCP

1. Do you know the LCP element on each template?
2. Is that element free of lazy loading?
3. Does the LCP image have fetchpriority="high"? WordPress 6.3 and later adds it automatically to the image it judges most likely to be the LCP; check that your theme didn’t remove it.
4. Is the image served at the size of its slot, using srcset?
5. Are images in WebP (supported in uploads since WordPress 5.8) or AVIF (since 6.5)?
6. Is the hero free of sliders and entrance animations that delay it?
7. Is render-blocking CSS limited to what the first screen needs?

Details in LCP in WordPress.

Front end: INP and JavaScript

1. Do non-essential scripts load with defer or async? WordPress 6.3 added loading strategies to script registration.
2. Are plugins loading their JavaScript only on the pages that use it?
3. Have you removed scripts that do something CSS can do (simple toggles, animations, sticky headers)?
4. Is the DOM size reasonable, especially on builder pages?
5. If you use a “delay JavaScript” option, have you checked that menus, search and add-to-cart still respond fast on the first tap?

Details in INP in WordPress. If the site is built with Elementor, how to speed up Elementor has builder-specific checks.

Front end: CLS and fonts

1. Do all images, videos and iframes have width and height, or a reserved aspect ratio?
2. Do ad slots, banners and embeds have space reserved before they load?
3. Does the cookie or consent bar overlay the page instead of pushing it down?
4. Are fonts self-hosted, limited to the weights you use, and set with font-display?
5. Is the font used in the LCP text preloaded, if there is one?

Details in CLS in WordPress.

Third-party scripts

1. Do you have a list of every third-party tag the site loads?
2. Does each one have an owner who uses its data?
3. Have you removed the ones nobody can justify?
4. Do chat, video and social embeds load only after interaction or when they scroll into view?
5. Does adding a new tag require a review, or can anyone add one through the tag manager?

WooCommerce extras

1. Do product and category pages pass LCP in field data?
2. Is the cart fragments request running only where it’s needed?
3. Is there a persistent object cache?
4. Are order screens and reports in wp-admin fast enough for the team?

The store-specific work is in WooCommerce speed optimization.

Keeping the site fast

1. Do you recheck field data a month after each round of changes?
2. Is there real user monitoring, or at least a regular look at Search Console?
3. Does a new plugin get tested for performance before it goes live?
4. Are WordPress core, PHP and plugins kept up to date?
5. Do you recheck autoloaded data and slow queries a few times a year?

Which items on a WordPress speed optimization checklist matter most?

If you only have time for a few, do these: confirm the page cache is actually hit, add a persistent object cache on sites with logged-in traffic, trim autoloaded options, fix the LCP image on your main templates, and remove third-party tags nobody uses. In my audits those five cover a large share of the problems. The rest of the list is how you get from “mostly fine” to passing on every template.

Want this done for you?

If you would rather have someone go through the checklist with field data, rank what matters on your site and write up the fixes, that is my WordPress performance audit. For ongoing performance work, see how I work as a WordPress performance specialist.