Why are styles in a <style> tag instead of in an external file? #41793

scofennell · 2022-06-17T16:28:00Z

scofennell
Jun 17, 2022

It seems like there are two interesting ways to make block & FSE styles external:

A WP API endpoint with a content-type for text/css and a cache breaking timestamp as a url variable
A file written to the uploads folder

This would offer several advantages over inline styles:

Cache-able
Version-able
Easily import/exportable
Smaller html document

Is there a discussion around this idea somewhere? I'd like to understand how we got to a giant <style> tag.

andrewserong · 2022-06-21T05:46:21Z

andrewserong
Jun 21, 2022
Maintainer

I'm not too sure of the origins of why global styles are output in a <style> tag, but at least with the current state of how styles are rendered, there'd be a fair few blockers to trying to get to a single cacheable file / API endpoint result:

Many styles are generated dynamically based on what is currently being rendered
Styles come from many different places at the moment (block styles, block supports styles when an individual block is rendered, global styles)
Because styles are often generated dynamically, it would be difficult to manage with a file written to the uploads folder

There's currently work underway to attempt to consolidate many of the different places where styles are generated. Some of this work is being tracked in the style engine tracking issue (#38167). While consolidating to a single (or close to it) stylesheet is a really good idea, I think it could be challenging attempting to balance the features that conditionally output styles based on what's currently rendered (e.g. what was introduced in #41160) with attempting to have a consistent output across page views.

The idea of moving to loading the styles via the global styles endpoint is a very compelling idea, though! Within style engine work, looking into this is currently slated for once there's better consolidation of how styles are output, but it's worthwhile having the discussion here to imagine how things might work one day. CC: @ramonjd

0 replies

aristath · 2022-06-21T07:07:08Z

aristath
Jun 21, 2022
Maintainer

Let's break down the benefits mentioned above, one by one...

Cache-able

A browser will do the following:

Get the HTML
Get render-blocking assets (like stylesheets).
Start/continue drawing
Rinse and repeat steps 2-3 until we get all blocking assets
Get other assets
Continue drawing

Files caching comes in on step 2: The 1st time the browser visits a page, it will get the .css file and cache it locally. On subsequent requests, If the browser has a CSS file in-memory, then it doesn't need to make an additional request to get the file and uses the files from memory.
However, if the styles are available on step 1, then it can skip step 2 completely.
Caching is excellent for big assets, but for smaller ones, it's preferable to have them available in the initial request; The browser doesn't need to make an additional request, it knows beforehand what it needs to do in order to start drawing, and it has everything it needs in the initial packet it gets from the server.
The benefits of caching are negated by the fact that the styles are small enough to be inlined without a negative impact in the initial request's packet.
If the file is cached, it still does not perform as fast as inlining the style (for small assets)... Furthermore, caching only benefits the 2nd/3rd, etc requests. Inlining benefits them all - including the 1st one.
Step 2 is the most expensive one when making a request, because we can't assume that all WP sites are on the most expensive & optimized servers. TTFB will play a role in each request separately with a compounding effect - which can be detrimental if the host is slow. You don't have that when assets are inlined... It's all there in the initial request. Also worth noting that all those requests would be render-blocking and in the <head> of the document. So on a bad host it would add ~600ms, and on a good host we can hope for ~80ms. Inlining them will add 0ms 😉

Performance-wise, it is a lot better to have styles inline when those styles are small in size. You can watch an interesting discussion about inlining CSS assets on https://www.youtube.com/watch?v=3sMflOp5kiQ too 👍

Version-able

Versions in assets make sense when using .css files for cache-busting purposes. If however the styles are inlined, cache-busting is not necessary because they are included in the HTML - making versioning unnecessary.

Easily import/exportable

I don't understand this one... Why would you need to import/export styles that are generated on-the-fly?

Smaller html document

This is the only real downside I see in inlining CSS. The HTML does indeed get bigger - and uglier to look at.
However, that is only a downside from a developer's perspective when I look at the source of a document. For users, it offers better performance overall, by minimizing the number of requests and making their site load a lot faster, especially in cases where they have a poor internet connection with abysmal speeds.
Additionally, gzip/brottli are far more efficient when the CSS is inlined because then gzipping is applied to the whole document, making the overall size smaller than if it were in separate files. Gzip is more efficient with inline code, so the more similar/repetitive markup there is in a resource response, the smaller the page.
Sites are developed by people who care about the beauty of the source but are consumed by people who just want to consume content fast.

Global styles are currently a moving target. It's an API that is getting constant improvements and development. The size of styles printed gets constantly tweaked, and the goal is only to print the styles that are relevant for a page, depending on the page's actual contents and blocks used. Something like that will not be possible unless these styles are inlined, and in the future, there will be a lot fewer styles present on a page as a result of these optimizations.

In an ideal scenario, when I visit a page, the browser will only need to make a single request: Get the HTML and print it. We're not there yet, but that is an admirable goal which will benefit performance, sustainability, accessibility and democratizing content.

2 replies

scofennell Jun 21, 2022
Author

This was an excellent response. Thank you for responding at all, and thank you doubly for such a thoughtful response.

I am content to table most of my reservations now that I understand there is an ongoing effort to examine how styles are drawn, with one exception.

Your claim:

"the styles are small enough to be inlined without a negative impact"

I completely agree that this will be true in many sites, but I'm wondering if perhaps many other sites will generate inline CSS that is large enough to impact performance.

Is there an idea of how large, in terms of download size, inline styles would have to be, before it gets to a point when it would be better to cache them in an external file?
Is there an idea of how large of an inline css payload we might see on, say, a garden variety marketing home page?

aristath Jun 22, 2022
Maintainer

Is there an idea of how large, in terms of download size, inline styles would have to be, before it gets to a point when it would be better to cache them in an external file?

That is a rather complicated question... 😅
The web (HTTP) is built on top of TCP, and TCP works with "packets". Each packet is ~65k, so when we request a 1MB file, it arrives to the browser as a stream of packets.
Getting 5 sequential packets will always be faster than making multiple separate requests to the server... So in a sense, inline will always be more performant than separate files. But that's where things get complicated because of the browser caches... Large files benefit from caching and the server request would be omitted.
It's difficult to quantify these, so instead, I'll talk about the "ideal" scenario below.

In an ideal world, a page would fit inside a single packet. Less ideal but still a lot better than using separate files, 2 packets would work fine. Getting the 2nd packet of the stream is a trivial task and a lot simpler than getting a separate file... Which means that the HTML + CSS (gzipped) should be less than 128k. Let's make that 120, because the 1st packet will also include the headers etc.
Gzip usually compresses plain-text like HTML/CSS/etc with a ratio of 3:1 and above. For example, the page on https://wordpress.org/plugins/gutenberg/ has a size of ~122k, and gzipped it's ~28k - which means that gzip there has a ratio of 4.3:1.
Let's assume it's doing a bad job, and it only compresses the data with a 3:1 ratio and not above. In this case, the total (uncompressed) amount of data should be less than 360k.
Assuming an average document size of 150k, that would leave 210k for the inline CSS.

The scenario described above makes a lot of assumptions and is therefore completely inaccurate. I'm just using it as a way to demonstrate the logic, and what a "reasonable" value would be.
I'd say that if we stay under 100-200k for inline CSS, we're safe.

The global styles are currently waaaaay below that threshold, so they don't really pose a risk.
But what about individual block styles then? In WP 5.8, we pushed an improvement in WP to only load styles for used blocks, and to inline small styles for blocks (see this post). Classic themes need to opt-in, but block themes have that behavior turned on by default (which is one of the reasons they are a lot faster than classic themes). These tweaks included a styles_inline_size_limit filter, which at the time was set to 20k.
In the future, as we fine-tune global styles and iterate on ways to minimize the amount of CSS loaded, I expect that value to change.

We keep testing and evaluating the performance of these things, and the end-goal is to make block themes as performant as possible with a combination of loading strategies for block styles and global styles. We have lots of tools available in our arsenal.. Inline styles at this point is simply the most performant option out of them 👍

ramonjd · 2022-06-21T22:12:09Z

ramonjd
Jun 21, 2022
Maintainer

Also thanks for the great responses, folks!

I'm wondering if perhaps many other sites will generate inline CSS that is large enough to impact performance.

This is a narrow aspect of the overall issue, but there's active work that is attempting to reduce the impact of block-specific styles. See for example this issue: #41434 and the PR that is addressing such issues: #40875

0 replies

BowFarmer · 2023-07-29T17:04:43Z

BowFarmer
Jul 29, 2023

What is overlooked in this discussion is the impact on security with generating inline styles. It makes it very difficult to build a robust content security policy in inline styles. Whether to have styles brought inline or not should be a setting a WordPress administrator could set. For a site using asynchronous loading http2 and a CDN, having styles in css files is preferable to having them inline.

2 replies

aristath Aug 1, 2023
Maintainer

For better or worse, inline styles are at the core of the block editor's architecture.
We can easily get rid of the stand-alone <style> elements, but that would still leave all the <div style="..."> stuff - which also don't comply with CSP.
I'm not saying it's impossible to fix, but it will require a significant architectural refactor of the editor

huubl Aug 2, 2023

Related:
#50417

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Why are styles in a <style> tag instead of in an external file? #41793

{{title}}

Replies: 4 comments 4 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Why are styles in a <style> tag instead of in an external file? #41793

scofennell Jun 17, 2022

Replies: 4 comments · 4 replies

andrewserong Jun 21, 2022 Maintainer

aristath Jun 21, 2022 Maintainer

Cache-able

Version-able

Easily import/exportable

Smaller html document

scofennell Jun 21, 2022 Author

aristath Jun 22, 2022 Maintainer

ramonjd Jun 21, 2022 Maintainer

BowFarmer Jul 29, 2023

aristath Aug 1, 2023 Maintainer

huubl Aug 2, 2023

scofennell
Jun 17, 2022

Replies: 4 comments 4 replies

andrewserong
Jun 21, 2022
Maintainer

aristath
Jun 21, 2022
Maintainer

scofennell Jun 21, 2022
Author

aristath Jun 22, 2022
Maintainer

ramonjd
Jun 21, 2022
Maintainer

BowFarmer
Jul 29, 2023

aristath Aug 1, 2023
Maintainer