You optimize your critical CSS, your Core Web Vitals scores improve, and everything looks great — until a visitor opens your mobile menu and it renders as an unstyled list of links stacked in the corner of the screen. Or they click a tab and the content underneath jumps and flashes before settling into place. Nothing is “broken” in the traditional sense. The CSS optimization simply never knew those styles existed.

This is one of the most common — and most misunderstood — pitfalls in critical CSS optimization. Let’s look at why it happens and what it takes to actually solve it.

A quick refresher: what critical CSS is trying to do

Critical CSS (sometimes called “above-the-fold CSS”) is a performance technique. Instead of making the browser download and parse your entire stylesheet before it can paint anything, you extract just the CSS needed to render the visible portion of the page immediately. That small chunk gets inlined directly into the HTML. Everything else — the styles for content further down the page, hover effects, modals, and so on — loads afterward, without blocking the first paint.

Done well, this can meaningfully improve metrics like LCP (Largest Contentful Paint — the moment the biggest visible element finishes rendering) and other Core Web Vitals that Google uses to judge page experience.

The catch is in that phrase “the CSS needed to render the page.” Needed when? At the exact instant the HTML arrives from the server — before a single line of JavaScript has run.

The problem: your page keeps changing after it loads

Modern WordPress themes and plugins lean heavily on JavaScript to add interactivity. Almost none of it is present in the raw HTML your server sends out. Instead, it gets added to the page dynamically, usually by attaching or removing CSS classes:

• A mobile menu toggle adds a class like .is-open or .menu-active when tapped.
• A slider or carousel plugin adds .slick-active, .swiper-slide-active, or similar classes to mark the current slide.
• A sticky header adds a .is-sticky or .scrolled class once you scroll past a certain point.
• A modal or lightbox adds .modal-open to the body and reveals a hidden overlay.
• Tabs and accordions toggle classes such as .tab-active or .accordion-expanded to show and hide panels.
• “Read more” buttons, cookie banners, search overlays, and back-to-top buttons all follow the same pattern.

None of these classes exist in the page’s initial static markup. They only appear after the browser runs JavaScript, and often only after a visitor actually interacts with the page — clicks a button, scrolls, or taps a menu icon.

A tool that only looks at the static HTML has no way of knowing these classes will ever exist, let alone what styles they need.

Why this is the hardest part of doing critical CSS by hand

If you’ve ever tried to hand-roll critical CSS — or used a basic automated tool that only captures a snapshot of the initial page — you’ve likely run into this exact issue. It’s genuinely difficult to get right, for a few reasons:

• The states are invisible until triggered. You can’t extract styles for a .menu-open class by looking at a page that has never been opened. Someone (or something) has to actually interact with the page to reveal that state.
• There are a lot of them, and they’re inconsistent. Every theme, page builder, and plugin names its dynamic classes differently. There’s no universal standard for “this is the class my dropdown uses when active.”
• Manual QA doesn’t scale. You could click through every menu, slider, tab, and modal on every page template and manually note the classes involved — but most WordPress sites have dozens of templates, and content changes over time. It’s easy to miss one, and easy for a fix to quietly break again after a theme update.
• Getting it wrong is worse than doing nothing. If the deferred CSS genuinely doesn’t include a dynamic class’s styles, that element can appear broken — unstyled, in the wrong position, or overlapping other content — right when a visitor is actively engaging with it. Interaction moments are exactly when you don’t want something to look broken.

This is why so much critical CSS advice online focuses only on the easy part (styles for what’s visible on first load) and glosses over the hard part (styles for what appears after someone interacts with the page).

How AWP accounts for dynamically-added classes

AWP’s optimization is built around the reality that WordPress pages are interactive, not static. When AWP’s Exchange Server analyzes a page to decide what counts as critical CSS, it doesn’t limit itself to the styles visible in the initial markup. It also identifies the CSS classes your page’s interactive elements rely on — the ones that get added by menus, sliders, sticky headers, modals, tabs, and similar components — and makes sure the styles for those classes are accounted for in the optimization result.

In practice, that means:

• The classes an interactive element needs when it opens, expands, or becomes active are captured as part of the analysis, not left out because they weren’t present at page load.
• Those styles get placed appropriately — either as part of the critical CSS if they matter early, or in the deferred CSS that loads right after first paint — so they’re available by the time a visitor actually triggers the interaction.
• You don’t have to click through every menu and slider on every page template yourself, or maintain a manual list of “classes to never remove.” That analysis happens as part of running a personalized optimization.

As always with AWP, this happens without touching your original theme files, page content, or CSS source. The optimization is applied at the output layer — the critical and deferred CSS AWP generates is additional, derived data, not a modification of your existing files — so it’s fully reversible if you ever want to turn it off.

The takeaway

Critical CSS isn’t just about what’s visible when a page loads — it’s about what your page becomes as visitors interact with it. Dropdown menus, carousels, sticky headers, and modals all depend on CSS classes that don’t exist in the static HTML, which is exactly why they’re the part most manual and basic automated critical-CSS approaches get wrong. If you’re evaluating any critical CSS solution for WordPress, ask how it handles states that only appear after interaction — it’s one of the clearest signs of whether the optimization was built for real-world, dynamic websites or just for a single static snapshot.