2

我想知道将我的 CSS 分成两部分是否是个好主意，一个内联关键部分和一个延迟外部部分。

我的整个 CSS 是 15kb（缩小）。在线“Critical Path CSS Generator”分析器给我的关键 CSS 是 1kb，但是当我检查我的代码时，我真的相信需要 5kb 的 CSS 才能在 1920x1080 的屏幕上渲染所有折叠内容。所以，我首先关心的是，当需要三分之一的 CSS 作为关键 CSS 时，是否值得拆分 CSS，或者我应该内联整个 CSS，因为它不是那么大（15kb）？

另一方面，我在这里关注的是我们整个网站的一部分，它鼓励用户采取行动，而行动是转到网站的另一部分，那里有另一个 CMS。所以，对于我说的这一部分，每个用户的页面浏览量并没有那么高：大约 70% 的人在这里只打开一个页面，而 92% 的人打开不到 4 个页面。因此，我猜在我们的情况下，拥有一个缓存的外部 CSS 可能不太重要。最后，我感觉第一页浏览量是最重要的；如果我们可以稍微提高它的速度，即使它降低了下一页的速度，那也是值得的。但是，我不知道当使用 HTTP/2 时，使用内联 CSS 而不是外部 CSS 是否真的会影响速度。

那么，你有什么建议？拆分我的 CSS 并仅内联关键部分更好，还是简单地内联整个文件？谢谢您的帮助。

4

1 回答 1

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 文件），您可能需要发布所有内联的网页......等等。就个人而言，除非您是一个超级繁忙和超级优化的网站（例如 Google 主页），我认为增加的复杂性是不值得的。我的更多想法在这里：https ://www.tunetheweb.com/blog/inlining-css-is-not-for-me/

这在 HTTP/2 下会改变吗？好吧，是的，不是的。从理论上讲，HTTP/2 的多路复用意味着多个请求可以同时进行，因此您无需启动另一个连接来请求 CSS，因此您可能根本不需要内联。但是，这仍然需要在获取 HTML 后来回请求 CSS，因此不如内联快，即使它比 HTTP/1.1 更快（您需要等待 HTML 完全完成下载以允许连接到用于 CSS 请求，或使用 TCP 和 HTTPS 延迟启动另一个连接）。

HTTP/2 Push 应该解决这个问题 - 将 CSS 作为单独的文件保存，但是当请求 HTML 时，用 HTML 文件和 CSS 文件回复（推送 CSS 文件）。没有往返延迟，仍然是一个单独的 CSS 文件 - 两全其美。与以往一样，现实有点棘手。主要问题是如何避免为任何后续页面再次推送 CSS（与内联具有相同的缺点）。有多种方法可以做到这一点，但基于cookie 的实现可能是目前最好和最实用的。即使这样，还有其他复杂性和错误需要考虑。因此，HTTP/2 推送未能真正成为内联替代品。

于 2019-01-22T22:57:28.863 回答