javascript - 网站性能(通过Lighthouse):更少的HTTP请求或更少的渲染阻止？

Question

因此，我一直在使用Lighthouse查看Chrome的新“审核”面板，并逐渐改善了我网站的指标。它目前位于95（性能），97（可访问性）和75（最佳实践）上。

我开始仔细阅读建议，然后单击几个部分的“了解更多”链接。因此，我现在正在阅读Google Developers网站。但是，对我的问题特别重要的两篇文章是Render-Blocking Resources和Render-Blocking CSS。

从“渲染阻止资源”一文中，这是最重要的摘录（整个CSS文章实质上对此进行了更详细的介绍）：


  
  对于关键脚本，请考虑将其内联到HTML中。对于非关键脚本，请考虑使用async或defer属性对其进行标记。请参阅Adding Interactivity with JavaScript以了解更多信息。
  对于样式表，请考虑按照媒体查询将样式拆分为不同的文件，然后为每个样式表链接添加media属性。加载页面时，浏览器仅阻止第一个绘画来检索与用户设备匹配的样式表。请参阅Render-Blocking CSS以了解更多信息。
  对于非关键的HTML导入，请使用async属性对其进行标记。通常，async应该与HTML导入一起使用。
  




现在，为了使我的网站达到当前评分，这是当前的位置。 （我应该注意，如果可能的话，我确实计划充分利用它们。这只是该站点当前的状态。）

当前实施


该网站100％设计为移动优先，并且与设备分辨率兼容，范围从240像素到3840像素。我正在使用自适应设计，但有一些断点。
我正在使用HTTPS。
我正在使用图标精灵。
由于站点主题仍在开发中，因此我使用的是非最小化的CSS和JavaScript，它们分为多个文件。 CSS文件包含媒体查询。
<a>个元素正在使用target="_blank"，并且rel="noopener"不存在。
<script>元素未使用async或defer属性。
我没有使用HTTP / 2或服务工作者。
我已经通过cPanel（“优化网站”）启用了GZIP压缩，定位所有内容。 （如果平均加载时间更快，我准备将其限制为HTML，PHP，CSS，JavaScript，纯文本和XML [我计划通过运行基准测试来对这两种情况进行10次测试，以测试这两种情况。还没有机会进行测试]。）




问题所在

主CSS文件相当大（当前为75 kiB）。最重要的是，已经缩小了（95 kiB）的jQuery文件，还有一些特定于站点某些区域的较小CSS文件。由于我的网站（微处理器信息存储库）的性质，还希望用户一次访问就可以浏览多个页面。

为了符合上述概述的准则，我正在考虑将CSS文件拆分为不仅依赖于网站当前所在的部分，还依赖于媒体查询，并通过<link>元素使用media属性，而不是CSS文件本身中的查询。

对于JavaScript，我正在考虑将所有async脚本归为一个文件，而将所有defer脚本归为另一个文件。我假设将jQuery API代码与其他自写函数组合在一起没有问题吗？

好的。有我的计划，但是在退后一会儿并思考如何实现这一点时，引起了我几个问题，我希望你们可以帮助我做出决定。这种思考过程对我来说是很新的（部分原因是我以前从未有过这么大的站点），因此任何投入都会很棒。



问题


由于所有CSS文件均已下载，无论是否使用它们，我都不确定一个大型主CSS文件是最佳选择，还是不确定是否有更多HTTP请求并按媒体类型/查询和部分将其拆分该网站。无论采用哪种方法，CSS都将被最小化。

<link rel="stylesheet" href="reset-min.css"> <!-- ~ 1.5 kiB; all media types -->
<link rel="stylesheet" href="layout-min.css"> <!-- ~ 50 kiB; internal @media -->
<link rel="stylesheet" href="color-min.css"> <!-- ~ 25 kiB; internal @media -->

<!--
    3 HTTP requests; 76.5 kiB
    Main CSS file split into "layout" and "color" for easy editing in the future.
-->

vs.

