监控和优化网站性能

性能良好的网站不仅能提升用户体验，还能提升可访问性、搜索引擎排名、转化率等等。要保持最佳性能，需要持续监控网站，及时发现性能下降的迹象。

本文探讨了与网站性能相关的关键概念以及您应该关注的原因。我们分享了一些实用的见解、工具和技巧，以帮助您监控和提升网站性能。

在本文中，我们将介绍：

如何解读网络请求瀑布
您可能会遇到的常见性能问题
如何处理大型网页资源
可用于测试网站性能的工具
如何监控网站的性能
可以采用的技术来优化性能

页面加载性能与运行时性能

虽然页面加载性能和运行时性能关注的是 Web 性能的不同方面，但它们并不是完全不同的概念。让我们分别来看一下：

页面加载性能

页面加载性能是指网页的初始加载。在页面加载过程中，会发出网络请求来获取 HTML、CSS、JavaScript、图像和字体等资源。这些网络活动可以通过网络请求瀑布图来直观呈现。该图显示了资源的下载顺序以及每个资源的加载时间。

在讨论页面加载性能时，需要了解以下一些有用的指标：

第一个字节的时间（TTFB）：服务器响应第一个数据的速度
首次内容绘制 (FCP)：页面上第一个内容的显示速度
最大内容绘制 (LCP)：主要内容在页面上显示的速度

运行时性能

运行时性能是指浏览器在屏幕上获取像素的速度以及页面对用户交互的响应速度。

网络资源下载完成并不意味着屏幕上会显示任何有意义的内容。运行时性能可以帮助您了解页面交互和可用性的速度。

与运行时性能相关的一些指标包括：

交互到下一次绘制（INP）：页面对用户交互的响应程度
JavaScript 执行：浏览器执行 JavaScript 代码的速度有多快
渲染性能：页面显示变化的速度

使用网络请求瀑布

网络请求瀑布图是一种可视化图表，用于展示浏览器如何随时间加载网页资源。这有助于您了解页面加载体验。大多数网络请求瀑布图还包含一个幻灯片，即一系列网站截图，用于展示页面随时间加载的情况（如下方的请求瀑布图所示）。

您可以使用我们的“网站速度测试”为您的网站生成网络请求瀑布图。此工具在受控的实验室环境中测试您的网站，并为您呈现网络活动可视化。

注意： DebugBear 等工具和浏览器开发者工具是调查网站性能问题的补充工具。两者结合使用，您将拥有更全面的方法来发现和解决性能问题。

此报告记录网站的页面加载体验。它显示了许多实用的性能指标，并提供了指向其他数据的链接，例如Lighthouse报告和瀑布视图的请求。

DebugBear 网站速度测试结果。报告显示了一些 Web 性能指标，例如首字节访问时间、最大内容点等。用户界面还包含一个侧边栏，其中包含指向 Lighthouse 报告、实验等内容的链接。

当您单击左侧窗格上的 “请求” 选项时，您将看到“请求瀑布”视图。

DebugBear 请求瀑布视图。图片的不同部分已用 1 到 4 的数字标记。

上图中的编号标签对应以下组件：

过滤选项：提供仅查看 CSS 资源或仅查看 HTML 资源的选项。
查看下拉菜单：更改胶片的外观，并显示/隐藏瀑布上的列。
胶片视图：显示此报告中捕获的页面加载的视觉进程。
请求：列出此录制期间发生的各个请求。

在瀑布图中，每一行代表一个网络资源，例如 HTML 文件、CSS 文件或图像文件。资源在以下关键方面可能存在显著差异：

优先级：浏览器根据资源的重要性确定其优先级。
大小：资源大小可能有所不同，从而影响下载时间和带宽使用情况。
阻塞行为：某些资源会延迟其他资源的加载。
类型：每种类型的资源都有自己的加载行为，由浏览器管理。

瀑布图中资源从上到下的顺序与资源的下载顺序相对应。关键资源应放在顶部，次要资源应放在底部。

了解瀑布元数据

DebugBear 的网络请求瀑布视图提供了每个请求的元数据。元数据以每行资源的列形式显示：

DebugBear 请求瀑布中的类型、URL、域、优先级、持续时间和大小标头

