Page related Stylesheets

[memoworker]

The all.css stylesheet currently might have 200kb (400'000 Lines) of styles after installation of a few plugins and a theme.
Most of which are not needed on the current page.

Therefore it would be nice as a plugin / theme developer to have the ability to define for which type of page your style is relevant.
Afterwards only the relevant styles will be loaded by the page.

As example a theme.json could be adapted as follows to allow the changes:

{
    "style": [
        "@Storefront",
        {
            "file": "app/storefront/src/scss/all.scss",
            "type": "all"
        },
        {
            "file": "app/storefront/src/scss/category_detail.scss",
            "type": "category,detail"
        },
        {
            "file": "app/storefront/src/scss/detail.scss",
            "type": "detail"
        },
        "@Plugins"
    ],
    ...
}

There should be the following types:

• all (inserted at every page)
• category
• detail
• checkout
• injected (injected into every compilation process to enable the use of SCSS Variables, Mixins, usw. across the different types)

The result should be a cacheable file for each of the different combinations of types.
For example:

[tobiasberge]

Hi @memoworker, thank you for your proposal. 👍

In general I think it's a good idea to introduce more purpose specific CSS to avoid unused CSS.

I have one concern regarding the division into routes/pages like "category", "detail" etc. Because of the CMS elements we don't really know what exactly will be on a page. Someone could add additional elements to the "category/listing" for example. With the "Commerce" elements I am able to have almost the entire "detail" styling in the category listing page. If we divide the CSS on route level like this, I think we would have to add all CSS which COULD be on a dynamic page in the "all.scss" entry point. Maybe it could be an approach to let the CMS elements bring their CSS.

Don't get me wrong, doing it like this could still be a big improvement because things like "account" could have their own CSS and are not effected by the CMS.

Because of the current big CSS we have written a new ADR recently which should help us to get rid of CSS which is not needed. If we use the Bootstrap framework more appropriately and remove unneeded CSS, I think there is a lot of potential to reduce the CSS globally.

[niklaswolf]

It would already be a big improvement to allow specifying a type or bundle like "account", "cart", "checkout", "cms", etc.
It makes no sense to load all the cart, checkout & account styles on any other page then the pages they belong to. This would already be a huge improvement, especially the initially requested pages typically are landing- or product-detail-pages.

Regarding the CMS: all CMS-styles could be served in one file for the first iteration. Shopware also knows which request is a cms page and which is not. So the CMS-chunk could be injected only on those pages.

[BrocksiNet]

I really like 🤩 this idea in general. And for sure it is more complicated than it looks like. 🙈

Here are some thoughts ☁️ about the proposal:

---

We define in a theme some new SCSS entry points that should affect how the core is building the CSS. I got the point and I guess this should be reflected in new SCSS files inside the core ... but then you will break up the 7 - 1 pattern ... and then the core will not have one base.scss we will have one "base" for every page. And that leads to a challenging task like deciding what is inside every new entry point (without breaking too much).

And this is just the start of the rabbit hole: What about Plugins? How can Plugins then add their SCSS to a specific page? Sure we can define a structure with folders and then the core collecting the files the same way we do it for all.css but in specific folders. The downside of this would be also longer build times and more chances to run in a timeout because the PHP SCSS compiler can crash more often. [This is also another story to improve the CSS compiling, smaller chunks or in a perfect world get rid of it.]

To try the new approach we could set a new @StorefrontPages inside theme.json. @Storefront and @Plugins will work like now and merge everything into all.css. @StorefrontPages will create the new CSS files for every page but not for all.css. And now we have more CSS files, how can someone then decide to use the new CSS instead of the all.css (for every page separate)? Should this be a theme config, admin config or will we check if the page entry file is there and when it was built prefer that over all.css.

What happens with Plugins that do not adapt to the new structure? So the style is lost until they adapt or should there be something like plugin.css (contains all the CSS from the old approach)?

I would also love to see some cirtical.css file afterward when we doing this "easy" task 😃

---

I know a lot of thoughts but I just want to make sure that everyone is aware that this is not a simple topic to integrate into an existing platform. Happy to hear your feedback about this. Thx. 🤝

[niklaswolf]

Regarding plugins etc: I think the most obvious and non-breaking approach would be to always fallback to the all.css chunk. What I mean by this is that if the plugin does not explicitely specify where the css belongs to (however the mechanism for this would look like), it always ends up in the all.css

[BrocksiNet]

Sure, but when all.css is not used in Listing and the Plugin is adding Styles for Listing ... what to do now? The Plugin needs to Support the new approach to get into the @StorefrontPages. But until that happend, the Style is lost.

[niklaswolf]

all.css should be loaded nevertheless on all pages. But it only includes:

• the code that is needed on all pages
• all code that was not specifically marked for a specific page

[BrocksiNet]

That would definitely be a break, and the name could be a bit confusing like all.css with all the CSS or all.css with the CSS for all pages. Anyway, we need to split the CSS and that's the main point here, so we will prepare some POC to discuss further. 👍

[BrocksiNet]

Here is a Link to a POC that uses Vite for Shopware and tries to split the CSS (check the Readme).
Feel free to test it and maybe prepare some PR or use it for further discussions.