Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement PurgeCSS #119

Closed
dainemawer opened this issue Jan 20, 2022 · 3 comments
Closed

Implement PurgeCSS #119

dainemawer opened this issue Jan 20, 2022 · 3 comments

Comments

@dainemawer
Copy link
Contributor

Historically, WordPress has really battled to get a good grasp of meaningful CSS being loaded to a given page. Often CSS files are loaded across the site, with no options for tree-shaking or code splitting in a way that makes semantic sense.

PurgeCSS is a tool that follows on from some of the paradigms introduced by frameworks like Tailwind, and the React space, where only the CSS that is required on the page is loaded. Thus, seeing our Code Coverage percentage improve. We want to see 100% code coverage on pages, i.e each CSS rule parsed is doing something, not just there because it likes the view.

PurgeCSS is one way of handling this. PurgeCSS has some baked in support for WordPress by providing a safeList of classes that we want to keep secure and safe on a page, otherwise it can parse .php and .js files in multiple folder directories and output a CSS file that only contains the CSS needed for the rendering of that page.

This does become rather tricky when it comes to Gutenberg as post content can change without a deploy. So we'd need to find a work around for that, not sure what that would be, but in general this would be a far more robust and more elegant solution, compared to something like Critical CSS.

Read more: https://purgecss.com/

@Rados51
Copy link

Rados51 commented May 24, 2022

@dainemawer Other way than safeList could be just a whitelist option as it would just need a list of all classes, that are presented on the page and the rest would be wiped from the final CSS.

@aristath
Copy link
Member

Note: I recently made a PR in Gutenberg to allow tree-shaking blocks CSS: WordPress/gutenberg#41020
Since WordPress is moving towards an "everything is a block" model and block-themes, it makes sense to implement things like tree-shaking and similar concepts to the blocks themselves.
In the future, there will not be much need for CSS that is not attached to a specific block... Long-term, it would be beneficial if our improvements are made "Just-in-time", on block-render.
Block themes already don't load any CSS for blocks that don't get rendered on a page, and that was the 1st step towards "tree-shaking", or "JIT-styling" we took. Tree-shaking the styles for individual blocks is the next logical step 👍

@swissspidy
Copy link
Member

This was discussed in this week's bug scrub (see https://wordpress.slack.com/archives/C02KGN5K076/p1721836146208509; requires registration), with the recommendation to close this as a) PurgeCSS is a build tool b) block themes and blocks already only load only the CSS required for them to work, so there shouldn't be much unused CSS.

@swissspidy swissspidy closed this as not planned Won't fix, can't repro, duplicate, stale Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants