网站性能（通过Lighthouse）：更少的HTTP请求或更少的渲染阻止？

Question

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

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

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

• 对于关键脚本，请考虑将其内联到HTML中。 对于非关键脚本，请考虑使用async或defer属性对其进行标记。 请参阅添加与JavaScript的交互以了解更多信息。
• 对于样式表，请考虑按照媒体查询将样式拆分为不同的文件，然后将media属性添加到每个样式表链接。 加载页面时，浏览器仅阻止第一个绘画来检索与用户设备匹配的样式表。 请参阅渲染阻止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）。 最重要的是，已经缩小了jQuery文件（95 kiB），还有一些较小的CSS文件，这些文件特定于网站的某些区域。 由于我的网站（微处理器信息存储库）的性质，还希望用户一次访问就可以浏览多个页面。

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

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

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

---

问题

1. 由于所有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. --> 

2. 第一个问题也适用于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 --> 

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

---

谢谢！

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

问题1：您可以随身携带单独的CSS文件，以方便编辑。 使用vswebessentials捆绑和缩小生产版本。 当您将其托管在服务器上时，请设置一个较远的过期日期或使用缓存清单。 然后，您需要在进行更改时重命名捆绑的文件。 网站将工作得更快。

通过单连接下载时，如果今天的日期为75kb，则css并不大，如果您提供了一个远期的到期日期，并且您的客户端对该域的任何其他日期都没有其他要求。 希望您不会每天更改CSS。 您也可以按照媒体查询规范将其细分。

问题2从cdn加载jquery是一个好主意，但是您需要确保在js执行之前，它可以使用。 不要将服务人员用于简单的事情。 如果您想检查www.google.co.in进行审核，则您的审核编号可能会比Google更好。 因此，不要使审核编号使开发复杂化。 专注于UX。 这就是谷歌在做什么。

问题3您可以并且应该将CDN用于jquery和字体。 如果可以，请使用缓存清单和远期到期，而不要遵循号码和服务工作者的审核选项卡。

Answer 3

我希望我的网站免费获得我的渐进式Web应用程序（Angular，AWS serverless）的高评价。 我得到的评分如下图所示。 对于您的问题，我会建议您这样做...

1）将折叠内容上方所需的CSS文件放在HTML页面本身中，对于其余的CSS文件，让它们异步加载。 小心未使用的CSS，我花时间清理和删除未使用的类。

2）您真的使用很多jquery吗？ 为了获得最佳结果，您可能想编写原始的javascript而不是在上面的内容中特别使用jquery。 在我的网站https://beta.akberiqbal.com中，我为上述项目（导航等）编写了简单的javascript。 在折叠之下，我得到了三个Angular5 JS文件。 bundle.css文件很小，因此我也将其作为HTML的一部分。

3）如果您有Service Worker应用程序，则本地获取应该比CDN更快。