前面我们已经探索了各种改进页面加载时间的方法。

文本内容的加载性能

图像内容的加载性能

HTTP Requests

HTTP缓存

这些技术可视为“唾手可得的果实”——通过简单的努力就能产生巨大的性能提升。说说容易，我们还没有真正看到这些技术的实际应用，本篇我们就来完成实践吧。

为了证明这些技术的有效性，我们将对不同版本的网页运行各种速度测试，从不进行优化开始，逐步介绍我们讨论过的一些加速技术，特别是文本资源优化、图形资源优化和 HTTP 请求减少。

目标很简单，通过包含 文本、图像、CSS和JavaScript的单个 HTML 页面，开始我们的优化实践。相关文件可以参考此开源项目。

页面速度的主要考虑因素之一是首次有意义的绘制 (FMP)，它衡量用户如何看待页面性能。 FMP 是指页面的主要内容出现在屏幕上所需的时间。 当然，“主要内容”的定义可能因页面类型而异。 对于新闻文章，主要内容可能是标题和“首屏”文字； 对于搜索引擎页面，主要内容是其搜索结果； 对于艺术博物馆页面，主要内容可能是一系列缩略图和简短描述。

另一个主要因素是原始加载速度，衡量从第一个下载字节到页面完全加载所需的时间。 虽然这是一个经验观察，但它可能无法准确反映用户对可用内容的感知。 也就是说，在页面加载在技术上完成之前很久，可查看的内容就可能在屏幕上并被认为是可用的。

显然，“页面加载速度”的感知与其字面测量相反，它是用户体验的一个主观方面，并受许多因素的影响。 感知性能是页面加载速度的主要指标，进而是用户满意度。 虽然完全客观的测量最终可能是不可能的，但这也并不意味着我们只能猜测。

 

测试工具

有很多很多的工具可以帮助确定页面的加载速度，这里就不一一列举了。 对于本文，我们将使用三个在线服务来帮助我们查看改进工作的结果。

• Google PageSpeed Insights

• WebPageTest

• Pingdom

为什么要三个工具？ 因为不同的测试服务使用不同的方法和算法来测试速度； 他们在不同位置的不同机器和浏览器上运行测试； 他们报告不同的结果，并以不同的方式报告。 您可能会感到不安的是，同一个页面可以在不同的工具之间进行完全不同的测试，但这就是测试的现实。

与其认为这是负面的，不如将其简单地视为获得更多更好数据的一种方式。 没有单一的测试工具可以为您提供完整的故事。 不要依赖一种工具，而是使用多种工具并多次运行测试，以获得关于页面特定焦点的最佳和最多信息，然后进行相应调整。

 

原始页面

让我们通过查看原始页面上的各种性能审计来获得基线。 诚然，它非常草率——原始文本、渲染阻止程序、大图像、太多外部文件——但它最终会按应有的方式加载和显示。 我们的工作是使用可用的工具来确定一些我们可以根据我们在前面文章中看到的改进的具体内容。 这是页面的一部分。

今日启示录主页

 

我们就用它来进行测试。（原始文件对应开源项目中的 pageload0.html 文件）

注意：您可能通过相同的服务运行相同的页面并获得不同的结果。 同样，这就是测试的现实。

 

PageSpeed Insights 页面评分很差，分别为移动设备提供 48/100 分和桌面设备 50/100 分，但没有给我们提供原始加载时间。 在它的观察中，它正确地指出页面的 HTML、CSS 和 JavaScript 没有被缩小。

PageSpeed Insights, 原始页面

 

Pingdom 给予页面“B”评级和 81/100 分，这听起来还不错。 但是，更有用的是，它报告了低于标准杆 4.73 秒的加载时间，并将该页面排在它测试过的其他站点中，仅将其置于第 33 个百分位。

Pingdom, 原始页面

 

WebPageTest 默认情况下运行三个连续的测试并对结果进行平均，这是测试服务中的一个独特功能。 它的结果包括 2.743 秒的文档完成加载时间和 2.831 秒的总加载时间，两者都明显少于 Pingdom 的报告。

WebPageTest, 原始页面

WebPageTest 还包括许多图形报告，包括幻灯片和视频视图（都非常好），以及这些方便的内容分解饼图。