<link rel="stylesheet" href="reset-min.css"> <!-- ~ 1.5 kiB; all media types -->
<link rel="stylesheet" href="global-screen.css" media="screen"> <!-- ~ 7 kiB; site-wide elements -->
<link rel="stylesheet" href="color-screen.css" media="screen"> <!-- ~ 10 kiB -->
<link rel="stylesheet" href="database-screen.css" media="screen"> <!-- 20 kiB; not on all pages -->
<link rel="stylesheet" href="global-print.css" media="print"> <!-- ~ 6 kiB; site-wide elements -->
<link rel="stylesheet" href="color-print.css" media="print"> <!-- ~ 7 kiB -->
<link rel="stylesheet" href="database-print.css" media="print"> <!-- ~ 7 kiB; not on all pages -->

<!--
    7 HTTP requests; 58.5 kiB
    CSS files split into "global/database" and "color" for easy editing in the future.
-->

第一个问题也适用于JavaScript文件。我具有用于功能的主要JS文件以及jQuery API文件。但是，由于功能将由 async或 defer属性分割，因此将导致更多的HTTP请求，但大小更小。 JS也将被缩小。

<script src="jquery-min.css"> <!-- ~ 95 kiB; local -->
<script src="scripts-min.css"> <!-- ~ 21.3 kiB -->

<!--
    2 HTTP requests; 116.3 kiB
-->

vs.

<script src="scripts-async-min.css" async> <!-- ~ 108.1 kiB; includes jQuery API -->
<script src="scripts-defer-min.css" defer> <!-- ~ 4.3 kiB -->

<!--
    2 HTTP requests; 112.4 kiB
-->

我的最后一个问题确实涉及减少网页加载的主要根源-jQuery API文件和Web字体。由于它们仍然处理HTTP请求，您是否建议直接从jQuery CDN和Google外包，而不是在本地托管文件？我提出这一点是因为我认为CDN的投放速度会更快。但是，我将尽可能利用服务人员来减少下载文件的需求。




谢谢！

感谢您阅读这篇长文章。我知道我可能已经讲了太多细节，但是我不想遗漏任何可能很重要的东西。

Answer 1

这是我对您提出的问题的看法：

1）浏览器可以在加载文件时打开到单个服务器的多个并行连接。但是，问题在于这些连接数量的限制。加载76.5 KiB的单个文件通常比加载25 KiB的3个文件要慢。因为服务器握手时间“可能”大于实际获取资源所花费的时间，所以这种情况永远不会成立，特别是在文件大小为70KB和平均Internet速度不断提高的情况下。我想最好的解决方案将高度取决于您所针对的地理区域。
这是关于并行连接限制的讨论：Max parallel http connections in a browser?

2）同样的谓词也适用于js文件。但是，jQuery如今几乎是全球性的。用户访问您的网站之前需要访问的网站的可能性非常高。因此，使用流行的CDN意味着将完全不会下载jQuery文件，也不会从浏览器缓存中加载jQuery文件。您最大的罪魁祸首之一。即使文件不存在于浏览器缓存中，使用CDN也应是首选做法，因为根据定义，CDN是地理分布式系统，并且如果访问者不在地理区域内，则CDN很有可能提供较低的延迟。与您的服务器相同的区域。

并非立即需要执行的javascript代码应异步加载或延迟。您对这两者的操作还取决于您要定位的浏览器。较旧的浏览器不会看到延迟加载的任何优势。
参考：Script Tag - async & defer

3）同样的理由也适用于字体。如果您使用的是流行字体，则很有可能已经在缓存中了。
对我来说，使用服务人员来管理jquery和字体似乎是过大了。不过，您可能希望将它们用于其他资产。

另外，我想补充一点，您应该尝试逐步加载网页。仅将所需的代码放入头部。在用户交互后执行的JS代码应在DOM内容之后（即，在结束body标签上方）加载。

我还建议推迟加载用于样式化内容的CSS，而不是固定布局。这包括所有颜色，字体和其他奇特的东西。

如果您的目的是在Chrome审核中获得良好的成绩，那么我提到的内容可能并不正确。但是，为了服务于实际用户，这是我个人要做的。