The Fastest WordPress Themes, Ranked by What They Send to the Browser

Every speed claim was measured on an empty page

Read the sales pages in a row and the numbers start to rhyme. Astra promises less than 50 KB of resources and a 0.5 second load. Neve quotes 28KB and says a default install loaded in 0.6s. Elementor describes Hello as 6KB in its help center and under 30KB on its product page. Divi's Divi 5 page shows a desktop score of 100. These are vendor figures, and we repeat them only as vendor figures.

Each one describes a theme with nothing in it. No hero photo, no contact form, no builder, no cookie banner, no chat widget. The moment you build a real page, the theme becomes one supplier among several, and often not the biggest. Say a lean theme needs four plugins to give you a sticky header, local fonts, a mega menu and a slider. The theme stayed small. The page did not.

A theme's speed claim is a photo of an empty apartment. Nobody lives there yet.

So the useful question is not which theme is fastest in a vacuum. It is which theme lets you build what you need while adding the least code, and which one gives you switches to remove what you do not use. That is what the ranking below measures. If you want the general theory first, the WordPress performance hub covers how themes feed LCP, CLS and INP.

The four tests behind the ranking

We did not run a shootout and we will not pretend to. Shootouts test demo imports on empty servers, then crown whoever had the lightest demo. Instead, each theme was judged on four traits that hold steady from site to site, using vendor documentation and, where noted, the theme's own source files as of October 2026.

• CSS delivery. Does the theme load one big stylesheet everywhere, or split CSS by component, by block or by page? Does it print settings CSS inline, write it to a cacheable file, or let you choose?
• jQuery dependence. Do the theme's own front-end scripts require jQuery? A jQuery-free theme does not stop a plugin from loading it, but it means the theme is not the reason.
• Builder weight. Is a page builder required, bundled or optional? A builder's CSS, JavaScript and nested markup usually outweigh the theme beneath it.
• Font handling. Can fonts be served from your own domain, preloaded, or skipped entirely? Fonts fetched from a third-party server add connections before text can paint.

Tier one: block themes with nothing to strip out

The leanest starting points are the block themes, because WordPress itself does most of the styling. Twenty Twenty-Four enqueues no front-end stylesheet at all. Its look comes from theme.json, plus one small stylesheet for outline buttons that loads only on pages where a button renders. Its fonts, Inter and Cardo, ship inside the theme as .woff2 files, so no request ever leaves for Google.

Twenty Twenty-Five adds a small style.min.css that WordPress may inline when it is small enough, and bundles Manrope and Fira Code locally. Neither default theme makes any speed claim, which is oddly reassuring. Ollie follows the same pattern with one style.css and per-block stylesheets that load only when their block appears. In our check of the current packages, none of the three enqueues a script of its own. Core blocks such as Navigation bring their own scripts.

The catch is what you give up. There is no drag-and-drop builder, and add one and the advantage is gone. The mobile menu is the core Navigation block, so a WordPress release can change it, as WordPress 7.1 did when Ollie had to patch submenus that opened pre-expanded. Tuning notes live on the Twenty Twenty-Five speed page, the Twenty Twenty-Four speed page and Ollie's.

Tier two: Customizer themes that keep jQuery off the page

These are the themes people mean when they say lightweight. Each generates CSS from your Customizer settings and keeps its own front-end JavaScript free of jQuery, or nearly so. The order within the tier is about what you get without paying.

• [GeneratePress](/wordpress-themes/generatepress). Settings CSS is printed inline by default and cached in the database. Icons are SVG. The External File print method and the Font Library for local fonts both need GP Premium. Tuning order on the GeneratePress speed page.
• [Kadence](/wordpress-themes/kadence). Its stylesheets are split by component (header, content, footer, sidebar). The free Performance panel holds Load Google Fonts Locally with preload and Enable CSS Preload. Only WooCommerce-related scripts declare jQuery.
• [Blocksy](/wordpress-themes/blocksy). Dynamic CSS Output can write a cacheable global.css file, which the vendor recommends. We found no theme script that requires jQuery. Local Google Fonts is a Pro extension, and many features live in the Blocksy Companion plugin.
• [Astra](/wordpress-themes/astra). Settings CSS goes inline by default; CSS file generation is listed as a Pro feature. Load Google Fonts Locally, with preload, sits under Astra > Settings > Performance. One WooCommerce-related script needs jQuery.

Close behind, with fewer published details