WebPageTest, 原始页面

如您所见，原始页面的加载特性不是很好。 明显的是，各种工具并未以相同的方式测量和报告其特征。 因此，最好的方法是专注于几个主要的改进途径，并在每次更改后重新测试以确定它是否达到了预期的效果。

 

文本内容

我们的演示页面主要由基于文本的资源组成：主要的 HTML 页面内容和结构加上一个或多个级联样式表和 JavaScript 文件。 该文本可能不是页面的主要问题，但它是一个开始的地方，因为它可以全部缩小以节省下载时间。

使用文本内容的加载性能文章中提到的一些工具，我们缩小了 HTML、CSS 和 JavaScript，并将站点重新部署到服务器。

PageSpeed Insights 提交了一份适度但有趣的报告，正确地指出修改后页面的 HTML、CSS 和 JavaScript 被缩小了。

PageSpeed Insights, 文本资源最小化

移动端和桌面端的分数都只提高了 1%（分别为 49 和 52），这表明缩小的效果很小。 但事实上，缩小文本资源导致实际字符数减少了 32%。 因为这是一个相当小的页面，所以由此带来的速度提升并不大，但大小减小的百分比却非常显着。

和以前一样，没有原始速度数字，但即使是这份报告也表明删除空格会加快您的页面速度。

Pingdom 的总体成绩没有变化，但页面加载时间下降了 1.3 秒，百分位排名跃升至 47。

Pingdom, 文本资源最小化

此处的加载时间改进比 PageSpeed Insights 报告中的更为明显，而且一秒钟以上的加速肯定是一个值得付出很少努力的结果。

WebPageTest 有趣的是报告中文档完成或总加载时间没有显著变化。

WebPageTest, 文本资源最小化

但是，将鼠标悬停在内容细分图表中的（小）饼片上会显示字符数和文本组件的相对比例显著减少：HTML（以前为 11,886/0.9%，现在为 9,237/0.7%）、CSS（ 之前为 4,443/0.4%，现在为 3,295/0.3%）和 JavaScript（之前为 14,471/1.2%，现在为 8,060/0.6%）。 个别数字似乎很小，但事实是缩小使文本资源总体减少了近三分之一。

WebPageTest, 文本资源最小化

有趣的是，尽管整体原始速度没有提高，但 WebPageTest 的报告显示其内部算法的两个结果走向不同的方向。 该页面的速度指数从 1699 上升到 1797（慢了大约 5%），其首次交互时间（测试版功能）从 1.266 秒下降到了 1.133 秒（快了大约 10%）。 虽然这些测量有些主观，但它们仍然会影响用户感知网站的速度。 永远记住，用户感知是性能的最终仲裁者。

更新：“首次交互时间”指标正在弃用，取而代之的是更准确的“持续交互时间”。 我们鼓励您使用 WebPageTest Easy 模式并选择 Mobile 复选框，这将生成 Lighthouse 报告。 然后单击页面顶部的 Lighthouse PWA 分数以查看完整的 Lighthouse Progressive Web App 报告，包括新的 Consistently Interactive 指标。

文本资源最小化的版本: pageload1.html

 

图像内容

此页面中另一个需要改进的领域是过度/滥用图像。 这并不是说图像对页面不重要，只是它们可以更好地处理。 再看看上面的 WebPageTest 饼图； 页面的图像占 HTTP 请求的 53.3% 和下载字节的 98.3%。

原始页面中有八张图片：五张主要文章图片、老式 Lucies 广告以及拉引语周围的开头和结尾引语图形。 Pingdom 的附加图表之一说明了等待和下载图像所花费的时间。

Pingdom, 原始页面

这里有很大的改进空间。

基于图像内容的加载性能文章中讨论的技术，我们对图像（甚至是小图像）进行了各种改进，包括：

• 物理尺寸调整

• 建立最佳格式

• 降低质量

• 压缩

• 移除 metadata

注意：对于本次测试和本文中的所有后续测试，我们始终从原始的、未修改的页面开始，并制作所有资源的新副本，以防止任何一个测试的程序或结果污染另一个测试。

以下是每个图像的改进结果。

值得在这里报告一些关于改进过程的观察。

