WordPress Themes With the Least CSS and JavaScript, and How to Check Yours

Why stylesheets and scripts cost more than their size

A kilobyte of photograph and a kilobyte of CSS are not equal. The photo downloads alongside everything else and appears when it arrives. A stylesheet in the head blocks rendering: the browser paints nothing until it has the file and has built the style rules. JavaScript is worse on a phone, because after it downloads it must be parsed, compiled and run on a processor far slower than your laptop's, and while it runs the page cannot respond to a tap.

That is why theme code shows up in two Core Web Vitals at once. CSS that blocks rendering pushes back Largest Contentful Paint, explained in WordPress vs Next.js on LCP. Scripts that occupy the main thread delay Interaction to Next Paint, covered in the INP comparison, and both feed the pass or fail in Core Web Vitals compared. Fewer bytes of code is the most direct lever a theme has on both, which is also why the lightweight themes guide treats code bytes as the number that reveals a theme's character.

Inline dynamic CSS against a generated file

Every Customizer theme turns your choices into CSS: the brand color, the heading font, the header height. Where that CSS goes is a real engineering trade, not a matter of taste. Inline CSS travels inside the HTML of every page. It needs no extra request and cannot go stale, but it is downloaded again on every page view because it is part of the document. A generated file costs one request on the first visit, then sits in the browser cache for every page after.

• Astra prints its dynamic CSS inline by default. The current pricing comparison lists CSS File Generation as a Pro feature.
• GeneratePress caches dynamic CSS in the database and embeds it inline by default. Its Dynamic CSS Print Method can switch to an external file, which needs GP Premium. Staff call the file option better, but not by much, when an optimization plugin is running.
• Blocksy offers File or Inline under Dynamic CSS Output, and recommends File.
• Kadence attaches its Customizer CSS inline to the kadence-global stylesheet, while the theme's own CSS is split into component files.
• OceanWP lets you put custom styling in the head or in a dedicated file in uploads.
• Bricks prints styles inline by default; switching CSS Loading Method to External Files writes per-page files and loads a lighter frontend stylesheet.

Files have one failure mode inline CSS lacks: they go stale. When a setting changes and the file is not rebuilt, visitors see the old design. GeneratePress staff note CSS may need regenerating after changes, and Bricks has a Regenerate CSS files button for exactly this. If your edits are not appearing, see CSS changes not showing or the theme pages for Astra and Bricks.

Block themes and the stylesheet that loads only when needed

Block themes have a structural advantage that classic themes have to work for. In a block theme, WordPress loads the stylesheet for a core block only when that block appears on the page. A page with headings, paragraphs and one image does not download the CSS for galleries, tables or quote blocks. Classic themes historically received the whole block library stylesheet on every page, whether the page used two blocks or forty.

Themes can extend the same idea to their own styles with wp_enqueue_block_style(). Twenty Twenty-Four has no main front-end stylesheet at all; its one extra file, for an outline button style, loads only when a button renders. Ollie enqueues a single style.css and registers per-block stylesheets the same way. Twenty Twenty-Five keeps a small stylesheet flagged so WordPress can inline it when it is small enough, saving a request. Most of each theme's design lives in theme.json, which WordPress turns into CSS for the styles actually in use.

The catch is that a block theme only stays lean if plugins behave the same way. A form plugin that enqueues its stylesheet on every URL undoes the advantage on every page that has no form. Read the Twenty Twenty-Five speed page and the Ollie speed page for what each theme still leaves to you.

Who still ships jQuery to visitors

WordPress no longer loads jQuery on the front end unless something asks for it. When a theme asks, the browser downloads jQuery and usually jQuery Migrate before any script that depends on them can run. The library is not enormous, but it is one more blocking dependency on a phone's main thread, and it tends to invite more jQuery plugins after it.

A jQuery-free theme does not guarantee a jQuery-free page. WooCommerce, many slider plugins and older form plugins still request it, and one request is enough to load it everywhere that plugin runs. The theme JavaScript errors guide covers what happens when a deferral setting moves jQuery after a script that needed it first.

Builders pay for flexibility in stylesheets