Neve offers Enable Local Fonts Hosting free, and it also catches Google Fonts loaded by other plugins. Its main front-end script declares no jQuery dependency in the current package, though Emoji Removal and Lazy Rendering are Pro. OceanWP can write settings CSS to a file and switch off Font Awesome, Simple Line Icons and its lightbox, but its main theme.min.js requires jQuery. Genesis is a framework, so the child theme decides most of the weight; the framework adds responsive menu scripts and a loader that can defer scripts.

Builder themes, where the builder sets the weight

With these, ranking the theme alone misses the point. The builder renders every section, and its CSS, scripts and nesting decide most of what loads. The performance panel is what separates a quick builder site from a slow one.

• [Bricks](/wordpress-themes/bricks) replaces the theme and builder pair with one product. Its front end is vanilla JavaScript with no jQuery, styles are inline by default with optional per-page CSS files, and the Font Manager can download Google Fonts to your server. The vendor's page shows a 98% performance score, its figure, not ours.
• [Hello Elementor](/wordpress-themes/hello-elementor) ships three small static stylesheets (about 5.8KB, 5.8KB and 7.5KB in version 3.5.1), and its settings page can switch all three off. Elementor and Elementor Pro bring the real weight.
• [Divi](/wordpress-themes/divi) has a Performance tab with Dynamic CSS, Critical CSS, Dynamic JavaScript and jQuery deferral, all on by default per the Divi 4 docs. Elegant Themes says Dynamic CSS cut its CSS from 860kb to 54kb. Third-party modules not yet ready for Divi 5 run in a compatibility mode that loads the Divi 4 framework.
• [Avada](/wordpress-themes/avada) offers a CSS compiler, critical CSS, jQuery deferral and a Performance Wizard, then bundles six premium plugins. Its own docs say user content will mostly decide how fast a site runs.
• [Newspaper](/wordpress-themes/newspaper) combines and minifies its JavaScript, but its CSS Analyzer is labeled beta by tagDiv staff and its speed guide leans on outside caching and CDN tools.
• [Hello Biz](/wordpress-themes/hello-biz) documents no performance controls, needs the Hello+ plugin and Elementor, and is headed into maintenance mode.

Builder sites have their own tuning pages: Divi speed, Avada speed, Bricks speed and Hello Elementor speed. For the head-to-head view, see Bricks vs Elementor.

Store themes and the dated stacks

WoodMart is the most performance-minded of the store themes on paper. The vendor says it loads only the CSS and JavaScript each page needs and cuts page size by 2 to 3 times. Its Performance settings include Preload LCP Image and Host Google Fonts locally, and its docs warn against running two lazy-loading systems at once. Flatsome advertises smart lazy loading, and the scores on flatsome.com carry the vendor's own note that they are not a measured audit. Its classic docs say little about jQuery or fonts.

Three themes carry older habits. Storefront is plain and its theme scripts skip jQuery, but it fetches Source Sans Pro from Google's servers and enqueues WooCommerce's cart fragments script, and its maintainers now limit work mostly to critical bugs and compatibility. Sydney loads a Bootstrap stylesheet and can load Font Awesome in two versions, and adds jQuery scripts when its hero slider or Elementor is active. Hestia runs Bootstrap's jQuery-dependent scripts plus a parallax script. Check the Storefront, Sydney and Hestia speed pages before you assume they are slow; settings and discipline still matter more than tier.

Test the shortlist on a page you actually publish

A ranking narrows the field. Your content settles it. Pick two or three themes from the tiers above that can build your layout without a pile of extra plugins, then build the same real page in each on a staging copy: same host, same images, same words, same plugins. Count stylesheets, scripts and font files in the browser's network panel, and run the lab test several times before trusting any score.

Our theme speed test method spells out the fair version, including what to write down and the traps that make demo sites look faster than they are. If the decision is between two specific themes, the comparisons help: GeneratePress vs Blocksy, Kadence vs GeneratePress and Astra vs Kadence. For the vitals themselves, see the best themes for Core Web Vitals.

When even tier one is not quick enough

A tier-one theme on a lean stack can pass Core Web Vitals. It still runs PHP on every uncached request, and every plugin you add later can enqueue files site-wide. If your hero is still the slowest thing on the page, start with fixing slow LCP. If the layout jumps, read theme layout shift.

Past a point, the ceiling is the platform. A Next.js site prerenders pages and serves them from a CDN, self-hosts fonts with next/font and ships less JavaScript through React Server Components. It costs more to build and needs a developer for layout changes, a trade weighed in WordPress vs Next.js speed. If you would rather get the current site fast first, our theme speed optimization service starts by measuring which part of the stack is costing you.