Twenty Nineteen: Size of style.css seems excessively large (225% as large as the next largest theme's CSS)

[westonruter]

I just did a check of the size of each core theme's style.css and here's what I found (first column is byte size):

  221622 twentynineteen/style.css
   98458 twentyfifteen/style.css
   83559 twentyseventeen/style.css
   81216 twentyfourteen/style.css
   70311 twentysixteen/style.css
   57356 twentyeleven/style.css
   57106 twentythirteen/style.css
   37606 twentytwelve/style.css
   24688 twentyten/style.css

The style.css for Twenty Nineteen is 225% the size of the next-largest core theme stylesheet, for Twenty Fifteen. Between 5.2.2 and 5.3-alpha, the size of Twenty Nineteen's CSS has grown yet another 9KB.

Prior to Twenty Nineteen, themes primarily had their CSS hand-written, I believe. As of Twenty Nineteen, SASS was used for the first time. Depending on how SASS is written, a little bit of code can end up generating a lot of CSS. Is this the case here for Twenty Nineteen? It doesn't seem the large amount of CSS is directly due to styling blocks, since the other themes have also been updated to style blocks.

A large amount of CSS has negative impact on performance. Not only does it increase the amount of time to render the page (as CSS is render-blocking) through increased data transfer time and CSS parsing time, it also hurts performance once the page has loaded, as there is more CSS in memory and more selectors to be evaluating.

How can the amount of CSS in Twenty Nineteen be reduced to be more in-line with the other core themes?

---

A few resources related to CSS performance:

• ​Reduce the Scope and Complexity of Style Calculations
• ​Render Blocking CSS
• ​Efficiently Rendering CSS

[marybaum]

I wonder if it’s all getting used. I’ve seen mention of a tool that shows which rules are active in a site and which aren’t, so my inclination would be to start there.

Then i’d Look to see if the thing is responsive or mobile-first, bc at least some rules can stay the same from {min-width: 0} to JumboTron size. For example.

And then would come my favorite, replacing floats with Flexbox for things that line up in one direction or Grid for things that lay out in two dimensions. Combine that with a mobile-first stylesheet and we can take a bath towel to a good 40% of a tightly written responsive sheet.

Then we can look for places to hit with a squeegee. 😜

[SergeyBiryukov]

I've encountered a similar issue with the wporg-support theme in ​#meta2479.

The theme's usage of SASS' extend feature caused some excessively verbose selectors, most of which were never used and created unnecessary bloat, even hitting a limit on CSS selector length in some cases.

​Extending In Sass Without Creating A Mess is a good reading on using extend more efficiently.

At a glance, a large part of the file is taken up by font family declarations with non-latin fallbacks​, coming from _mixins-master.scss​, which does use extend. If we find a way to optimize them, it should reduce the file size in half.

[westonruter]

Replying to marybaum:

I wonder if it’s all getting used. I’ve seen mention of a tool that shows which rules are active in a site and which aren’t, so my inclination would be to start there.

Also, a lot of the language-specific styles seem like they would be better added via PHP inline styles based on what the actual active language is.

[kjellr]

Off the top of my head, I can provide a few additional details.

Depending on how SASS is written, a little bit of code can end up generating a lot of CSS. Is this the case here for Twenty Nineteen? It doesn't seem the large amount of CSS is directly due to styling blocks, since the other themes have also been updated to style blocks.

It could definitely be a part of it! I'm sure the SASS could use a refactor — nobody's been available to take that on since the theme launched, but it would be incredibly welcome.

Regarding the block styling: Twenty Nineteen does include more extensive styling for the core blocks than the other core themes do (for instance, the off-center alignments), so I'd definitely expect the blocks code to be just a little heavier at least.

Then i’d Look to see if the thing is responsive or mobile-first, bc at least some rules can stay the same from {min-width: 0} to JumboTron size. For example.

And then would come my favorite, replacing floats with Flexbox for things that line up in one direction or Grid for things that lay out in two dimensions. Combine that with a mobile-first stylesheet and we can take a bath towel to a good 40% of a tightly written responsive sheet.

Everything should be mobile first, and reliant on flexbox already — though I haven't stayed on top of every commit, so I wouldn't say I'm 100% positive on that one. 😅

At a glance, a large part of the file is taken up by font family declarations with non-latin fallbacks​, coming from _mixins-master.scss​, which does use extend. If we find a way to optimize them, it should reduce the file size in half.

Also, a lot of the language-specific styles seem like they would be better added via PHP inline styles based on what the actual active language is.

Yes, exactly. I think this is a huge part of the CSS bloat, and would probably offer the biggest quick win. Those language-specific font fallbacks were a beast to build, and provide a lot of extra code (most of which is unused for many users). You can find some details on the current (and previous) implementation here:

#45731

These are really screaming for a better solution.