我想知道将CSS分为两部分，内联关键部分和递延外部部分是否是个好主意。
我的整个CSS为15kb（最小）。在线“关键路径CSS生成器”分析器提供给我的关键CSS是1kb，但是当我检查代码时，我真的相信需要5kb CSS才能在1920x1080屏幕上呈现上述所有折叠内容。 因此，我首先要担心的是，当需要将CSS的三分之二用作关键CSS时，是否值得拆分CSS；或者考虑到CSS的大小不大（15kb），我是否应该内联整个CSS？
另一方面，我在这里关注的是整个网站的一部分，鼓励用户采取措施，而该措施是转到网站的另一部分，该网站有另一个CMS。因此，对于我正在谈论的这一部分，每个用户的页面浏览量并不是很高：大约70％的人在这里只打开一页，而92％的人打开不到4页。 因此，在我们看来，缓存外部CSS可能不那么重要。 最后，我觉得首页浏览是最重要的。如果我们可以稍微提高它的速度，即使它降低了下一页的速度，那也是值得的。但是，我不知道使用HTTP / 2时使用内联CSS而不是外部CSS是否真的会在速度上有所不同。
那么，您有什么建议？拆分CSS并仅内联关键部分，还是仅内联整个文件，是否更好？ 感谢您的帮助。
答案 0 :(得分：1)
一般规则是发送所需的内容最少-为什么发送不必要的数据并浪费下载时间和带宽？因此，如果您仅可以内嵌1kb的关键CSS，则可以这样做，如果需要5kb，则可以这样做。包括完整的15kb的主要原因是为了避免弄清楚关键或必要的CSS的复杂性，但是您似乎已经弄清楚了这个问题。
有人还争辩说，将第一个绘画的关键数据（包括内联的css和HTML）保留在页面的前14kb中-这是由于TCP的工作方式，以及它最初可以在发送10个数据包之前它希望得到任何认可。因此，任何大于14kb的内容都需要确认，因此需要往返行程和延迟。此后，在需要确认之前，TCP可以发送的数量（CWND）呈指数增长，但是开始很小。就我个人而言，我不认为14kb的数字不再适用； SSL / TLS协商（假设您使用的是HTTPS）占用了14kb的一部分，还需要往返，然后HTTP / 2（再次假设您使用的是）需要更多的kbs和往返，以发送初始消息，所有您的HTTP请求已发送和接收。因此，到这一切发生的时候，窗口大小要么只是14kb的一小部分，要么已经成倍增长到更大的大小。尽管如此，将其尽可能缩小以允许更快地下载更多页面的一般原则仍然是有效的-不必一定要盯着那个14kb的数字。
是否选择内联CSS完全取决于您。速度的提升令人印象深刻，您通常认为首页浏览量通常更为重要，但是存在不利之处，其中包括以下事实：它需要构建步骤才能确定要包含的CSS，然后再包含CSS，这是重复的。跨页面的数据，事实上，如果您更改了CSS（而不是仅发布CSS文件），则可能需要内嵌所有网页，以此类推。等等。就个人而言，除非您是一个非常忙碌且经过优化的网站（例如Google主页），我认为增加复杂性是不值得的。我对此有更多想法：https://www.tunetheweb.com/blog/inlining-css-is-not-for-me/
在HTTP / 2下进行此更改吗？是的，不是。理论上，HTTP/2’s multiplexing意味着可以同时进行多个请求，因此您无需启动另一个连接即可请求CSS，因此您根本不需要内联。但是，这仍然需要获取HTML之后的往返请求CSS，因此它的速度不如内联，即使它的速度比HTTP / 1.1快（在这种情况下，您还需要等待HTML完全完成下载以允许连接到用于CSS请求，或通过TCP和HTTPS延迟触发另一个连接）。
应该使用HTTP / 2推送解决此问题-将CSS保留为单独的文件，但是当请求HTML时，请使用HTML文件和CSS文件（将CSS文件推送）答复。没有往返延迟，并且仍然是单独的CSS文件-两者兼有。与以往一样，现实情况有些棘手。主要问题是如何避免在以后的任何页面中再次推送CSS（其缺点与内联相同）。这样做的方法多种多样，但是cookie based implementation可能是目前最好和最实用的方法。即使有other complexities and bugs to consider。正因为如此，HTTP / 2推送并不能真正作为内联替换。