Core Web Vitals for WordPress

WordPress runs a larger share of the web than any other system, from one-person blogs to newsrooms with millions of readers, and the spread in speed is just as wide. The core itself is not slow. What decides whether a WordPress site passes the Core Web Vitals is the theme, the plugins, the hosting and the discipline with images and scripts. This guide uses PerfDelta's own measurements of WordPress sites to show where they typically stand, what slows them down, and which fixes pay off first.

From PerfDelta's measurements: 57% of the 462 measured WordPress websites pass all three Core Web Vitals (all measured websites: 49%). 72% have a good LCP, 89% a good INP and 81% a good CLS. All values, other platforms and regions are in the WordPress speed statistics. More in the data section below.

Where WordPress sites stand

Lab tests and field data tell different stories on WordPress more than on most platforms. Many WordPress sites have a mediocre Lighthouse score because of plugin JavaScript and render-blocking CSS, yet pass the Core Web Vitals with real users, because content sites are mostly read, not interacted with, and their visitors are on reasonable devices. The data section below shows the pass rate and the metric distribution across the WordPress sites we measured, and the WordPress speed statistics page adds page weight, third parties and the most common Lighthouse findings. The same page compares the worldwide figures with Germany, Austria and Switzerland and with the UK.

What typically slows WordPress down

Server response time

WordPress builds every page from PHP and database queries on each request unless something caches the result. On shared hosting without page caching, Time to First Byte alone can eat most of the LCP budget. This is the most common cause of a poor LCP on WordPress and the cheapest to fix.

Plugins that load everything everywhere

A contact form plugin loads its CSS and JavaScript on every page, not just the contact page. A slider plugin, a social sharing plugin, a related posts plugin and a page builder each do the same. The result is a dozen stylesheets and scripts on a plain article, most of them render-blocking and most of them unused on that page.

Page builders and DOM size

Visual builders wrap every block in several layers of containers and ship a large CSS framework to style them. The DOM grows, style and layout work grows with it, and interactions slow down.

Unoptimized images

WordPress generates several sizes of each upload and serves WebP in recent versions, but themes that use the full-size image for a 400-pixel thumbnail, hero images uploaded at camera resolution, and galleries without lazy loading remain everyday findings. See properly size images and next-gen formats.

Fonts and third-party tags

Themes that load Google Fonts in several weights, plus analytics, ads and consent tools added by plugins, make up the remainder. The third-party code guide covers the audit; the font-display guide covers the fonts.

Fixes in order of impact

1. Enable full-page caching. Either through the host (most managed WordPress hosts do this at the server level) or a caching plugin. This turns a slow PHP render into a static file read and usually moves TTFB from over a second to a few hundred milliseconds. Pair it with an object cache if the site is dynamic.
2. Serve images correctly. Confirm that themes use srcset sizes, enable WebP or AVIF generation, lazy-load everything below the fold and give the hero image fetchpriority="high". An image optimization plugin or an image CDN handles most of this.
3. Remove and restrict plugins. Delete what is unused. For the rest, use an asset manager or the plugin's own settings to load scripts and styles only on the pages that need them. Watch the plugin count: each one is a maintenance and performance liability.
4. Deal with render-blocking CSS and JavaScript. Defer non-critical JavaScript, generate critical CSS for the templates that matter, and load the rest asynchronously. Caching plugins offer this; test each option, because deferring the wrong script breaks sliders and forms.
5. Self-host fonts with font-display: swap. Download the font files, add them to the theme, remove the Google Fonts request, and limit weights to two or three.
6. Review the theme. A block theme or a lean classic theme with modern CSS produces a smaller DOM and less CSS than a multipurpose theme with a builder. Switching themes is a project, but it is the step that fixes DOM size and unused CSS at the root.
7. Upgrade hosting if the server is the bottleneck. If TTFB stays high with caching enabled, the server is undersized or far from the audience. Managed WordPress hosting with a CDN in front solves both.

Measuring the result

Test the home page and the main template types (article, category, product if WooCommerce) separately; a fast home page with a slow article template is a common pattern. Lab scores respond immediately; the Core Web Vitals in the field follow over the 28-day Chrome UX Report window. PerfDelta's monitoring tracks both per URL, with the industry and platform medians next to them.

Frequently asked questions

Which caching plugin is best for Core Web Vitals?

The one your host supports and you can configure. Server-level caching from a managed host is usually faster than any plugin. Among plugins, the differences in page caching are small; the differences in how they handle CSS and JavaScript deferral are larger, so test those options on your templates.

Do page builders always hurt performance?

They add markup and CSS, so a builder site starts with a handicap. Modern builders with an "optimized output" mode and a disciplined use of blocks can still pass the Core Web Vitals. Block-based themes without a builder are the leaner starting point.

How many plugins are too many?

There is no fixed number; one badly written plugin can cost more than twenty light ones. Judge by what each plugin loads on the front end, which the Lighthouse findings and the Network panel show by file.

Does WooCommerce change the picture?

Yes. Shop pages carry cart fragments, more JavaScript and more images, and the cart and checkout must stay dynamic. Caching rules get more complex and INP becomes the metric to watch. The fixes above still apply, with extra attention to third-party apps and payment widgets.