A visual builder has to be ready to draw any module on any page, so its natural state is to load everything. The serious builders now fight that with per-page loading. Divi's Performance tab, on by default per its Divi 4 documentation, builds a Dynamic CSS stylesheet from the modules a page actually uses, loads JavaScript libraries on demand, and generates Critical CSS. Elegant Themes says Dynamic CSS cut its CSS from 860kb to 54kb.

Avada's Global Options include a CSS compiler, a JavaScript compiler that combines scripts, Critical CSS generation and a Performance Wizard that scans icons and fonts and switches off unused features. WoodMart says it loads only the CSS and JavaScript each page needs. Newspaper has a tagDiv CSS Analyzer for per-page and critical CSS, which its own staff call a beta version suited to simple pages. On Divi 5, third-party modules that are not yet Divi 5-ready run in a backward-compatibility mode that loads the Divi 4 framework, which the vendor says makes pages slower.

These tools work, within limits. They shrink what a builder sends; they cannot remove the builder's wrapper markup or the runtime it needs for animations and interactions. Each builder's speed page covers the settings in order: Divi, Avada, Bricks and WoodMart.

Icon fonts against inline SVG icons

An icon font is a font file in which every letter is a picture. To show a magnifying glass, the browser downloads the whole font plus a stylesheet mapping hundreds of class names to glyphs. Until the font arrives, the icon shows as a blank square or nothing. An inline SVG icon is a few lines of markup in the page itself: it needs no request, carries only the icons used, and draws immediately.

• GeneratePress uses SVG icons by default.
• OceanWP has Performance toggles for Font Awesome, Simple Line Icons and its own Ocean SVG icons, so you can keep only one set.
• Divi has a Dynamic Icons option in its Performance tab, and Avada's Performance Wizard scans which icons are used.
• Hestia enqueues Font Awesome 5 plus a v4 compatibility shim, and Sydney loads Font Awesome 5 and its legacy version.
• Storefront enqueues a separate icons.css alongside its main stylesheet.

If your theme lets you drop an icon font and you use four icons, drop it and replace them with SVG. Watch for plugins that bring their own copy of Font Awesome; it is common to find two versions loading on one page. Fonts in general, icon or text, are covered in theme fonts not loading.

Measuring CSS and JavaScript coverage in Chrome DevTools

You do not need a paid tool to see how much code your theme sends and how much of it runs. Chrome DevTools has everything. Test logged out, or in an incognito window, so the admin bar and editor scripts do not pollute the numbers.

1. 1

   Open the Network panel

   Tick Disable cache, reload, and filter by CSS, then JS. Sort by size. The Initiator column and the file path tell you which theme, builder or plugin requested each file.

2. 2

   Open Coverage

   Press Ctrl+Shift+P (Cmd+Shift+P on a Mac), type Coverage, choose Show Coverage, then click the reload button inside the panel. Each file lists total bytes and unused bytes.

3. 3

   Interact before you judge

   Open the mobile menu, scroll to the footer, hover the dropdowns. Coverage only counts code that ran during your session, so untouched menus look unused.

4. 4

   Measure inline CSS too

   View the page source and find the large style blocks in the head. Inline CSS does not appear as a separate file in the Network panel but still adds to every HTML response.

5. 5

   Compare with a default theme

   On a staging copy, switch to Twenty Twenty-Five and repeat. The difference is the theme's share; whatever remains belongs to plugins.

Treat unused bytes as a lead, not a verdict. Some unused CSS covers other pages, screen sizes or states, and stripping it breaks layouts, which is how automated "remove unused CSS" features cause half the support threads they generate. PageSpeed Insights reports the same evidence as Reduce unused CSS and Reduce unused JavaScript; our PageSpeed Insights guide for themes explains how to read those lines without overreacting.

Where trimming theme code stops paying

Once you have switched off the theme's extras, moved fonts local and cleared out duplicate icon sets, the remaining code mostly belongs to the builder and plugins. Each one loads its own files on its own terms, and the next update can add a script you never asked for. If you are trimming the same pages every quarter, our theme speed optimization team can do one careful pass, or performance consulting can look at the whole stack.

A Next.js build sidesteps the problem instead of managing it. React Server Components render on the server and send no component JavaScript to the browser unless a component needs interactivity, and CSS is split by route at build time. Nothing loads on a page that the page does not use, because nothing gets installed on the live site. The full comparison is at WordPress vs Next.js speed, and the WordPress performance hub covers the rest of the tuning story.