I’ve come across some unexpected behavior with the “CSS per page” feature and I’m curious if anyone else has noticed this.
My finding is:
I have “CSS per page” set to “on” for the entire site.
I created a completely blank page—no elements, no custom code.
I expected the dedicated CSS file for this page to be empty or nearly empty.
However, upon inspection, the page’s CSS file contains all the class definitions for all breakpoints below desktop, even for classes that are only used on other pages of the site.
This seems to defeat the purpose of “CSS per page,” as it appears to be leaking styles from other parts of the site into a page where they are not used.
Has anyone else experienced this? Is this a known issue or a bug? Any insights would be appreciated.
Try using the support AI bot, it may have some details on the design here. If not, open a ticket and the support team can tell you more.
My guess is that there are certain situations where the current per-page CSS generator includes classes that it might need, which are not easily determined during the publishing step. If I had to guess, that might include classes used in components.
You could try creating a new site from a template, no components, and run your same test to see if my theory aligns with the behavior you’re seeing.
With CSS per page on, Webflow serves up a shared css file regardless of whether your page is empty or not. It’s about 38kb and compressed about 8.9kb. You get this by default with no option to not load it.
Yeah, that’s expected right now , “CSS per page” still pulls in base classes and breakpoint styles tied to symbols/components, even if they aren’t placed on the page. Had to debug this on a blank test page for a client, same outcome. The only true empty result I’ve seen is on brand-new projects with zero global classes.