[PP-2] Support inline and async CSS

btw In case of inline it should go always first, so no ordering needed

@frob: no. This issue is not about adding all css as inline.

This is about allowing conditional /dynamic inline css code if a module/theme may need it for rendering reasons. Currently only possible without #attached dependecies and incorrect ordering inside head.

This is part of #2391025: Add support for inline JS/CSS with #attached

What are we going to support or not support?

I'd like to hear 2 feedback:
1. What if Performance doesn't matter
2. What if Performance does matter

Here's a possible pattern:

<html>
  <head>
    <style>inline CSS</style>
    <script src="external.js"></script>
    <script>inline JS</script>
    <script src="external.js"></script>
    <script>inline JS</script>    
    <meta />
    <link type="text/css" rel="stylesheet" href="external.css" />
    <script src="external.js"></script>
    <script>inline JS</script>
    <link type="text/css" rel="stylesheet" href="external.css" />
    <script src="external.js"></script>
    <meta />
    <script>inline JS</script>    
    <style>inline CSS</style>
    <link type="text/css" rel="stylesheet" href="external.css" />
    <style>inline CSS</style>
    <link type="text/css" rel="stylesheet" href="external.css" />
    <style>inline CSS</style>
    <link type="text/css" rel="stylesheet" href="external.css" />
    <style>inline CSS</style>
  </head> 
  <body>
    <script>inline JS</script>
    <script src="external.js"></script>
    <script>inline JS</script>
    <script src="external.js"></script>
    <script>inline JS</script>
  </body>
</html>

Frob: you linked to this case here and said is is the inline part. What you are looking for is a totally different thing. Totally unrelated to the other issue that just tries to allow developers to add some important selectors to head and not the full css. As the title is highjacking the other issue, i change the title, too.

You are highjacking the other case. Please stay on topic. This named topic is handled in the other case. You are permanently changing your comments. If you want to change all css files to inline code you may better create a contrib module. If you want to add inline css we fix this in the other case. Please do not change the status again or change the title to something different.

I also don't quite understand this issue.

"aggregated CSS into the head." and "#attach" are 2 different concepts to me.

Can I say this issue is going to get this thing workable via API:

A:

<html>
  <head>
    <meta />
    <style>inline CSS</style>
    <link type="text/css" rel="stylesheet" href="external.css" />
  </head> 
  <body>
  </body>
</html>

OR