您可以通过点击单个资源来查看其他元数据。要自定义元数据列，请点击“列”下拉菜单，然后切换要查看的列。一些值得关注的元数据包括：

优先级：表示浏览器对资源的加载优先级
DNS：解析域名所需的时间
TTFB（第一个字节的时间）：服务器响应所需的时间
全尺寸：资源未压缩的大小
协议：使用的网络协议（例如 HTTP/2、HTTP/3）

网络请求瀑布图显示了渲染里程碑。您可以使用渲染里程碑（显示为垂直彩色线）来了解网络活动如何影响页面渲染。

红色垂直线表示最大内容绘制（LCP），而蓝线表示首次内容绘制（FCP）。

DebugBear 瀑布线显示 FCP 和 LCP

使用瀑布模型来识别性能问题

分析瀑布流时，请查找可能影响网站性能的模式和问题。以下是三个最常见的问题：

渲染阻塞资源

阻塞渲染资源是指会延迟页面初始渲染的资源。请考虑以下代码示例：

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Online Shop</title>
  </head>
  <body>
    <p>Cookie banner</p>
    <script src="cookie-banner.js"></script>
    <h1>Shop for clothes</h1>
  </body>
</html>

在这种情况下，cookie-banner.js脚本会阻止元素的渲染<h1>。

事实上，许多网站在<head>HTML 文档的元素中包含了阻塞渲染的资源，这可能会延迟整个页面的渲染。无论是 CSS 还是 JavaScript，DebugBear 都会在网络请求瀑布图中高亮显示阻塞渲染的资源，从而更容易地直观地看到这些问题发生的位置：

对于阻止渲染的 JavaScript 文件，您可以将该async属性应用于<script>元素，以防止其阻止页面的渲染。

长请求链

当资源相互依赖时，请求链就会变长，从而形成级联请求。以下是一个请求链的示例：

index.html（第一个请求）：

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Online Shop</title>
    <script src="app.js"></script>
  </head>
  <body>
    <h1>Loading...</h1>
  </body>
</html>

app.js（第二个请求）：

import analytics from "./analytics.js";
import home from "./home.js";

document.addEventListener("DOMContentLoaded", () => {
  analytics.init();
  home.init();
});

home.js（第三个请求）：

function init() {
  const response = await fetch('/message');
  const message = await response.text();
  document.querySelector('h1').textContent = message;
}

export default { init };

此示例展示了一个index.html文件加载另一个app.js文件，而该文件又加载另一个home.js文件的过程。虽然此示例较为简化，但它说明了较长的请求链会对页面加载体验产生怎样的影响。

注意：/message仅在事件发生后调用端点这一事实DOMContentLoaded进一步加剧了问题，因为DOMContentLoaded不需要通过网络获取消息。

浏览器非常擅长预测并获取可以从主 HTML 文件中发现的资源，但是当使用长请求链时，这种能力就会丧失。

错过预加载机会

有时，关键资源的加载速度会有所偏差。通常，可以通过从较长的请求链中移除关键资源，并确保其在主 HTML 文档中可被发现来实现提前加载；然而，有时这并非易事。

如果无法避免较长的请求链，则可以通过使用关键资源<link rel="preload">元素（例如 LCP 图像元素）来缓解该问题。

例如，按照前面的长请求链示例，index.html可以更新文件以预加载home.js文件和消息端点，如下所示：

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Online Shop</title>
    <link rel="preload" href="home.js" as="script" />
    <link rel="preload" href="/message" as="fetch" />
    <script src="app.js"></script>
  </head>
  <body>
    <h1>Loading...</h1>
  </body>
</html>

Chrome DevTools 的性能面板中会显示“LCP 图像在最早的起始点之后 X 秒加载”的消息。这可以帮助您识别错过的预加载机会。要找到此功能，请使用 DevTools 对页面加载进行性能记录，然后从性能洞察侧边栏中打开“LCP 请求发现”部分。

DevTools LCP 图像详细信息

在 DebugBear 请求瀑布视图中，点击单个资源，并将“显示请求发起链”设置为开启，即可查看较长的请求链。下图中的请求链显示，字体文件（最后一个资源）由发起，typography.css,而又由发起style.css，而是从主文档中请求的。

