Javascript 站点性能（通过Lighthouse）：减少HTTP请求或减少渲染阻塞？_Javascript_Html_Css_Pagespeed_Lighthouse

Javascript 站点性能（通过Lighthouse）：减少HTTP请求或减少渲染阻塞？

javascript html css

Javascript 站点性能（通过Lighthouse）：减少HTTP请求或减少渲染阻塞？,javascript,html,css,pagespeed,lighthouse,Javascript,Html,Css,Pagespeed,Lighthouse,所以我一直在用Lighthouse检查Chrome的新审计面板，并慢慢地改进我网站的指标。它目前的排名是95（性能）、97（可访问性）和75（最佳实践）我开始浏览这些建议，并点击了几个部分的“了解更多”链接。因此，我现在正在浏览谷歌开发者网站。然而，对我的问题特别重要的两篇文章是和从Render Blocking Resources文章中，这里是最重要的摘录（CSS文章作为一个整体基本上更详细地介绍了这一点）：对于关键脚本，考虑在HTML中嵌入它们。对于非关键脚本，考虑使用“代码> AS

所以我一直在用Lighthouse检查Chrome的新审计面板，并慢慢地改进我网站的指标。它目前的排名是95（性能）、97（可访问性）和75（最佳实践）

我开始浏览这些建议，并点击了几个部分的“了解更多”链接。因此，我现在正在浏览谷歌开发者网站。然而，对我的问题特别重要的两篇文章是和

从Render Blocking Resources文章中，这里是最重要的摘录（CSS文章作为一个整体基本上更详细地介绍了这一点）：

对于样式表，考虑将样式划分为不同的文件，通过媒体查询组织，然后向每个样式表链接添加<代码>媒体< /代码>属性。加载页面时，浏览器仅阻止第一次绘制以检索与用户设备匹配的样式表。请参阅以了解更多信息
对于非关键HTML导入，使用
```
async
```
属性标记它们。一般来说，
```
async
```
应尽可能多地用于HTML导入

现在，为了让我的网站达到目前的分数，这里是目前的情况。（我应该注意的是，如果可能的话，我确实计划充分利用它们。这只是网站目前的现状。）

当前实现

该网站是100%设计为移动第一，并兼容设备的分辨率范围从240像素到3840像素的宽度。我使用的是带有几个断点的自适应设计
我正在使用HTTPS
我用的是图标精灵
我使用的是非小型CSS和JavaScript，分为几个文件，因为网站主题仍在开发中。CSS文件包含媒体查询
元素正在使用
```
target=“\u blank”
```
并且
```
rel=“noopener”
```
不存在
元素未使用
```
异步
```
或
```
延迟
```
属性
我没有使用HTTP/2或服务工作者
我已经通过cPanel（“优化网站”）启用了GZIP压缩，目标是所有内容。（如果平均加载时间更快，我准备将此限制为HTML、PHP、CSS、JavaScript、纯文本和XML（我计划运行一个基准测试，通过分别加载10次站点来测试这两种情况，我还没有机会测试这一点）。）

问题主CSS文件相当大（目前为75kib）。除此之外，还有已经缩小的jQuery文件（95kib），以及一些特定于站点某些区域的较小CSS文件。由于我的站点（微处理器信息存储库）的性质，用户还需要在一次访问中查看多个页面

为了遵守上面概述的指导原则，我正在考虑拆分CSS文件，使其不仅依赖于网站的当前部分，而且还通过媒体查询，使用

媒体属性通过
元素链接到它们，而不是CSS文件本身中的查询
对于JavaScript，我考虑将所有async
脚本组合在一个文件中，将所有defer
脚本组合在另一个文件中。我假设将jQueryAPI代码与其他自行编写的函数分组没有问题
好的。这是我的计划，但在退一步思考如何实施时，有几个问题引起了我的注意，我希望你们能帮助我做出决定。这种思考过程对我来说是非常新鲜的（部分原因是我以前从未有过这么大的网站），所以任何输入都是非常好的

问题
由于所有的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.
-->

<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
-->


我的最后一个问题是关于减少网页加载的主要原因——jQueryAPI文件和网页字体。由于它们无论如何都会占用HTTP请求，您会建议直接从jQueryCDN和Google外包，而不是在本地托管文件吗？我提出这个问题是因为我认为CDN的服务速度会更快。不过，我会尽可能利用服务人员来减少下载文件的需要

非常感谢。
感谢您阅读这篇长文章。我知道我可能讲得太详细了，但我不想遗漏任何可能重要的内容。
以下是我对您提出的问题的看法：
1） 加载文件时，浏览器可以打开到单个服务器的多个并行连接。然而，问题在于这些连接的数量有限。加载一个76.5 KiB的文件通常比加载3个25 KiB的文件慢。这并不总是正确的，因为服务器握手时间“可能”大于实际获取资源所需的时间，尤其是在文件大小为70Kibs且平均互联网速度不断提高的情况下。我想最好的解决方案在很大程度上取决于您所针对的地理区域。
以下是关于并联极限的讨论：
2） 同样的谓词也适用于js文件。然而，如今jQuery几乎是全球性的。有一个非常非常高的机会，用户已经访问了一个网站，需要在来到您的网站。因此，使用流行的CDN