html
Scenario
The outcome of our evaluation depends on how we are theming our site. In this evaluation, we will start from the following work methodology based on:
- Development using reusable, precise components following the SMACSS methodology (categorizing them into: "base, layout, module, state & theme").
- Use of SASS to generate SCSS files.
- Use of the SMACSS methodology to organize our SCSS files.
- Use of BEM to name our components and their variants.
- Drupal 8.
- "Combine CSS files" enabled.
Evaluation of the apparent advantages we find when splitting CSS files in our work scenario.
Overcoming technical limitations of browsers
The main and most notable limitation comes from Internet Explorer version 9, regarding the number of selectors per stylesheet and the maximum number of stylesheets.
Initially, this is not an issue since the minimum version supported by Drupal 8 (>8.4.x) is Internet Explorer 11 (source).
IE 11 already has a limit that will be nearly impossible to reach in most cases (65,534 selectors and 4,095 stylesheets).
Additionally, we should highlight Drupal's excellent "Combine CSS files" feature, which allows us to greatly optimize stylesheets.
In reality, splitting files or not in this section does not provide any improvement since the result would be the same: a single CSS file that would rarely reach the mentioned limitations.
Page load optimization
The advantage lies in only loading the CSS of the components that appear on the viewed page. The CSS generated by the "Combine CSS files" functionality would differ on each page (if the components vary).
This does not make much of a difference because, although the CSS size is optimized, the browser would need to download a new CSS for each version of the page with different pieces. This means that on the server side, Drupal would have to generate different stylesheets, and on the client side (browser), it would require a new download for each page (containing different pieces) instead of using a single cached version of the file.
More readable CSS by not containing all theming and better CSS file organization
In our proposed workflow, we will have components perfectly organized in SCSS files with SMACSS, independently of the CSS files we generate.
By generating our theming in separate files for each component and using SASS, we do not need our CSS to be readable since the .scss files—the files we actually work with—already are.
Therefore, this also does not provide a real advantage in this case.
Drawbacks we encounter in our methodology when splitting CSS files
- Generating split CSS adds significant additional development overhead by requiring us to indicate in Drupal when each component is used. The process would involve creating a library for each component in our theme, including the CSS in a template/twig preprocessing function, etc.
- It also creates an additional hurdle when wanting to use a component from our pre-built theme, which we could otherwise simply use or reuse by leveraging BEM selectors.
- Additionally, it would require changing the way we generate components in SASS. Each component would need to include a set of essential base files, such as: the _init.scss file with the variables used in our site (colors, font sizes, etc.), _mixins.scss (if we need to use mixins), etc., as well as any other required components.
Conclusion
The scale definitively tips in favor of generating a single CSS file in our scenario, as the advantages we might initially assume are debunked upon closer analysis. When we add the additional development overhead and the burden it places on creating our reusable component-based theme, the conclusion becomes clear.
When might it be a good option?
For generating stylesheets categorized by SMACSS as theme, examples: a Christmas theme, optional equivalent themes that users can enable (like YouTube's dark theme). Having isolated files would allow us to dynamically load or use these styles with JavaScript (without needing to reload the page).
In other work scenarios different from the one presented, the balance may shift. Feel free to add any in the comments section, as well as mention any details we may have overlooked.