B: (@hass and @droplet wanted. This is similiar to #2391025: Add support for inline JS/CSS with #attached I think )

<html>
  <head>
    <style>inline CSS</style>
    <meta />
    <style>inline CSS</style>
    <link type="text/css" rel="stylesheet" href="external.css" />
    <style>inline CSS</style>
  </head> 
  <body>
  </body>
</html>

Ah, that is a good topic for the case here - "aggregate CSS into the head as inline". At least this is what frob explained.

#attached is different and A and B is handled in #2391025: Add support for inline JS/CSS with #attached.

Frob: you really have not understood the case #2391025: Add support for inline JS/CSS with #attached. This is the ground api work to be able to implement A and B. Maybe you need to read the case again.

If you talk about converting the following code from:

<html>
  <head>
    <style>inline CSS</style>
    <meta />
    <style>inline CSS</style>
    <link type="text/css" rel="stylesheet" href="external1.css" />
    <link type="text/css" rel="stylesheet" href="external2.css" />
    <style>inline CSS</style>
  </head> 
  <body>
  </body>
</html>

To this non-cachable code that bloat the webpages (let's name ist C):

<html>
  <head>
    <style>content of external1.css and external2.css and inline css</style>
  </head> 
  <body>
  </body>
</html>

Than you may need this case here.

But A and B are covered in the other case and allow a developer to stop the flash of content. If you think not, you are clearly wrong and have not understood the other issue. Close the case here if you want to implement A and B here.

The flash of content will be fixed by adding small pieces of css like body width or background colors as inline css only. This does not mean every piece of css. All this requires case #2391025: Add support for inline JS/CSS with #attached.

So @frob wanted C in #17.

That meant Comment #2 until my this comment are wasting others time to read. We should open a new issue or note it in IS.

Usually, we talked about "Critical CSS" (Few KB of above fold CSS) rather than inlined ALL CSS ( big CSS like 300KB)

If we talked about "Critical CSS", I don't think Drupal is possible to do so. We have to run nodejs to capture the "Critical CSS" and adding via #attached

I think it's a better title:

Extract & Inline drupal CSS assets into HEAD tag

I am not even sure CSS that is attached as a css file can be made to be inline CSS. That is what I am requesting here.

There is no simple checkbox in core, but it can be done easily in contrib already.

Make it so all CSS regardless of how it was initially attached to the renderer, inline or file based, to be made to be put inline in head with full support of the library api. Basically, all CSS regardless of how it was initially included or attached should be able to be put into the head inline without having to duplicate the CSS.

Please see https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Asset%21C... . If you create a new asset that combines all css files into inline (it is simply what core already does) except creating a combined css file. You just do not add a file, you make it inline. This requires #2391025: Add support for inline JS/CSS with #attached very first. You can already do this dirty with html_head.

However... nobody want to add 300kb into the body of a webpage as it disables all caching features of webbrowsers and only makes your website ultra slow on mobile as you always need to transfer the webcontent (~50kb) and this ~300kb inline css with every request. Do you really like to slow down your website? I guess not.

Guess you only like to prevent the flash effect... and this may require just 500 byte inline code or less.

But making this a core feature, maybe one that is supported with an alter_hook or a yaml file. Maybe we can work through some possible APIs.

OMG. Please spend some time with core api. This is already possible with library api. Nothing extra need to be implemented. Search for library override.

For this hypothetical let's consider the navbar module. It is in core and its placement is such that it will always be above the fold. This module could flag it's css as being inline. But, (this is hypothetical) it depends on a css library from another module (I am not sure that is true). That module is marked as a css dependency and is thus added inline as well. This could be done in library definition in the yaml or as a part of #attached inline.

Navbar depends on underscore, backbone, modernizr. And again with #2391025: Add support for inline JS/CSS with #attached the developer of navbar has the ability to add all navbar css inline if he really want. No need for any extra case.

As a part of building a theme, we know that we will be using a responsive menu module (any of them should work for this example). We would like the css that the module provides to be placed inline in the head, in the info.yml we should be able to register it as a dependency and have it automatically placed in the head.

And again a theme can use library override or #2391025: Add support for inline JS/CSS with #attached to add inline js into head.

Why is it so difficult to understand that we already have all these api's??? We only need #2391025: Add support for inline JS/CSS with #attached. Please close these useless case yourself now.

See #2642122: Overriding already overridden libraries-override requires knowledge of previous libraries-overrides how library override works. It will work the same way for inline once inline is back.

No idea what you are trying here. In #23 you said all inline is not the idea. Now you changed title to do it again. It looks clearly that you are not aware what core already can or what this case is about.

@frob

Is it what this issue try to do:

performance-matter:
  version: 1.x
  css:
    theme:
      css/small.css: { inline: true }
      css/big.css: {  }

It will depend on #2391025: Add support for inline JS/CSS with #attached I think. We still do not what is the best strategy to add inline CSS/JS into HEAD. Introduce one or two random Twig tag in HEAD section will make the API more messed in the future.

The main idea is to make it chain to dependencies automatically.

This is the third time you change the goal of your case.

Dependencies are an existing feature of library api in Drupal Core 8. Example code:

google_analytics:
  version: VERSION
  js:
    js/google_analytics.js: {}
  dependencies:
    - core/jquery
    - core/drupal
    - core/drupalSettings

I got you. Does what @droplet says in #29.

Originally posed in https://www.drupal.org/node/2391025#comment-11829091 but there was still a lot of unresolved discussion about JS.
I think there is more agreement about CSS. (Current thread arguments considered).

What do you think?

You are in the wrong case.

@hass Could we potentially split the issues and have this one for CSS and https://www.drupal.org/node/2391025 for JS only? The JS discussion seems to be holding up what I think most agree is not an issue for CSS.

This is not needed. The code will be nearly the same - at least logic wise. If you can come up with the CSS part we can easily adapt the JS code.

The patch #33 does what @droplet mentions if you want to review? Not sure if it's what we need but it's being doing the trick for me.

I can't comment to the overall functionality, but I took a peek at the patch and noticed this:

+++ b/core/lib/Drupal/Core/Asset/CssOptimizer.php
@@ -20,7 +20,7 @@ class CssOptimizer implements AssetOptimizerInterface {
-    if ($css_asset['type'] != 'file') {
+    if (!in_array($css_asset['type'], ['file', 'inline'])) {
       throw new \Exception('Only file CSS assets can be optimized.');

Error message is no longer correct - it appears both 'file' and 'inline' are allowed

I've rerolled Frobs patch from #42 (with the exception fix) for Drupal 8.4.x. Should apply now.
Will try to find some time to work on some test cases as well as adding support for programmatic #attach

As a site builder trying to implement Content Security Policy and not allow any inline scripts, I don't want an arbitrary module to be able to break the expectation that all CSS is included via link tags. There's also the risk that functionality would break if I were to disable the inlining of CSS, if the module author wrote with the expectation that certain CSS was always going to be inlined.

I also don't think that inlining as implemented here has any benefit to rendering performance and time to first paint.
My understanding is that the browser will pause rendering the page when any stylesheet is encountered until the CSS is parsed (which requires downloading first for external assets). The portion of CSS still included via link tag in the head of the document will continue to block the first render of the page until it's downloaded and parsed, eliminating the benefit of extracting a portion of the CSS from that file.
The intent of inlining is to reduce the number of external assets loaded so that there is less overhead due to multiple requests, but with CSS aggregation the number of requests is already minimal. Inlining even risks increasing the number of aggregated files if an inlined portion of CSS is ordered between two external sheets that could have otherwise been aggregated (though Drupal's aggregation could probably be made smarter to prevent this).

Two ways rendering performance and time to first paint could be improved:

• Only include stylesheets in the page body when first required via Twig attach_library() (https://jakearchibald.com/2016/link-in-body/#a-simpler-better-way)
  For HTTP 1.1 the overhead of additional requests versus just including the CSS in aggregated files in the document head would probably vary per site, but this practice would be beneficial over HTTP/2 due to the reduced connection overhead.
• Allow specifying stylesheets to be included at page bottom
  This would risk content reflow if the styles would affect elements already rendered on page, but could be beneficial for interactive elements (e.g. the part of menus not visible on page load, modal content...)

@gapple: Inlining CSS is often / mostly a mobile first optimization. If you do not like it you do not need to use it, but others may care about their strongly growing mobile users.

I understand inlining CSS as a mobile optimization. However, without moving external stylesheets from the head of the page, inlining has no benefit since first paint is blocked until all CSS assets are downloaded and parsed.

Bytes transferred is the same whether the CSS is inline or external (on the first request, at least), so unless all CSS is inlined the number of requests isn't reduced and connection overhead will be the same.

Maybe you read https://en.m.wikipedia.org/wiki/Flash_of_unstyled_content first and some other websites that write about this topic. It is never about bytes. It is about beeing able to show/read content before all external css is fully loaded.

The Wikipedia article is very limited in information relevant to Flash of Unstyled Content. The references it includes are in regards to Internet Explorer 5, Safari as of 2006, and "with the advent of jQuery".

Looking deeper, Firefox treats FOUC as a browser bug and it looks like Chrome does the same.
A much more detailed walk through of browser rendering in Firefox and Safari from 2011: https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#The_m...
Here is a much newer article on the browser rendering flow: https://bitsofco.de/understanding-the-critical-rendering-path/
And info on Chrome's rendering process, and how loading stylesheets block rendering: https://developers.google.com/web/fundamentals/performance/critical-rend...

The browser will pause rendering until the last stylesheet specified in the page head is downloaded and parsed, so inlining some of the CSS offers no improvement if there are still stylesheets linked in the head of the document.
The rendering performance and time to first paint of the following examples will be equivalent. The pages both require two HTTP requests, and transfer roughly equal bytes of data.

  <html>
    <head>
      <style>
        /* Small CSS file contents */
      </style>
      <link href="large.css" rel="stylesheet" />
    </head>
    <body>
    </body>
  </html>

  <html>
    <head>
      <link href="all.css" rel="stylesheet" />
    </head>
    <body>
    </body>
  </html>

This was only a starting point for You as you seem to have no idea what flash of unstyled content is. There is the definition what is means.

Have you tried Critical CSS contrib module? This helps to inline CSS and can also load other CSS files (including aggregated ones) using preload method.

In our implementation we did the following. You have to play with it as every site is different.

1. we used different critical path CSS generators to find what CSS should be included above the fold
2. Then we moved all the minified CSS into that directory for the Critical CSS module to pick up and inline.
3. All other CSS was moved to another location such as in the <body> or other element.

@frob in the article you linked it is addressing FOUC occurring because of the use of loadCSS, not basic browser behaviour. Its recommendation to use a block of inline styles for critical CSS is no different than if the same critical CSS was included through a file in regards to the browser's render process (other than the additional network request on first page load).

loadCSS even indicates that it is only intended for CSS not critical to the initial render of the page, and is intended to improve perceived performance because CSS is by default render blocking.

@gapple is correct, unless you're doing something tricky with the rest of the CSS files, just making some inline does nothing. Making the entire contents inline is likely to be counter-productive, you wouldn't want everthing inline all the time because then you can't make use of browser caching.

https://www.drupal.org/project/critical_css is handling what this issue wants to do, so this is really a feature request about bringing that functionality into core.

Either way this should be postponed on #2391025: Add support for inline JS/CSS with #attached.

Actually this is needs more info, between the contrib module and also #2989324: Allow CSS to be added at end of page by rendering assets with placeholders, not clear what's being asked for here that's not covered by other issues.

It has been two years sine more information was asked for so progress could be made here. Since that information has not been supplied I am closing this issue.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.