Plenty of caching plugins have an option called “Remove Unused CSS.” Turn it on and it scans your pages, deletes every selector no element uses, and sends the browser a slimmed-down stylesheet.<\/p>\n
Most of the time that works well. The problem is that it decides statically.<\/p>\n
First, classes added in the page builder’s back end. A name typed into an element’s “extra class” field doesn’t appear anywhere in the templates, so the scanner assumes nobody uses it.<\/p>\n
Second, design tokens declared only on Third, classes that scripts attach at runtime. The scan is done before any of that happens.<\/p>\n Every piece of evidence we could get our hands on said things were fine.<\/p>\n The file on the server had the declaration. So did the combined file. In DevTools, the file loaded with a 200.<\/p>\n The one thing that turned out to tell the truth was Declarations that would get stripped are injected by the plugin as inline styles instead. Inline styles don’t go through the removal step.<\/p>\n WordPress lets you declare dependencies between stylesheets so that A always loads after B. We used to think a dependency meant we were covered. It guarantees the order. It doesn’t guarantee the file gets loaded at all.<\/p>\n","protected":false},"excerpt":{"rendered":" The file is right, the path is right, and the rule is sitting in the combined stylesheet. It still doesn’t apply.<\/p>\n","protected":false},"author":1,"featured_media":1027,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[29],"tags":[],"class_list":["post-2127","post","type-post","status-publish","format-standard","has-post-thumbnail","category-web-notes-en-us"],"yoast_head":"\n:root<\/code>. You define the variables now and plan to use them later, and nothing references them yet. To the scanner, that’s dead code.<\/p>\nWhy it’s hard to spot<\/h2>\n
getComputedStyle()<\/code>, which reports the value the browser actually ended up using. Our first two checks both came back all green because we took “the file on the server has it” as proof. Now we verify with getComputedStyle()<\/code> every time.<\/p>\nWhat we do now<\/h2>\n