Opened 4 years ago
Last modified 7 months ago
#47925 new enhancement
Twenty Nineteen: Size of style.css seems excessively large (225% as large as the next largest theme's CSS)
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.0 |
Component: | Bundled Theme | Keywords: | needs-patch |
Focuses: | css, performance | Cc: |
Description (last modified by )
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:
Change History (9)
#5
@
4 years ago
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.
#6
in reply to:
↑ 4
@
4 years ago
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.
#7
@
4 years ago
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:
These are really screaming for a better solution.
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. 😜