站点性能（通过 Lighthouse）：更少的 HTTP 请求或更少的渲染阻塞？
Site Performance (via Lighthouse): Less HTTP Requests or Less Render Blocking?
所以我一直在使用 Lighthouse 检查 Chrome 的新审核面板，并慢慢改进我网站的指标。它目前位于 95（性能）、97（可访问性）和 75（最佳实践）。
我开始阅读建议，并单击了几个部分的 "learn more" 链接。因此，我现在正在阅读 Google 开发者网站。然而，对我的问题特别重要的两篇文章是 Render-Blocking Resources and Render-Blocking CSS.
摘自 Render-Blocking Resources 文章，这是最重要的摘录（CSS 文章作为一个整体基本上继续更详细地介绍了这一点）：
- For critical scripts, consider inlining them in your HTML. For non-critical scripts, consider marking them with the
async or defer attributes. See Adding Interactivity with JavaScript to learn more.
- For stylesheets, consider splitting up your styles into different files, organized by media query, and then adding a
media attribute to each stylesheet link. When loading a page, the browser only blocks the first paint to retrieve the stylesheets that match the user's device. See Render-Blocking CSS to learn more.
- For non-critical HTML imports, mark them with the
async attribute. As a general rule, async should be used with HTML imports as much as possible.
现在，为了让我的网站达到目前的分数，以下是目前的情况。 （我应该指出，如果可能的话，我确实计划利用它们。这只是网站目前的状态。）
当前实施
- 该网站 100% 设计为移动设备优先，兼容宽度从 240 像素到 3840 像素的设备分辨率。我正在使用自适应设计，有几个断点。
- 我正在使用 HTTPS。
- 我正在使用图标精灵。
- 我使用的是未缩小的 CSS 和 JavaScript，分为几个文件，因为网站主题仍在开发中。 CSS 文件包含媒体查询。
<a> 元素正在使用 target="_blank" 而 rel="noopener" 不存在。<script> 元素未使用 async 或 defer 属性。- 我没有使用 HTTP/2 或服务人员。
- 我已经通过 cPanel ("Optimize Website") 启用了 GZIP 压缩，针对所有内容。 （我准备将其限制为 HTML、PHP、CSS、JavaScript、纯文本和 XML，如果平均加载时间更快 [我计划 运行 一个基准来测试这两种情况，每次加载网站 10 次 — 我还没有机会测试这个。）
问题
CSS 主文件相当大（目前为 75 kiB）。最重要的是，jQuery 文件已经缩小 (95 kiB)，加上几个更小的 CSS 文件，这些文件特定于站点的某些区域。由于我网站的性质（微处理器信息存储库），用户还应该在一次访问中查看多个页面。
为了遵守上面概述的准则，我正在考虑拆分 CSS 文件，使其不仅依赖于网站的当前部分，而且还依赖于媒体查询，使用 media 属性与 <link> 元素链接到它们，而不是 CSS 文件本身中的查询。
对于 JavaScript，我正在考虑将所有 async 脚本组合在一个文件中，并将所有 defer 脚本组合在另一个文件中。我假设将 jQuery API 代码与其他自写函数分组没有问题？
好的。这是我的计划，但在退后一步思考如何实施时，我注意到了几个问题，我希望你们能帮助我做出决定。这种思维过程对我来说很新（部分原因是我以前从未有过这么大的网站），所以任何意见都会很棒。
问题
由于所有 CSS 文件都已下载，无论是否使用，我不确定一个大的主 CSS 文件是否是最好的方式，或者是否有更多的 HTTP 请求并按媒体 type/query 和站点的部分拆分。无论哪种方法，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 文件和网络字体。由于它们无论如何都会占用 HTTP 请求，您是否建议直接从 jQuery CDN 和 Google 外包，而不是在本地托管文件？我提出这个问题是因为我假设 CDN 的服务速度会更快。但是，我会尽可能利用服务人员来减少下载文件的需要。
谢谢！
感谢您阅读这篇长文 post。我知道我可能已经介绍了太多细节，但我不想遗漏任何可能重要的内容。
针对您提出的问题，我的看法如下：
1) 浏览器可以在加载文件时打开到单个服务器的多个并行连接。但是，问题在于对这些连接数量的限制。加载一个 76.5 KiB 的文件通常比加载 3 个 25 KiB 的文件要慢。这并不总是成立，因为服务器握手时间 'might' 大于实际获取资源所花费的时间，特别是在您的情况下文件大小为 70Kibs 并且平均互联网速度不断增加。我想最好的解决方案将高度依赖于您定位的地理区域。
这是关于并行连接限制的讨论：
2) 相同的谓词也适用于 js 文件。然而，jQuery 如今几乎是全球性的。用户在访问您的网站之前访问过所需的网站的可能性非常高。因此，使用流行的 CDN 意味着 jQuery 文件根本不会被下载并从浏览器缓存中加载。你最大的罪魁祸首之一。即使文件不存在于浏览器缓存中，使用 CDN 也应该是首选做法，因为根据定义，CDN 是地理分布式系统，如果访问者不在地理上，CDN 很有可能提供较低的延迟与您的服务器相同的区域。
不需要立即执行的 javascript 代码应该异步或延迟加载。您对这两者的处理进一步取决于您所针对的浏览器。较旧的浏览器看不到延迟加载的任何优势。
参考：Script Tag - async & defer
3) 同样的道理也适用于字体 well.If 你正在使用一种流行的字体，它很可能已经存在于缓存中。
使用服务工作者来管理 jquery 和字体对我来说似乎有点矫枉过正。不过，您可能希望将它们用于您的其他资产。
此外，我想补充一点，您应该尝试让网页逐渐加载。仅将所需的代码放入 head 部分。在用户交互时执行的 JS 代码应该在 DOM 内容之后加载，即在结束 body 标记之上。
我还建议推迟加载 css，它用于设置内容样式而不是固定布局。这包括所有颜色、字体和其他花哨的东西。
如果您的目的是在 Chrome 审核中取得好成绩，那么我提到的内容可能并不正确。但是为了服务真正的用户，这就是我个人会做的。
问题一：
您可以随身携带单独的 css 个文件，以便于编辑。使用 vswebessentials 为生产版本打包和缩小。当您将其托管在服务器上时，设置一个遥远的未来到期日期或使用缓存清单。然后，您需要在进行更改时重命名捆绑文件。站点将运行得更快。
75kb css 在通过单一连接下载时今天的日期并不大，如果您提供一个遥远的未来到期日期并且您的客户没有对域的任何其他日期提出其他请求。
希望您不会每天更改 css。您也可以根据媒体查询规范对其进行分解。
问题2
从 cdn 加载 jquery 是个好主意，但您需要确保它在您的 js 执行之前可用。不要将服务工作者用于更简单的东西。如果要查，审计www.google.co.in，你的审计数可能比google好。因此，不要将开发与审计数字复杂化。专注于用户体验。这就是 google 正在做的事情。
问题三
您可以而且应该将 CDN 用于 jquery 和字体。如果可以，请使用缓存清单和远期到期，而不是遵循数字和服务工作者的审计选项卡。
我希望免费为我的渐进式 Web 应用程序（Angular、AWS 无服务器）获得高评级。我得到的评分如下图所示。这就是我对你的问题的建议...
1) 将首屏内容所需的 CSS 文件放在 HTML 页面本身，对于其余的 css 文件，让它们异步加载。小心未使用的 css，我花了时间清理和删除未使用的 类。
2）你真的用了很多jquery吗？为获得最佳效果，您可能希望特别是在首屏内容中使用 javascript 而不是使用 jquery 。在我的网站 https://beta.akberiqbal.com 中，我为首屏项目（导航等）写了简单的 javascript。在首屏之下，我有我的三个 Angular5 JS 文件。 bundle.css 文件很小，所以我也把它作为 HTML 的一部分。
3) 如果您有服务工作者应用程序，本地提取应该比 CDN 更快。
所以我一直在使用 Lighthouse 检查 Chrome 的新审核面板，并慢慢改进我网站的指标。它目前位于 95（性能）、97（可访问性）和 75（最佳实践）。
我开始阅读建议，并单击了几个部分的 "learn more" 链接。因此，我现在正在阅读 Google 开发者网站。然而，对我的问题特别重要的两篇文章是 Render-Blocking Resources and Render-Blocking CSS.
摘自 Render-Blocking Resources 文章，这是最重要的摘录（CSS 文章作为一个整体基本上继续更详细地介绍了这一点）：
- For critical scripts, consider inlining them in your HTML. For non-critical scripts, consider marking them with the
asyncordeferattributes. See Adding Interactivity with JavaScript to learn more.- For stylesheets, consider splitting up your styles into different files, organized by media query, and then adding a
mediaattribute to each stylesheet link. When loading a page, the browser only blocks the first paint to retrieve the stylesheets that match the user's device. See Render-Blocking CSS to learn more.- For non-critical HTML imports, mark them with the
asyncattribute. As a general rule,asyncshould be used with HTML imports as much as possible.
现在，为了让我的网站达到目前的分数，以下是目前的情况。 （我应该指出，如果可能的话，我确实计划利用它们。这只是网站目前的状态。）
当前实施
- 该网站 100% 设计为移动设备优先，兼容宽度从 240 像素到 3840 像素的设备分辨率。我正在使用自适应设计，有几个断点。
- 我正在使用 HTTPS。
- 我正在使用图标精灵。
- 我使用的是未缩小的 CSS 和 JavaScript，分为几个文件，因为网站主题仍在开发中。 CSS 文件包含媒体查询。
<a>元素正在使用target="_blank"而rel="noopener"不存在。<script>元素未使用async或defer属性。- 我没有使用 HTTP/2 或服务人员。
- 我已经通过 cPanel ("Optimize Website") 启用了 GZIP 压缩，针对所有内容。 （我准备将其限制为 HTML、PHP、CSS、JavaScript、纯文本和 XML，如果平均加载时间更快 [我计划 运行 一个基准来测试这两种情况，每次加载网站 10 次 — 我还没有机会测试这个。）
问题
CSS 主文件相当大（目前为 75 kiB）。最重要的是，jQuery 文件已经缩小 (95 kiB)，加上几个更小的 CSS 文件，这些文件特定于站点的某些区域。由于我网站的性质（微处理器信息存储库），用户还应该在一次访问中查看多个页面。
为了遵守上面概述的准则，我正在考虑拆分 CSS 文件，使其不仅依赖于网站的当前部分，而且还依赖于媒体查询，使用 media 属性与 <link> 元素链接到它们，而不是 CSS 文件本身中的查询。
对于 JavaScript，我正在考虑将所有 async 脚本组合在一个文件中，并将所有 defer 脚本组合在另一个文件中。我假设将 jQuery API 代码与其他自写函数分组没有问题？
好的。这是我的计划，但在退后一步思考如何实施时，我注意到了几个问题，我希望你们能帮助我做出决定。这种思维过程对我来说很新（部分原因是我以前从未有过这么大的网站），所以任何意见都会很棒。
问题
由于所有 CSS 文件都已下载，无论是否使用，我不确定一个大的主 CSS 文件是否是最好的方式，或者是否有更多的 HTTP 请求并按媒体 type/query 和站点的部分拆分。无论哪种方法，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 文件和网络字体。由于它们无论如何都会占用 HTTP 请求，您是否建议直接从 jQuery CDN 和 Google 外包，而不是在本地托管文件？我提出这个问题是因为我假设 CDN 的服务速度会更快。但是，我会尽可能利用服务人员来减少下载文件的需要。
谢谢！
感谢您阅读这篇长文 post。我知道我可能已经介绍了太多细节，但我不想遗漏任何可能重要的内容。
针对您提出的问题，我的看法如下：
1) 浏览器可以在加载文件时打开到单个服务器的多个并行连接。但是，问题在于对这些连接数量的限制。加载一个 76.5 KiB 的文件通常比加载 3 个 25 KiB 的文件要慢。这并不总是成立，因为服务器握手时间 'might' 大于实际获取资源所花费的时间，特别是在您的情况下文件大小为 70Kibs 并且平均互联网速度不断增加。我想最好的解决方案将高度依赖于您定位的地理区域。 这是关于并行连接限制的讨论：
2) 相同的谓词也适用于 js 文件。然而，jQuery 如今几乎是全球性的。用户在访问您的网站之前访问过所需的网站的可能性非常高。因此，使用流行的 CDN 意味着 jQuery 文件根本不会被下载并从浏览器缓存中加载。你最大的罪魁祸首之一。即使文件不存在于浏览器缓存中，使用 CDN 也应该是首选做法，因为根据定义，CDN 是地理分布式系统，如果访问者不在地理上，CDN 很有可能提供较低的延迟与您的服务器相同的区域。
不需要立即执行的 javascript 代码应该异步或延迟加载。您对这两者的处理进一步取决于您所针对的浏览器。较旧的浏览器看不到延迟加载的任何优势。 参考：Script Tag - async & defer
3) 同样的道理也适用于字体 well.If 你正在使用一种流行的字体，它很可能已经存在于缓存中。 使用服务工作者来管理 jquery 和字体对我来说似乎有点矫枉过正。不过，您可能希望将它们用于您的其他资产。
此外，我想补充一点，您应该尝试让网页逐渐加载。仅将所需的代码放入 head 部分。在用户交互时执行的 JS 代码应该在 DOM 内容之后加载，即在结束 body 标记之上。
我还建议推迟加载 css，它用于设置内容样式而不是固定布局。这包括所有颜色、字体和其他花哨的东西。
如果您的目的是在 Chrome 审核中取得好成绩，那么我提到的内容可能并不正确。但是为了服务真正的用户，这就是我个人会做的。
问题一： 您可以随身携带单独的 css 个文件，以便于编辑。使用 vswebessentials 为生产版本打包和缩小。当您将其托管在服务器上时，设置一个遥远的未来到期日期或使用缓存清单。然后，您需要在进行更改时重命名捆绑文件。站点将运行得更快。
75kb css 在通过单一连接下载时今天的日期并不大，如果您提供一个遥远的未来到期日期并且您的客户没有对域的任何其他日期提出其他请求。 希望您不会每天更改 css。您也可以根据媒体查询规范对其进行分解。
问题2 从 cdn 加载 jquery 是个好主意，但您需要确保它在您的 js 执行之前可用。不要将服务工作者用于更简单的东西。如果要查，审计www.google.co.in，你的审计数可能比google好。因此，不要将开发与审计数字复杂化。专注于用户体验。这就是 google 正在做的事情。
问题三 您可以而且应该将 CDN 用于 jquery 和字体。如果可以，请使用缓存清单和远期到期，而不是遵循数字和服务工作者的审计选项卡。
我希望免费为我的渐进式 Web 应用程序（Angular、AWS 无服务器）获得高评级。我得到的评分如下图所示。这就是我对你的问题的建议...
1) 将首屏内容所需的 CSS 文件放在 HTML 页面本身，对于其余的 css 文件，让它们异步加载。小心未使用的 css，我花了时间清理和删除未使用的 类。
2）你真的用了很多jquery吗？为获得最佳效果，您可能希望特别是在首屏内容中使用 javascript 而不是使用 jquery 。在我的网站 https://beta.akberiqbal.com 中，我为首屏项目（导航等）写了简单的 javascript。在首屏之下，我有我的三个 Angular5 JS 文件。 bundle.css 文件很小，所以我也把它作为 HTML 的一部分。
3) 如果您有服务工作者应用程序，本地提取应该比 CDN 更快。