1. 虽然一些 jpg 图像在另存为 gif 时稍微小一些，但它们的质量明显受到影响。 因此，在每种情况下，“最佳”文件类型都是原始文件类型，即使它比最小的另存为类型大一点。

2. 由于视觉检查而导致的任何尺寸保留都完全通过物理尺寸（宽度/高度）的减小和图像压缩来补偿。 文章的主图尺寸减少了三分之一，从 900x500 像素减少到 600x333 像素。 有趣的是，这 33% 的减少通常会导致 50% 的文件大小差异。

3. 尽管在默认设置（没有特殊调整）下对大图像进行压缩时，结果既低得惊人（3%），又高得令人满意（50%），但整体上最大的改进因素是 jpg 质量的降低。 所有 jpg 文件都以 50% 的质量保存，但仍保持其视觉清晰度，从而在没有视觉感知成本的情况下产生更小的文件大小。 （我们可能本来可以以更低的质量保存它们，但停止在 50%。）

现在让我们看看图像改进如何影响页面加载时间。 请记住，此版本基于原始页面，而不是文本资源缩小的版本，因此这些结果仅反映与图像优化直接相关的改进。

 

PageSpeed Insights 报告移动和桌面环境的显着改进。 尽管图像加载速度肯定更快，但它们可能仍然太大（宽度/高度），无法舒适地放在某些移动屏幕上。

PageSpeed Insights, 优化图像版本

 

Pingdom 没有升级网站的整体性能等级，但确实显示出比原来更快的加载时间和更好的百分位排名。

Pingdom, 优化图像版本

Pingdom 的时间线报告还显示图像的等待/加载时间显著改善。 他们访问浏览器的速度比以前快得多。

Pingdom, 优化图像版本

 

WebPageTest 报告对于文档完成和完全加载状态，比原始加载时间快得多。

WebPageTest, 优化图像版本

并且，在其内容细分图表上，请注意，虽然图像请求数占总请求数的百分比当然没有改变（我们将在下面讨论 HTTP 请求），但图像字节数占下载总字节数的百分比已经 急剧下降，从 98.3% 降至 75.8%。 也就是说，浏览器下载图片的时间比以前减少了 22.5%，这是一个显着的改进。

WebPageTest, 优化图像版本

优化图像版本：pageload2.html

 

HTTP 请求

回想一下，页面的加载速度不仅取决于它必须下载的资源的大小，还取决于它必须下载的资源数量。 因此，HTTP 请求的数量（每个资源一个）成为加载速度的重要因素。 但是，如果一个站点确实需要一组特定的资源来正确显示和运行——CSS、JavaScript、图像——我们如何在不遗漏必要资源的情况下减少 HTTP 请求的数量？ 答案：合并资源。

原始的 HTML 页面（我们总是用于新测试）有 14 个外部资源：3 个 CSS、3 个 JavaScript 和 8 个图像。 使用 HTTP 请求文章中概述的技术，我们首先将 CSS 资源合并到一个文件中，并将 JavaScript 资源合并到一个文件中，立即消除了四个 HTTP 请求。

接下来，我们将主要的 JavaScript 标记从页面头部（它会阻止页面渲染）移到页面末尾，它可以在内容渲染后加载。 虽然这不会删除 HTTP 请求，但它会从根本上改变请求的时间，从而导致感知速度提升。

我们采用的另一种 JavaScript 技术是“内联推送”，其中少量代码直接插入到 HTML 页面中，用于修改页面内容。 为了实现这一点，我们将“早上好/下午/晚上”问候脚本内联，紧跟在它修改的 <h2> 之后。 因此，它是随页面加载的，而不是通过外部 HTTP 请求加载的，它会在 DOM 中的标题可用的那一刻执行，明显地更新内容并再次导致感知速度增益。

最后，我们尽可能合并图像。 幸运广告是独立的，但拉引语上的开头和结尾引语图像是不错的候选者，页面主要文章中的五个英雄图像也是如此。 通过将两个拉引号图像合并到一个文件中并将五个主图像合并到一个文件中，我们消除了另外五个 HTTP 请求。

这种技术需要添加一些简单的 CSS 来移动图像，并对 HTML 进行一些小的更改以适应组合的图形，但所有这些都是用不到一千字节（即将缩小）的代码完成的，这是一个很好的折衷方案。

