WordPress carries a large share of the web, yet that alone makes nothing fast. In the HTTP Archive Web Almanac, only 40 percent (HTTP Archive Web Almanac) of mobile WordPress sites passed all three Core Web Vitals together in 2024, a clear step up from 28 percent (HTTP Archive Web Almanac) the year before and still far from a good baseline. On WordPress the causes are usually the same recurring ones: a page builder that bloats the markup, a growing pile of plugins with unused assets, a database filling up with revisions, transients and autoloaded options, a missing persistent object cache, and an image that is too heavy in the visible area. This article walks through the most common brakes one by one and shows which built-in means and which order resolve each of them, without rebuilding the system.
How Many WordPress Sites Are Actually Fast
A look at the field data frames the problem. WordPress ran on around 36 percent (HTTP Archive Web Almanac) of the mobile sites analyzed in 2024, making it by far the most widespread CMS. At the same time, only 40 percent (HTTP Archive Web Almanac) of those sites passed all three Core Web Vitals on mobile, up from 28 percent (HTTP Archive Web Almanac) a year earlier. Where it snags is telling: Cumulative Layout Shift reached 82 percent (HTTP Archive Web Almanac) and Interaction to Next Paint 82 percent (HTTP Archive Web Almanac), the latter a jump from 69 percent (HTTP Archive Web Almanac). The bottleneck is loading performance: Largest Contentful Paint also passed on only about 40 percent (HTTP Archive Web Almanac). Right there, at the first large visible element, the perceived speed of a WordPress site is decided.
The weight explains it. The median mobile WordPress page weighed 2,047 KB (HTTP Archive Web Almanac) in 2024, of which 725 KB (HTTP Archive Web Almanac) were images and 528 KB (HTTP Archive Web Almanac) JavaScript. That is not a law of nature but the sum of many small decisions: a heavy theme, a page builder, a handful of plugins, uncompressed images. Each of these layers can be relieved individually. The link to the Core Web Vitals is direct, because a lighter, earlier-rendered above-the-fold improves LCP immediately, and the order of the measures decides how much effect comes from how little effort.
The Three Thresholds at a Glance
Page Builder and Theme Overhead
The first brake sits deep in how the page is built. A large share of WordPress sites uses a page builder; the most widespread ran on 56 percent (HTTP Archive Web Almanac) of mobile WordPress sites in 2024. Page builders are convenient, but they often produce deeply nested markup with many wrapper elements, load generic CSS and JavaScript bundles for features a given page does not need, and thereby inflate the DOM. A large DOM slows both the first render and later interactions, hitting LCP and INP at once. The same applies to bloated themes that ship sliders, icon libraries and font variants that never get used.
Flatter Markup
Less nesting lowers the DOM size. Where a builder creates five wrappers for a simple section, one or two often suffice, which speeds up rendering and interaction.
Critical CSS First
Only the CSS needed for the visible area belongs inline in the head, the rest loads afterward. That way the browser starts painting earlier instead of waiting for one large stylesheet.
No Blocking Up Top
Render-blocking scripts and fonts in the head delay the first paint. Defer, async loading and a sensible font fallback keep the above-the-fold free of waiting time.
The most effective step is choosing a lean, current theme and deliberately skipping a page builder where standard blocks suffice. Where a builder stays, it helps to disable unused modules and to check the generated assets per page. How strongly an oversized DOM weighs on performance is covered by the article on reducing DOM size; how critical CSS speeds up the first render is shown by the piece on critical CSS above the fold.
Plugin Sprawl and Unused Assets
Every active plugin may enqueue CSS and JavaScript into the page, and many do so globally, even where their function is not needed. A form plugin loads its scripts on every page, a slider plugin on every subpage without a slider. This is how the median 528 KB (HTTP Archive Web Almanac) of JavaScript that a WordPress page delivers on mobile adds up. The official WordPress optimization guide names the first step plainly: deactivate and delete unnecessary plugins (WordPress.org Documentation). What remains should enqueue its assets only where they take effect.
Dequeue Assets Selectively
- Consolidate duplicate functions: several plugins for the same task cause duplicate scripts and conflicts.
- Load assets conditionally: enqueue handles via hooks only on the pages that truly need them.
- Question external scripts: embedded widgets and trackers pull in connections to third parties.
- Remove orphaned leftovers: deactivated plugins often leave behind tables, options and scheduled tasks.
A large part of the ballast also comes from embedded third-party scripts that do not stem from your own code. How to trim and defer such embeds is covered by the article on trimming third-party scripts; how a fixed JavaScript budget keeps the sprawl in check for good is shown by the piece on JavaScript performance budgets. The principle holds: every kilobyte not loaded also does not need to be parsed and executed.
Database Bloat: Revisions, Transients, autoload
The database is the quietest brake because it grows invisibly during operation. Three sources drive the ballast: post revisions that WordPress creates on every save, expired transients meant as temporary storage but left lying around, and above all the autoloaded options in the wp_options table. These autoloaded options are loaded in full on every single page view, regardless of whether the current page needs them. WordPress explicitly recommends keeping the autoloaded options under 800 KB (WordPress.org Documentation), because too many automatically loaded options slow the site down. Plugins that permanently store large amounts of data there burden every request.
// Limit the number of revisions stored per post
define( 'WP_POST_REVISIONS', 5 );
// Empty the trash automatically after 7 days
define( 'EMPTY_TRASH_DAYS', 7 );The cleanup has two parts. First you limit further growth, for example via a fixed cap on revisions and an automatic trash. Then you remove the accumulated ballast: expired transients, old revisions and orphaned metadata. It matters to check the size of the autoloaded options afterward and to switch individual outliers to non-autoload in a targeted way, instead of deleting wholesale. How to further speed up slow queries with indexes and by resolving expensive query patterns is described in the article on database query optimization.
| Database Brake | Effect | Countermeasure |
|---|---|---|
| Post revisions | wp_posts grows on every save | cap WP_POST_REVISIONS, remove old ones |
| Expired transients | orphaned rows in wp_options | delete expired transients regularly |
| Large autoloaded options | loaded on every request | keep under 800 KB, switch outliers |
| Orphaned metadata | unnecessary links and rows | clean up after plugin uninstall |
Object Cache and Persistent Caching
WordPress has a built-in object cache, but by default it is not persistent: it keeps data in memory only for the duration of a single request and discards it afterward (WordPress.org Documentation). So on every page view the cache starts from scratch, and the same options, metadata and query results are fetched from the database again and again. This is exactly where a persistent object cache comes in. It keeps the results in memory across requests and thereby saves the repeated trips to the database. WordPress states the effect directly: a persistent object cache shortens response times such as Time to First Byte and protects the database during traffic spikes (WordPress.org Documentation).
Separate Object Cache and Page Cache
The page cache is the second lever. WordPress describes that a page cache stores posts and pages as static files and can reduce server load for largely static pages many times over (WordPress.org Documentation). For guest traffic this is the single most effective measure, because a request then neither runs PHP nor touches the database. How reverse proxy and in-memory store work together at the infrastructure level is covered by the article on caching strategies; the matching server optimization and the targeted lowering of TTFB keep the response time low for good.
Caching Does Not Replace Cleanup
Images and LCP Above the Fold
With a median of 725 KB (HTTP Archive Web Almanac), images are the single largest weight item on a WordPress page and at the same time the most common reason for a poor LCP. On most pages the largest visible element is an image, such as the featured image or the hero motif. Three levers decide here: the format, the size and the loading priority. Modern formats like WebP and AVIF deliver much smaller files at the same quality, precisely scaled variants prevent a huge image from being loaded into a small frame, and the right priority ensures the decisive image comes first.
WebP and AVIF
Modern formats noticeably lower image weight at the same quality. WordPress generates matching sizes from every upload, which can additionally be brought into a modern format.
fetchpriority for the LCP Image
The one important image in the visible area gets fetchpriority=high so the browser prioritizes it. That shortens the delay until the largest element loads.
No Lazy Load Up Top
Images below the fold load lazily, but the LCP image does not. A lazy-loaded hero image pushes LCP back because the browser requests it too late.
In practice this means: below the visible area native lazy loading applies, in the visible area exactly one image gets high priority and loads immediately. How to further reduce image weight with modern formats is shown by the article on image optimization with WebP and AVIF; how priority hints speed up the LCP image is covered by the piece on fetchpriority and priority hints. A structured image optimization bundles these steps, and the article on the Core Web Vitals 2026 places their effect on the metrics in context.
The Order of Levers and Staying Fast
The individual measures work best in the right order. First comes the baseline: a lean theme, pruned plugins and a tidy database make the cold request fast. Then a persistent object cache together with a page cache lowers the response time for the bulk of requests. Only after that is the frontend fine-tuning worthwhile, meaning image formats, loading priorities and critical CSS. Reversing this order and starting with caching masks the problems without solving them, and hits the old wall again immediately for logged-in users or cache misses. A sound performance analysis measures up front which page type loses the most time, so effort flows to where it moves the most.
The principle extends beyond WordPress. Anyone running an online shop finds the matching server-side levers in the article on Shopware performance; how strongly the choice of server and hosting predetermines the response time is shown by the piece on choosing hosting and server load time. And because Time to First Byte sets the starting point for all frontend metrics, the targeted monitoring of TTFB as server response time remains the foundation on which the WordPress-specific measures build. Our bundled WordPress performance service implements exactly this order.
The fastest WordPress site does not come from one more plugin but from leaving things out: less theme, fewer scripts, a lean database and a cache that builds on a clean baseline. In that order, every step takes effect.