This, of course, will depend on the features of the project.
But, generally speaking, in my opinion it's worth extracting CSS - even with HTTP 1.1. By combining css files into scripts, you lose the ability to cache css. In addition, you may suffer from Flash Unstyled Content (FOUC). Please note that although HTTP / 2 introduces multiplexing requests, so there is no longer any need to reduce the number of requests by combining assets into one, nevertheless the fastest request is the one that was not executed. By parsing css and javascript files, you can use browser caching for css files, which can change less frequently than scripts.
When the new code is released, the user will not have to download all the packages again if they are not changed. Because of this, it would be really useful to merge your css files into several parts (that is, where HTTP2 may be applicable). In a typical scenario, you will have: provider styles — libraries that do not change, basic styles — basic css that rarely change, components css-css-modules for certain components.
It is difficult to evaluate the overall performance of HTTP / 2 at this stage. The adoption of technology is still in its infancy, there are no clear best practices to follow this guarantee of success. After some stories about using HTTP / 2 and tests [1] , [2] , we can conclude that reality is a little more complicated than theoretical deviations. As the above results show, for example, delivering many small assets using the HTTP / 2 protocol can lead to some additional overhead in terms of compression.
To summarize, you should always try to test and measure the performance hypothesis when trying to use HTTP / 2 in an applicable scenario, since it cannot provide the desired performance boost.
Also take a look at the large slides from Ilya Grigorik . Considering only disaggregation of css in HTTP / 2 is wrong. You should also look at pushing and prioritizing servers in terms of providing critical assets for the fastest rendering.