2

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

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

来自Render-Blocking Resources文章，这里是最重要的摘录（CSS 文章作为一个整体基本上更详细地进行了这一点）：

  • 对于关键脚本，请考虑将它们内联到您的 HTML 中。对于非关键脚本，请考虑使用asyncordefer属性对其进行标记。请参阅添加与 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 文件和网络字体。由于它们无论如何都会占用 HTTP 请求，您是否建议直接从 jQuery CDN 和 Google 外包，而不是在本地托管文件？我提出这一点是因为我假设 CDN 的服务速度会更快。但是，我会尽可能利用服务人员来减少下载文件的需要。

谢谢你！

感谢您阅读这篇长文。我知道我可能已经介绍了太多细节，但我不想遗漏任何可能很重要的内容。

4

3 回答 3

1

我希望我的渐进式 Web 应用程序（Angular、AWS 无服务器）的网站免费获得高评价。我得到的评分如下图所示。这就是我对你的问题的建议......

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

2）你真的使用很多jquery吗？为获得最佳效果，您可能想要编写 vanilla javascript 而不是在首屏内容中使用 jquery。在我的网站https://beta.akberiqbal.com中，我为首屏项目（导航等）编写了纯 JavaScript。在折叠之下，我有我的三个 Angular5 JS 文件。bundle.css 文件很小，所以我也将它作为 HTML 的一部分。

3）如果你有一个服务工作者应用程序，本地获取应该比 CDN 更快。

在此处输入图像描述

于 2018-05-02T12:57:12.607 回答
1

问题 1：您可以保留单独的 css 文件以便于编辑。使用 vswebessentials 为生产版本捆绑和缩小。当您在服务器上托管它时，设置一个遥远的未来到期日期或使用缓存清单。然后，您需要在进行更改时重命名捆绑文件。网站将工作得更快。

通过单个连接下载时，今天的 75kb css 并不大，如果您提供了一个遥远的未来到期日期，并且您的客户没有对该域的任何其他日期提出其他请求。希望您不会每天都更改 CSS。您也可以根据媒体查询规范对其进行分解。

问题 2 从 cdn 加载 jquery 是个好主意，但您需要确保它在您的 js 执行之前可用。不要将服务人员用于更简单的事情。如果你想查，审计 www.google.co.in，你的审计数字可能比 google 好。所以，不要用审计数字使开发复杂化。专注于用户体验。这就是谷歌正在做的事情。

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

于 2017-08-28T12:49:26.563 回答
1

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

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

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

不需要立即执行的 javascript 代码应该异步加载或延迟加载。你对这两个做什么进一步取决于你所针对的浏览器。较旧的浏览器不会看到延迟加载的任何优势。参考：脚本标签 - 异步和延迟

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

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

我还建议推迟加载用于设置内容样式的 CSS，而不是修复布局。这包括所有的颜色、字体和其他花哨的东西。

如果您的目的是在 Chrome 审核中获得高分，那么我提到的事情可能不正确。但是对于服务实际用户，这是我个人会做的。

于 2017-08-10T08:37:51.870 回答