请求瀑布视图中的 DebugBear 请求链

处理大量资源

在 Web 开发领域，人们普遍认为大型资源会影响 Web 性能。当您的页面包含大型资源时，可能会导致：

页面整体加载时间较慢
数据使用量增加，对于使用计量连接的用户来说，这可能会带来高昂的成本
移动设备的电池消耗更高
带宽拥堵，影响其他资源的加载

注意： 大型资源的影响不仅仅在于下载时间。浏览器还需要解析并执行代码（即使未使用），这对于大文件来说尤其耗时。

如何识别大型资源

要查找大型资源，请按大小对瀑布视图中的资源进行排序。在 DebugBear 中，您可以点击“完整大小”或“大小”列标题，分别按未压缩或压缩后的大小对资源进行排序。最大的资源显示在顶部，这样您就可以轻松识别特别大的资源。

HTML/CSS 尺寸分析

较大的资源通常归因于图像，但较大的尺寸也可能是由文本代码/内容造成的，例如：

HTML：主页文档中的标记过多
JavaScript：由第三方库或未使用的代码组成的大型捆绑包
CSS：臃肿的样式表，包含未使用的规则

DebugBear 提供HTML和CSS 大小分析工具，帮助您分解这些文件的组成。这可以帮助您找出需要改进的地方，例如删除未使用的样式或优化标记。

以下屏幕截图展示了 HTML 标记的大小分析。在此示例中，JavaScript 框架出于数据融合 (hydration)<script>的目的，将页面上的文本内容复制到一个元素中。即使进行了压缩，这也会导致网络字节浪费，并且浏览器需要额外的解析时间来处理元素内的数据。<script>

DebugBear HTML 大小分析显示，段落元素中的文本内容和脚本元素中的内容大致平均分布，各约占 50%

JavaScript 大小分析

为了深入分析 JavaScript 的使用情况，浏览器 DevTools（Edge 或 Chrome）中的“覆盖率”选项卡可以显示在页面加载期间实际使用了多少 JavaScript（和 CSS）。

Chrome DevTools 覆盖率面板

虽然 DebugBear 没有提供特定的 JavaScript 大小分析器，但如果您的捆绑包包含 JSON 数据，您可以使用其JSON 大小分析器工具。

优化资源规模的方法

一般来说，无论资源有多大，都有标准的方法来优化大小，包括：

摇树：从包中删除未使用的代码。
代码拆分：将代码拆分成更小的块，以便在页面加载期间仅加载所需的代码。将非关键代码推迟到需要时或页面加载完成后再加载。
压缩：使用 Brotli 或 Gzip 压缩基于文本的文件，使用 WebP 或AVIF等现代格式压缩图像，以减少资源的大小。

优化页面渲染

页面资源下载完成后，浏览器会构建页面并将其显示在屏幕上。有些网站的资源加载速度非常快，但页面渲染速度却很慢，反之亦然。以下是一些常见的渲染问题及其解决方法。

缓慢的网页字体

根据浏览器和font-display已设置的任何 CSS 属性，使用加载缓慢的Web 字体会有效阻止页面上文本内容的呈现。

即使最初使用了系统后备字体，延迟加载的网络字体也可能导致布局偏移，从而影响用户体验。发生这种情况的原因是，浏览器最初使用后备字体渲染页面，然后在加载后将其替换为网络字体。如果后备字体和网络字体的尺寸和指标不同，则可能会导致布局偏移。

为了缓解这些问题，您可以执行以下一项或多项操作：

如果您的网络字体并非始终需要使用，您可以将font-display: optional或font-display: fallbackCSS 属性应用于font-face声明。这允许浏览器管理网络字体的显示，从而平衡性能和用户体验。至少，使用font-display: swap，可以确保在网络字体加载完成之前使用后备字体。
您可以预加载 Web 字体文件，这通常很有效，因为字体有时是在 CSS 文件中指定的。CSS 文件在 HTML 文件之后加载，从而创建了一个请求链。
您可以使用字体描述符来更好地将后备字体与 Web 字体匹配，从而减少布局偏移。