总体而言，我们将 HTTP 资源请求的数量从 14 个减少到 5 个（不包括 HTML 页面本身），而不会牺牲一个字节的内容。 让我们看一下测试服务的结果。

PageSpeed Insights 再次报告移动和桌面环境的改进。 它仍然可以识别出该页面具有未缩小的文本和未优化的图像，但请记住，我们正在使用原始页面并且仅在此测试中测量 HTTP 请求的效果。

PageSpeed Insights, 减少HTTP请求

 

Pingdom 报告加载时间为 1.18 秒，百分位排名为 86，与原来的 4.73 秒和第 33 个百分位相比有了很大的改进。

Pingdom, 减少HTTP请求

在其报告的另一部分中，Pingdom 确认 HTTP 资源请求从原始页面中的 14 个减少到此版本中的 5 个（再次打折 HTML 页面）：3 个图像、1 个 CSS 和 1 个 JavaScript。

Pingdom, 减少HTTP请求

 

WebPageTest 不仅报告了加载时间的显着差异，文档完成和完全加载，而且还显示了 HTTP 请求的差异——原始页面中的 16 个和此版本中的 7 个。 （为什么此测试服务报告的 HTTP 请求比其他服务多一个，原始报告 15 个，此版本报告 6 个，在撰写本文时尚未确定。如果有解释，本文将更新。）不过，总体差异 9 是准确的。

WebPageTest, 减少HTTP请求

该服务的内容分解饼图也很有用。 注意字节图表中较高的图像编号； 这实际上是意料之中的，因为虽然图像字节数没有增加，但图像字节数占总字节数的百分比却增加了。 这是因为将多个文本资源合并到一个文件中，以及内联了一些 JavaScript。

WebPageTest, 减少HTTP请求

更有趣的是请求图表。 同样，虽然图像请求的数量实际上下降了 63%，但图像请求数量占总请求的百分比几乎不低于原来的数量（从 53.3% 下降到 50.0%）。 为什么？ 因为 HTML、CSS 和 JavaScript 请求——现在它们的资源被合并并且它们的请求数量减少了——在总数中所占的比例要大得多，这表明 HTTP 请求的整体减少已经平衡了这样的竞争环境 那不再那么重图像了。 换句话说，在这个版本中，浏览器加载图像的服务器点击次数并不多于加载所有其他资源的总和。

减少HTTP请求版本：pageload3.html

 

将所有优化融合

现在我们已经看到了个别技术带来的一些速度改进，让我们看看当我们在一个版本中应用所有技术时会发生什么。 对于此测试，我们采取了以下步骤：

• 最小化 HTML、CSS 和 JavaScript 文件

• 优化图像

• 合并 CSS 和 JavaScript 文件，引用以及“英雄”图像

我们是怎么做的？

 

PageSpeed Insights 为移动和桌面环境的页面提供良好的数字。 如前所述，由于（仍然）相当大的图像，移动分数可能会受到一些影响。

PageSpeed Insights，所有优化集合

 

Pingdom 报告了迄今为止最好的结果——加载时间不到半秒，在测试页面的第 97 个百分位。

Pingdom，所有优化集合

 

WebPageTest 它的文档完成和完全加载分数也显示出显着提高，并且其（测试版）首次交互时间不到一秒。

WebPageTest，所有优化集合

所有优化集合版本：pageload4.html

小结

我们可以从所有这些技术、测试和报告中得到什么？ 让我们看一下来自各种测试运行的一些基本数字。

可以确定的是，不同的测试工具可以对同一页面进行非常不同的评分。 这也正确地意味着您使用的工具越多，您拥有的数据就越多，可用于做出明智的优化决策。

另一个有用的观察是，似乎实现了最佳单速提升的技术是图像优化。 这并不奇怪，因为对于我们的页面（与许多典型的网页一样），图像在总下载内容中所占的比例不成比例。

最后，虽然各种技术的数字往往有点跳跃，但令人满意的是，当我们应用所有技术时，我们实现了整体最快的加载和交互时间，以及在其他测试页面中的最高百分位排名 立刻。

从这些测试中可以清楚地看出，您可以对加载缓慢的页面采取的改进技术越多，您的速度就越快，您的用户体验就会越好。