利用 Performance API 进行首屏加载耗时分析：指标 FP、FCP、LCP 的归因 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同学，大家下午好！

今天，我们将深入探讨一个对用户体验和业务成功至关重要的主题——首屏加载耗时分析。在当今快节奏的互联网世界中，用户对网站或应用的速度有着极高的期望。一个缓慢的加载体验不仅会劝退用户，导致流量流失，更可能对品牌形象造成负面影响。因此，理解并优化首屏加载性能，是每一位前端开发者和架构师的必修课。

我们将利用浏览器提供的强大工具——Performance API，来精确测量并归因首屏加载过程中的关键指标：FP (First Paint)、FCP (First Contentful Paint) 和 LCP (Largest Contentful Paint)。通过这次讲座，我希望大家不仅能学会如何测量这些指标，更能理解它们背后的含义，以及如何通过代码层面的分析，找到性能瓶颈并进行优化。

1. 引言：为什么首屏加载如此重要？

想象一下，你打开一个网站，屏幕一片空白，或者只有导航栏，迟迟不见核心内容。你会怎么做？大概率是关闭页面，转向其他竞争对手。这就是慢速首屏加载的代价。

首屏加载（First Screen Load）指的是用户在浏览器中输入网址后，到页面主要内容首次呈现给用户，使其能够感知到页面正在加载并开始交互的这一段时间。它直接影响着用户的首次印象和等待体验。

核心影响：

用户体验 (User Experience, UX)：快速响应的页面让用户感到愉快和高效。
业务转化 (Business Conversion)：研究表明，加载时间每增加一秒，转化率就可能下降数个百分点。
搜索引擎优化 (Search Engine Optimization, SEO)：Google 等搜索引擎已将页面加载速度纳入其排名算法，更快的网站更容易获得更好的搜索排名。
用户留存 (User Retention)：良好的初始体验有助于用户长期使用。

为了量化和优化首屏加载，我们需要一系列指标。今天，我们将聚焦于 Web 性能领域最核心的三个可视化指标：FP、FCP 和 LCP。

2. Performance API 基础：浏览器性能分析的利器

在过去，我们可能通过 Date.now() 或者一些简单的计时器来测量代码执行时间。但这些方法对于测量复杂的页面加载过程来说，显得过于粗糙和不准确。幸运的是，现代浏览器提供了强大的 Performance API，它允许我们以高精度、高分辨率的方式访问浏览器内部的性能数据。

window.performance 对象是 Performance API 的入口。它提供了许多方法和属性，用于测量页面导航、资源加载、用户计时、长任务等。

2.1 `performance` 对象简介

performance 对象的核心特性包括：

performance.timing：（已废弃，但仍有参考价值） 提供了页面加载各个阶段的时间戳。
performance.now()：返回当前时间戳，精度可达微秒，相对于 performance.timeOrigin。
performance.getEntries()：返回一个包含所有性能条目的列表。
performance.getEntriesByType(type)：按类型过滤性能条目，例如 'resource', 'navigation', 'paint' 等。
performance.mark() 和 performance.measure()：用于自定义性能测量。

2.2 `PerformanceObserver`：异步监听性能事件

PerformanceObserver 是 Performance API 中最为强大的工具之一，它允许我们异步地观察和收集特定类型的性能条目。这意味着我们不需要轮询 getEntriesByType()，而是在浏览器生成新的性能数据时得到通知。这对于实时监控和报告性能指标至关重要。

// 创建一个 PerformanceObserver 实例
const observer = new PerformanceObserver((list) => {
    // 当有新的性能条目出现时，这个回调函数会被调用
    for (const entry of list.getEntries()) {
        console.log('新的性能条目：', entry.name, entry.startTime, entry.duration);
        // 根据 entry.entryType, entry.name, entry.startTime 等属性进行处理
    }
});

// 告诉 observer 我们对哪些类型的性能条目感兴趣
// 'paint' 类型用于 FP 和 FCP
// 'largest-contentful-paint' 类型用于 LCP
// 'resource' 类型用于所有资源的加载
// 'navigation' 类型用于页面导航
// 'longtask' 类型用于识别耗时任务
observer.observe({ entryTypes: ['paint', 'largest-contentful-paint', 'resource', 'navigation', 'longtask'] });

// 在适当的时候断开观察者，避免内存泄漏
// observer.disconnect();

2.3 `performance.getEntriesByType()`：同步获取性能条目

虽然 PerformanceObserver 是推荐的实时监控方式，但在某些情况下，例如在页面加载完成后一次性获取所有已发生的性能事件，getEntriesByType() 仍然非常有用。

// 获取所有已发生的 paint 事件（FP 和 FCP）
const paintEntries = performance.getEntriesByType('paint');
console.log('所有 paint 事件：', paintEntries);

// 获取所有已发生的资源加载事件
const resourceEntries = performance.getEntriesByType('resource');
console.log('所有资源加载事件：', resourceEntries);

// 获取导航事件
const navigationEntries = performance.getEntriesByType('navigation');
if (navigationEntries.length > 0) {
    const navEntry = navigationEntries[0];
    console.log('页面导航耗时：', navEntry.loadEventEnd - navEntry.startTime);
}

理解了这些基础工具，我们就可以开始深入测量和分析 FP、FCP 和 LCP 了。

3. 核心指标解析：FP、FCP、LCP

这三个指标是衡量用户感知加载速度的关键。它们反映了从用户请求页面到页面内容逐步呈现给用户的过程。

3.1 FP (First Paint) – 首次绘制

定义与意义：
FP 记录的是浏览器首次在屏幕上渲染任何像素的时间点。这可以是背景颜色、导航栏、或者任何非空白的内容。它标志着浏览器不再显示空白屏幕，用户开始感知到页面正在加载。FP 是所有可视化指标中最基础的一个，它告诉用户“页面有动静了”。

如何获取：
FP 可以通过 PerformanceObserver 监听 entryType 为 'paint'，且 name 为 'first-paint' 的性能条目来获取。

const fpObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-paint') {
            console.log('First Paint (FP) 时间:', entry.startTime, 'ms');
            // 在这里可以停止观察，因为 FP 只发生一次
            fpObserver.disconnect();
        }
    }
});

fpObserver.observe({ entryTypes: ['paint'] });

归因分析：什么会影响 FP？

FP 发生的早晚，主要受以下因素影响：

HTML 文档的下载与解析：浏览器需要先下载 HTML，然后开始解析。
CSS 阻塞渲染：在解析 HTML 遇到 <link rel="stylesheet"> 或 <style> 标签时，浏览器通常会暂停渲染，直到 CSS 资源下载并解析完成，因为 CSS 会影响页面布局和样式。
JavaScript 阻塞渲染：如果在 <head> 或 <body> 开头有不带 defer 或 async 属性的 <script> 标签，浏览器会暂停 HTML 解析，下载并执行 JavaScript 代码。
服务器响应时间 (TTFB – Time To First Byte)：服务器处理请求并返回第一个字节所需的时间。TTFB 直接决定了浏览器何时开始接收 HTML。

代码示例：FP 归因分析

为了更直观地看到这些因素的影响，我们假设一个简单的页面结构：

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>FP 分析示例</title>
    <style>
        body {
            margin: 0;
            background-color: #f0f0f0; /* 会影响 FP */
            color: #333;
        }
        .header {
            background-color: #007bff;
            color: white;
            padding: 20px;
            text-align: center;
        }
    </style>
    <!-- 引入外部 CSS，可能阻塞渲染 -->
    <link rel="stylesheet" href="slow.css">
</head>
<body>
    <div class="header">
        <h1>欢迎来到我的网站</h1>
    </div>
    <div class="content">
        <p>页面内容正在加载中...</p>
    </div>
    <!-- 引入外部 JS，可能阻塞渲染 -->
    <script src="blocking.js"></script>
</body>
</html>

slow.css 文件内容（模拟一个大文件或慢速加载）：

/* slow.css */
/* 假设这是一个非常大的 CSS 文件，或者模拟网络延迟 */
body {
    font-family: Arial, sans-serif;
}
/* 1000 行重复样式，模拟大文件 */
.some-class-1 { color: red; }
.some-class-2 { color: blue; }
/* ... 省略大量重复样式 ... */
.some-class-1000 { color: green; }

blocking.js 文件内容：

// blocking.js
// 模拟一个耗时且阻塞主线程的 JavaScript
console.log("Blocking JS 开始执行...");
const start = performance.now();
while (performance.now() - start < 500) {
    // 阻塞 500ms
}
console.log("Blocking JS 执行完毕!");

分析：

当浏览器加载 index.html 时，它会首先解析 <head>。
<style> 标签中的 background-color: #f0f0f0; 会让 body 有背景色。理论上，如果 slow.css 和 blocking.js 不存在，或者加载很快，那么 FP 应该在解析到 body 样式并应用后很快发生。
然而，slow.css 的存在会阻塞渲染。浏览器会等待 slow.css 下载并解析完毕，才能进行首次绘制。
blocking.js 在 <body> 顶部，也会阻塞后续的 HTML 解析和渲染，进一步推迟 FP。

通过 Performance API 测量，你会发现 FP 的时间点会显著滞后。

优化策略（FP 层面）：

优化服务器响应时间 (TTFB)：使用 CDN、优化后端代码、开启 Gzip 压缩。
关键 CSS 内联化 (Critical CSS)：将首屏所需的少量关键 CSS 直接嵌入到 HTML 的 <head> 中，避免外部 CSS 阻塞。
异步加载非关键 CSS：使用 media 属性或 JavaScript 动态加载非关键 CSS。
JavaScript 优化：将 <script> 标签移至 <body> 底部，或添加 defer/async 属性。

3.2 FCP (First Contentful Paint) – 首次内容绘制

定义与意义：
FCP 记录的是浏览器首次渲染任何文本、图片（包括背景图片）、非白色 <canvas> 或 SVG 的时间点。它比 FP 更进一步，意味着用户开始看到页面上的“有用内容”，而不仅仅是空白背景。FCP 是用户感知页面加载的关键里程碑。

如何获取：
FCP 也通过 PerformanceObserver 监听 entryType 为 'paint'，且 name 为 'first-contentful-paint' 的性能条目来获取。

const fcpObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-contentful-paint') {
            console.log('First Contentful Paint (FCP) 时间:', entry.startTime, 'ms');
            // 同样，FCP 只发生一次
            fcpObserver.disconnect();
        }
    }
});

fcpObserver.observe({ entryTypes: ['paint'] });

FP 与 FCP 的区别与联系：

FP 总是早于或等于 FCP。 FP 只要有任何像素渲染即可，而 FCP 必须是“内容”像素。
如果页面只有一个背景色，没有文本或图片，FP 会发生，但 FCP 不会发生，直到有内容被绘制。
通常情况下，FP 和 FCP 的时间点会非常接近，除非页面设计非常简单，FP 只是一个背景色，而内容（如文本）加载较慢。

特征	First Paint (FP)	First Contentful Paint (FCP)
定义	浏览器首次在屏幕上渲染任何像素的时间点。	浏览器首次渲染任何文本、图片、非白色 Canvas 或 SVG 的时间点。
感知	页面不再是空白，有动静。	页面开始显示有意义的内容。
触发条件	任何可见的像素变化（包括背景色）。	至少一个文本节点、图片、SVG 或 Canvas 元素被渲染。
时间关系	总是早于或等于 FCP。	总是晚于或等于 FP。
重要性	页面加载的第一个视觉反馈。	用户感知页面加载进度的关键指标。
影响因素	TTFB、HTML 解析、CSS/JS 阻塞。	TTFB、HTML 解析、CSS/JS 阻塞、字体加载、首屏图片/文本加载。

归因分析：什么会影响 FCP？

除了影响 FP 的因素（TTFB、HTML 解析、CSS/JS 阻塞）之外，FCP 还特别受到以下因素的影响：

字体加载：如果首屏文本依赖自定义字体（@font-face），且字体文件较大或加载缓慢，会导致文本无法立即渲染，直到字体文件下载完成。这会延迟 FCP。
首屏图片加载：如果首屏包含图片，且这些图片未优化（过大、未压缩、未懒加载）或加载缓慢，FCP 也会受影响。
DOM 复杂度与层级：过于复杂的 DOM 结构会增加浏览器解析和渲染的负担。
网络延迟：所有资源的下载都需要网络时间。

代码示例：FCP 归因分析

我们沿用之前的 index.html，并加入一个自定义字体和一张图片：

<!-- index.html (更新版) -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>FCP 分析示例</title>
    <style>
        /* 引入自定义字体，可能延迟文本渲染 */
        @font-face {
            font-family: 'CustomFont';
            src: url('custom-font.woff2') format('woff2'); /* 假设这个字体文件很大或加载慢 */
            font-display: swap; /* 重要的优化，但默认可能是 block */
        }
        body {
            margin: 0;
            background-color: #f0f0f0;
            font-family: 'CustomFont', Arial, sans-serif; /* 使用自定义字体 */
            color: #333;
        }
        .header {
            background-color: #007bff;
            color: white;
            padding: 20px;
            text-align: center;
        }
        .main-image {
            width: 100%;
            max-width: 600px;
            height: auto;
            margin-top: 20px;
        }
    </style>
    <link rel="stylesheet" href="slow.css">
</head>
<body>
    <div class="header">
        <h1>欢迎来到我的网站</h1>
    </div>
    <div class="content">
        <img src="large-hero.jpg" alt="英雄图片" class="main-image"> <!-- 首屏大图 -->
        <p>这里有一些重要的文本内容，它使用了自定义字体。</p>
    </div>
    <script src="blocking.js"></script>
</body>
</html>

分析：

slow.css 和 blocking.js 会像之前一样影响 FP 和 FCP。
现在，<p> 标签中的文本使用了 CustomFont。如果 custom-font.woff2 文件很大或加载缓慢，浏览器可能会在字体下载完成前显示空白文本（FOIT – Flash of Invisible Text），或者使用备用字体（FOUT – Flash of Unstyled Text，如果 font-display: swap 被设置）。无论哪种情况，如果首屏文本是 FCP 的主要内容，那么字体加载的延迟会直接影响 FCP。
large-hero.jpg 是一张首屏图片。如果它没有被优化（文件过大），其下载时间会显著增加，从而延迟 FCP。

优化策略（FCP 层面）：

优化字体加载：
- 使用 font-display: swap 属性，让浏览器立即使用系统字体渲染文本，待自定义字体加载完成后再替换，避免 FOIT。
- 字体子集化：只包含所需的字符。
- 预加载 (Preload) 关键字体：<link rel="preload" href="custom-font.woff2" as="font" crossorigin>。
优化首屏图片：
- 压缩图片、使用现代格式（WebP, AVIF）。
- 响应式图片 (srcset, sizes)，根据用户设备提供合适尺寸的图片。
- 优先加载首屏图片：移除懒加载属性，或使用 <link rel="preload">。
关键资源预加载/预连接：利用 <link rel="preload">, <link rel="preconnect">, <link rel="dns-prefetch"> 提前加载关键资源或建立连接。

3.3 LCP (Largest Contentful Paint) – 最大内容绘制

定义与意义：
LCP 记录的是视口内最大的内容元素完成渲染的时间点。这个“最大的内容元素”通常是图片、视频的海报帧、或由大块文本节点组成的块级元素。LCP 旨在衡量用户何时看到页面的主要内容，是用户感知页面加载速度最重要的指标之一。Google 将 LCP 作为其核心 Web Vitals (CWV) 的一部分，建议 LCP 在 2.5 秒以内。

如何获取：
LCP 可以通过 PerformanceObserver 监听 entryType 为 'largest-contentful-paint' 的性能条目来获取。

const lcpObserver = new PerformanceObserver((list) => {
    const entries = list.getEntries();
    // LCP 可能会在页面加载过程中多次发生，因为“最大的内容元素”可能会变化
    // 我们总是取最后一个（最新的）LCP 条目
    const lastEntry = entries[entries.length - 1];
    console.log('Largest Contentful Paint (LCP) 时间:', lastEntry.startTime, 'ms');
    console.log('LCP 元素:', lastEntry.element); // LCP 对应的 DOM 元素
    console.log('LCP 渲染时间:', lastEntry.renderTime, 'ms'); // 元素实际渲染时间
    console.log('LCP 加载时间:', lastEntry.loadTime, 'ms'); // 元素资源加载时间 (如果是图片/视频)
    // 理论上 LCP 可能会更新，但对于最终报告，我们通常在页面加载稳定后获取
    // 或者在页面卸载前发送最后一个 LCP
});

// 注意：LCP 观察者通常在页面生命周期中持续观察，直到页面完全加载或用户交互
lcpObserver.observe({ entryTypes: ['largest-contentful-paint'], buffered: true });

buffered: true 选项允许观察者访问在它被创建之前已经发生的条目。

LCP 元素的识别规则：
浏览器会根据以下规则识别 LCP 元素：

<img> 元素
<image> 元素内部的 <svg>
<video> 元素（使用其海报帧）
带有 background-image 的元素（但仅限于通过 url() 函数加载的图片）
包含文本节点或其他内联级文本元素的块级元素（例如 <p>, <h1>, <div> 包含大量文本）

浏览器会持续监控页面，并在最大的内容元素发生变化时报告新的 LCP 条目。最终的 LCP 值是所有报告中最大的那个。

归因分析：什么会影响 LCP？

LCP 耗时主要由四个方面组成：

服务器响应时间 (TTFB)：页面 HTML 到达浏览器的时间。越长，LCP 越晚。
资源加载延迟 (Resource Load Delay)：LCP 元素（特别是图片或视频）的加载时间。
渲染阻塞 (Render Blocking)：CSS 和 JavaScript 阻塞渲染，导致 LCP 元素无法及时绘制。
元素渲染时间 (Element Render Time)：LCP 元素在 DOM 中布局和绘制所需的时间。

代码示例：LCP 归因分析

我们继续使用更新后的 index.html。这次，large-hero.jpg 极有可能是 LCP 元素。

<!-- index.html (最终版) -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>LCP 分析示例</title>
    <style>
        @font-face {
            font-family: 'CustomFont';
            src: url('custom-font.woff2') format('woff2');
            font-display: swap;
        }
        body {
            margin: 0;
            background-color: #f0f0f0;
            font-family: 'CustomFont', Arial, sans-serif;
            color: #333;
        }
        .header {
            background-color: #007bff;
            color: white;
            padding: 20px;
            text-align: center;
            /* 假设 header 很大，也可能成为 LCP 候选 */
            min-height: 150px;
        }
        .main-image {
            width: 100%;
            max-width: 600px;
            height: auto;
            margin-top: 20px;
            /* 假设这张图片很大，是 LCP 的主要贡献者 */
        }
        .text-block {
            padding: 20px;
            font-size: 1.2em;
            line-height: 1.5;
            /* 假设这个文本块非常大，也可能成为 LCP 候选 */
            max-width: 800px;
            margin: 20px auto;
        }
    </style>
    <!-- 模拟一个非常大的 CSS 文件，严重阻塞渲染 -->
    <link rel="stylesheet" href="very-slow.css">
</head>
<body>
    <div class="header">
        <h1>我的响应式网站</h1>
    </div>
    <div class="content">
        <img src="large-hero.jpg" alt="英雄图片" class="main-image">
        <div class="text-block">
            <p>这里有一些非常重要的文本内容，它是页面核心信息的一部分。</p>
            <p>为了演示 LCP，我们假设这个文本块包含了大量有价值的信息，并且占据了视口内相当大的区域。</p>
            <p>因此，它的渲染时间对于用户感知页面可用性至关重要。如果这个文本块的渲染被延迟，那么 LCP 也会相应地推迟。</p>
            <!-- 更多文本内容填充，使其成为一个大的块级元素 -->
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
            <p>Curabitur pretium tincidunt lacus. Nulla facilisi. Nullam eget nisl. Praesent dapibus, neque id cursus faucibus, tortor neque egestas augu. Donec vitae arcu. Duis sapien. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
        </div>
    </div>
    <!-- 模拟一个非常慢的 JS 文件，严重阻塞主线程 -->
    <script src="super-blocking.js"></script>
</body>
</html>

very-slow.css 和 super-blocking.js 模拟极端情况，它们会进一步延长页面加载时间。

分析：

TTFB：如果服务器响应慢，所有后续资源的加载都会延迟，包括 LCP 元素。
very-slow.css：这个巨大的 CSS 文件会严重阻塞渲染。在它完全下载和解析之前，浏览器无法构建完整的渲染树，因此无法绘制包括 LCP 元素在内的任何内容。这会直接导致 LCP 大幅延迟。
large-hero.jpg：如果这张图片没有优化，文件过大，或者服务器响应慢，它的下载时间会很长。由于它很可能是 LCP 元素，其加载时间会直接贡献到 LCP。
super-blocking.js：这个阻塞主线程的 JavaScript 会在执行期间阻止浏览器进行任何渲染工作。如果它在 LCP 元素渲染之前执行，那么 LCP 就会被推迟。即使 CSS 已经加载完成，JS 阻塞也会阻止渲染。
text-block：如果图片加载失败或图片很小，而文本块很大，那么这个文本块也可能成为 LCP 元素。字体加载（如果使用的是自定义字体）和文本渲染的延迟也会影响 LCP。

通过 lastEntry.element 我们可以确定哪个元素是 LCP 元素，进而针对性地分析其加载和渲染过程。

LCP 优化策略：
LCP 的优化是综合性的，涵盖了前端性能优化的多个方面：

优化服务器响应时间 (TTFB)：
- 使用 CDN 加速静态资源。
- 优化后端代码和数据库查询。
- 启用 HTTP/2 或 HTTP/3。
- 服务端渲染 (SSR) 或预渲染 (Prerendering)。
优化资源加载时间：
- 图片优化：
  - 压缩图片、使用 WebP/AVIF 等现代图片格式。
  - 响应式图片 (srcset, sizes)。
  - 对 LCP 图片使用 <link rel="preload"> 进行预加载。
  - 避免对首屏图片使用懒加载。
- 视频优化：使用海报帧、压缩视频、流媒体。
- 字体优化：预加载关键字体、字体子集化、font-display: swap。
消除渲染阻塞资源：
- CSS 优化：
  - 关键 CSS 内联化。
  - 异步加载非关键 CSS (<link rel="stylesheet" media="print" onload="this.media='all'"> 或 JavaScript)。
  - CSS 压缩和代码分割。
- JavaScript 优化：
  - defer 和 async 属性。
  - 代码分割 (Code Splitting) 和懒加载。
  - 避免长任务，使用 Web Workers 处理复杂计算。
  - 将非关键 JavaScript 移到 <body> 底部。
优化 LCP 元素的渲染时间：
- 减少 DOM 深度和复杂性。
- 避免在 JavaScript 中进行大量的样式计算或布局操作，尤其是在页面加载初期。
- 使用 content-visibility: auto (实验性) 优化非首屏内容的渲染。

4. 深入分析与归因实践

理解了 FP、FCP、LCP 的基本概念和影响因素后，我们现在来看看如何更深入地进行归因分析，将这些指标的延迟具体定位到网络、渲染或 JavaScript 执行阶段。

4.1 网络阶段 (Network Phase)

网络阶段是页面加载的起点，任何网络延迟都会直接影响后续的所有指标。我们可以使用 performance.getEntriesByType('resource') 和 performance.getEntriesByType('navigation') 来分析网络耗时。

PerformanceResourceTiming 接口提供了单个资源（如图片、CSS、JS 文件）从请求到下载完成的详细时间戳。

属性	描述
`name`	资源的 URL。
`initiatorType`	资源是如何被请求的（如 `img`, `script`, `link`）。
`startTime`	资源请求开始的时间戳。
`duration`	资源加载总耗时。
`fetchStart`	浏览器开始获取资源的时间。
`domainLookupStart`	DNS 查询开始时间。
`domainLookupEnd`	DNS 查询结束时间。
`connectStart`	TCP 连接开始时间。
`connectEnd`	TCP 连接结束时间。
`secureConnectionStart`	TLS/SSL 握手开始时间（如果使用 HTTPS）。
`requestStart`	浏览器发送 HTTP 请求的时间。
`responseStart`	浏览器收到响应的第一个字节的时间 (TTFB)。
`responseEnd`	浏览器收到响应的最后一个字节的时间。

PerformanceNavigationTiming 接口（getEntriesByType('navigation') 返回）提供了主文档的导航和加载的详细时间戳。

// 假设在页面加载完成后调用
function analyzeNetworkPerformance() {
    const navigationEntry = performance.getEntriesByType('navigation')[0];
    if (navigationEntry) {
        console.log('--- 页面导航时间轴 ---');
        console.log(`TTFB (Time to First Byte): ${navigationEntry.responseStart - navigationEntry.requestStart} ms`);
        console.log(`DOM Content Loaded: ${navigationEntry.domContentLoadedEventEnd - navigationEntry.startTime} ms`);
        console.log(`Page Load Complete: ${navigationEntry.loadEventEnd - navigationEntry.startTime} ms`);
        console.log(`DNS Lookup: ${navigationEntry.domainLookupEnd - navigationEntry.domainLookupStart} ms`);
        console.log(`TCP Connect: ${navigationEntry.connectEnd - navigationEntry.connectStart} ms`);
        console.log(`TLS Handshake: ${navigationEntry.secureConnectionEnd - navigationEntry.secureConnectionStart} ms (if HTTPS)`);
    }

    console.log('n--- 资源加载详情 ---');
    performance.getEntriesByType('resource').forEach(entry => {
        // 过滤掉 data URL 和非 HTTP/HTTPS 资源
        if (!entry.name.startsWith('http')) return;

        console.log(`资源: ${entry.name.substring(entry.name.lastIndexOf('/') + 1)}`);
        console.log(`  类型: ${entry.initiatorType}`);
        console.log(`  总耗时: ${entry.duration.toFixed(2)} ms`);
        console.log(`  TTFB: ${(entry.responseStart - entry.requestStart).toFixed(2)} ms`);
        console.log(`  下载耗时: ${(entry.responseEnd - entry.responseStart).toFixed(2)} ms`);
        console.log('---');
    });
}

// 在 window.onload 事件中调用，确保所有资源加载完成
window.addEventListener('load', analyzeNetworkPerformance);

归因实践：

高 TTFB：可能是服务器性能问题、后端处理缓慢、网络拥堵。
长的 DNS Lookup/TCP Connect/TLS Handshake：可能与 DNS 解析器性能、网络延迟、TLS 证书协商有关。考虑 DNS 预解析 (<link rel="dns-prefetch">) 或预连接 (<link rel="preconnect">)。
大文件下载时间长：检查资源大小、是否压缩、是否利用 CDN、是否 HTTP/2。

4.2 渲染阶段 (Rendering Phase)

渲染阶段包括 DOM 解析、CSSOM 构建、渲染树构建、布局 (Layout/Reflow) 和绘制 (Paint)。渲染阻塞是 LCP 延迟的常见原因。

渲染阻塞的元凶：

同步 CSS：浏览器在下载和解析所有 CSS 文件之前，通常不会渲染任何内容，以避免闪烁无样式内容 (FOUC)。
同步 JavaScript：位于 document.head 或没有 async/defer 的 JavaScript 会暂停 HTML 解析和渲染，直到脚本下载并执行完成。

要分析渲染阻塞，除了观察 FP/FCP/LCP 的时间点，还可以结合资源加载时间和 JavaScript 执行时间来推断。

PerformanceObserver('longtask')：
长任务是指在主线程上执行超过 50 毫秒的任务。它们会阻塞主线程，导致页面无响应，影响用户体验和 LCP。

const longTaskObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        console.warn('检测到长任务:', entry.name, '持续时间:', entry.duration.toFixed(2), 'ms');
        // entry.startTime 是任务开始时间
        // entry.duration 是任务持续时间
        // entry.attribution 属性可能提供更多关于任务来源的信息
    }
});

longTaskObserver.observe({ entryTypes: ['longtask'] });

归因实践：

FCP/LCP 延迟明显长于资源下载时间：很可能存在渲染阻塞。
长任务频繁出现：表明主线程被长时间占用，检查 JavaScript 代码。
CSS 文件过大或请求数量过多：考虑 CSS 拆分、压缩、内联关键 CSS。

4.3 JavaScript 执行与阻塞

JavaScript 是现代 Web 应用的核心，但也常常是性能瓶颈的来源。

JavaScript 阻塞渲染：
如前所述，不当的 JS 加载方式会阻塞 HTML 解析和渲染。

主线程阻塞 (Long Tasks)：
即使 JS 文件已加载，其执行也可能耗费大量 CPU 时间，导致主线程卡顿，无法处理用户输入或进行渲染。这会直接影响交互性能，并可能延迟 LCP 的最终确定。

归因实践：

分析 JS 文件加载策略：是否使用了 async/defer？是否进行了代码分割？
识别耗时函数：使用浏览器开发者工具的 Performance 面板，录制页面加载过程，可以清晰看到 JavaScript 的执行堆栈和耗时情况。
优化算法：减少复杂计算，避免在主线程中处理大量数据。
Web Workers：将耗时的计算任务转移到 Web Workers 中，不阻塞主线程。
节流 (Throttling) 和防抖 (Debouncing)：优化事件处理函数。

5. 综合案例分析与优化策略

现在，让我们通过一个模拟的案例来将上述知识付诸实践。

场景描述：一个典型的慢速电商商品详情页

假设我们有一个电商网站的商品详情页 product.html，它的首屏加载体验非常糟糕。

product.html 结构：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>商品详情 - 慢速页面</title>
    <link rel="stylesheet" href="https://cdn.example.com/libs/bootstrap/4.5.2/bootstrap.min.css"> <!-- 外部 CSS 库 -->
    <link rel="stylesheet" href="styles.css"> <!-- 自定义样式 -->
    <script src="https://cdn.example.com/libs/jquery/3.5.1/jquery.min.js"></script> <!-- 外部 JS 库 -->
    <script src="analytics.js"></script> <!-- 分析脚本，通常放在头部 -->
    <style>
        /* 内部样式，可能包含一些关键样式，也可能不关键 */
        body { font-family: sans-serif; margin: 0; background-color: #f8f8f8; }
        .product-header { background-color: #fff; padding: 20px; text-align: center; }
        .product-image-container { text-align: center; margin-top: 20px; }
        .product-image { max-width: 800px; width: 90%; height: auto; }
        .product-details { padding: 20px; max-width: 800px; margin: 0 auto; }
    </style>
</head>
<body>
    <div class="product-header">
        <h1>商品名称：豪华智能手机 X Pro</h1>
        <p>价格: ¥9999.00</p>
    </div>
    <div class="product-image-container">
        <img src="https://example.com/images/large_phone_hero.jpg" alt="豪华智能手机 X Pro" class="product-image">
    </div>
    <div class="product-details">
        <h2>产品描述</h2>
        <p>这是关于豪华智能手机 X Pro 的详细描述。它拥有最新的芯片、最先进的摄像头技术和超长的电池续航。我们保证提供无与伦比的用户体验。</p>
        <!-- 更多产品特点和用户评价，导致此文本块可能很大 -->
        <p>...</p>
        <button id="addToCart">加入购物车</button>
    </div>
    <script src="main.js"></script> <!-- 主业务逻辑 -->
</body>
</html>

styles.css：自定义样式，假设其中包含一个 @font-face 规则和大量非关键 CSS。
analytics.js：模拟一个需要在页面加载早期执行的第三方分析脚本，可能耗时。
main.js：主业务逻辑，包含加入购物车事件监听等，可能在 DOMContentLoaded 之后才需要执行。
large_phone_hero.jpg：一张未经优化的超大分辨率图片。

初始指标测量 (使用 PerformanceObserver)

我们首先在 product.html 中嵌入我们的 PerformanceObserver 代码：

<!-- 插入到 <head> 底部，或者 <body> 顶部，确保能捕获所有事件 -->
<script>
    const performanceMetrics = {};

    new PerformanceObserver((list) => {
        for (const entry of list.getEntries()) {
            if (entry.name === 'first-paint') {
                performanceMetrics.fp = entry.startTime;
                console.log('FP:', entry.startTime.toFixed(2), 'ms');
            }
            if (entry.name === 'first-contentful-paint') {
                performanceMetrics.fcp = entry.startTime;
                console.log('FCP:', entry.startTime.toFixed(2), 'ms');
            }
        }
    }).observe({ entryTypes: ['paint'] });

    new PerformanceObserver((list) => {
        const entries = list.getEntries();
        const lastEntry = entries[entries.length - 1]; // 取最新的 LCP
        performanceMetrics.lcp = lastEntry.startTime;
        console.log('LCP:', lastEntry.startTime.toFixed(2), 'ms', 'Element:', lastEntry.element ? lastEntry.element.tagName : 'N/A');
        console.log('LCP Element Load Time:', (lastEntry.loadTime || 0).toFixed(2), 'ms');
    }).observe({ entryTypes: ['largest-contentful-paint'], buffered: true });

    // 监听页面加载完成，发送指标到后端或做最终分析
    window.addEventListener('load', () => {
        console.log('n--- 最终性能指标 ---');
        console.log('FP:', performanceMetrics.fp ? performanceMetrics.fp.toFixed(2) + 'ms' : 'N/A');
        console.log('FCP:', performanceMetrics.fcp ? performanceMetrics.fcp.toFixed(2) + 'ms' : 'N/A');
        console.log('LCP:', performanceMetrics.lcp ? performanceMetrics.lcp.toFixed(2) + 'ms' : 'N/A');

        // 这里可以添加网络资源分析等
        analyzeNetworkPerformance(); // 调用上面定义的函数
    });

    // 模拟一个耗时操作，用于测试 LCP 延迟
    setTimeout(() => {
        console.log('页面加载后执行的模拟耗时操作...');
        let sum = 0;
        for (let i = 0; i < 100000000; i++) {
            sum += Math.sqrt(i);
        }
        console.log('模拟耗时操作完成，结果:', sum);
    }, 1000); // 延迟 1 秒执行，可能影响 LCP
</script>

在本地或模拟网络环境下测试，我们可能会得到如下的结果（假设值）：

指标	初始测量值 (ms)	归因分析
FP	1200	– TTFB 较长 (200ms) – `bootstrap.min.css` 和 `styles.css` 加载和解析阻塞 (共 800ms) – `jquery.min.js` 和 `analytics.js` 在 `<head>` 中，阻塞 HTML 解析和渲染 (共 200ms)
FCP	1800	– 与 FP 相同的原因 – `styles.css` 中的 `@font-face` 字体加载延迟 (300ms) – 首屏文本 (`<h1>`, `<p>`) 渲染受字体影响，且等待 CSS 和 JS 阻塞结束。
LCP	4500	– 与 FP/FCP 相同的原因 – `large_phone_hero.jpg` 图片文件巨大 (5MB)，加载时间长 (1500ms) – `main.js` 脚本在 `<body>` 底部，但其执行可能在图片加载完之前，导致渲染阻塞 (200ms) – 页面加载后 1 秒的模拟耗时操作也可能进一步延迟 LCP 的稳定。

优化策略与验证：

针对上述归因，我们逐步进行优化：

优化阶段 1：消除渲染阻塞

CSS 优化：

将 bootstrap.min.css 和 styles.css 中首屏不必要的样式标记为非关键，使用 JavaScript 异步加载。
将首屏必要的关键 CSS 内联到 <head> 中。
将 styles.css 中的 @font-face 规则添加 font-display: swap。
压缩和合并 CSS 文件。

<!-- 优化后的 <head> -->
<head>
    <!-- ...其他 meta 标签 -->
    <title>商品详情 - 快速页面</title>
    <style>
        /* 内联关键 CSS */
        body { font-family: 'OptimizedFont', sans-serif; margin: 0; background-color: #f8f8f8; }
        .product-header { background-color: #fff; padding: 20px; text-align: center; }
        /* ... 其他首屏关键样式 ... */

        /* 字体优化 */
        @font-face {
            font-family: 'OptimizedFont';
            src: url('optimized-font.woff2') format('woff2'); /* 假设字体文件也优化了 */
            font-display: swap; /* 关键！ */
        }
    </style>
    <!-- 异步加载非关键 CSS -->
    <link rel="preload" href="https://cdn.example.com/libs/bootstrap/4.5.2/bootstrap.min.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="https://cdn.example.com/libs/bootstrap/4.5.2/bootstrap.min.css"></noscript>
    <link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="styles.css"></noscript>
    <!-- 预连接 CDN 域名 -->
    <link rel="preconnect" href="https://cdn.example.com">
    <link rel="dns-prefetch" href="https://cdn.example.com">
    <!-- ... -->
</head>

JavaScript 优化：

将 jquery.min.js 和 analytics.js 添加 defer 属性，或移至 <body> 底部。
main.js 也添加 defer 属性。

<!-- 优化后的 JS 引入 -->
<!-- ... -->
<body>
    <!-- ... 页面内容 ... -->
    <script src="https://cdn.example.com/libs/jquery/3.5.1/jquery.min.js" defer></script>
    <script src="analytics.js" defer></script>
    <script src="main.js" defer></script>
    <!-- ... -->
</body>

优化阶段 2：LCP 元素优化

图片优化：

将 large_phone_hero.jpg 优化（压缩、转为 WebP 格式），生成不同尺寸的图片。
使用 srcset 和 sizes 属性实现响应式图片。
对 LCP 候选图片进行预加载。

<!-- 优化后的图片 -->
<div class="product-image-container">
    <link rel="preload" href="https://example.com/images/large_phone_hero_optimized.webp" as="image">
    <img src="https://example.com/images/large_phone_hero_optimized.webp"
         srcset="https://example.com/images/small_phone_hero.webp 480w,
                 https://example.com/images/medium_phone_hero.webp 800w,
                 https://example.com/images/large_phone_hero_optimized.webp 1200w"
         sizes="(max-width: 600px) 480px,
                (max-width: 1000px) 800px,
                1200px"
         alt="豪华智能手机 X Pro" class="product-image">
</div>

服务器响应时间 (TTFB) 优化：
- 检查后端服务性能，数据库查询优化。
- 启用 Gzip/Brotli 压缩。
- 考虑使用 SSR 或预渲染，直接提供渲染好的 HTML。

优化阶段 3：减少主线程阻塞

JavaScript 任务分解：

将页面加载后执行的模拟耗时操作，如果真实业务逻辑中存在，应考虑分解为小任务，或使用 requestIdleCallback，甚至 Web Workers。

// main.js (优化后)
document.addEventListener('DOMContentLoaded', () => {
    document.getElementById('addToCart').addEventListener('click', () => {
        console.log('商品已加入购物车！');
    });

    // 将耗时操作分解或延迟
    requestIdleCallback(() => {
        console.log('页面空闲时执行的模拟耗时操作...');
        let sum = 0;
        for (let i = 0; i < 10000000; i++) { // 减少循环次数
            sum += Math.sqrt(i);
        }
        console.log('模拟耗时操作完成，结果:', sum);
    });
});

优化后的指标测量 (再次测量)

经过这些优化后，再次测量页面性能，我们可能会看到显著的改善：

指标	初始测量值 (ms)	优化后测量值 (ms)	改进百分比
FP	1200	300	75%
FCP	1800	500	72%
LCP	4500	1500	66%

这个表格清晰地展示了优化带来的效果。通过 Performance API 的精确测量和细致的归因分析，我们能够有针对性地解决问题，从而显著提升用户体验。

6. RUM (Real User Monitoring) 与合成监控 (Synthetic Monitoring)

我们刚才所做的分析，属于合成监控 (Synthetic Monitoring) 的范畴。即在受控的环境（例如开发者工具、WebPageTest）中，模拟用户访问来测量性能。

然而，用户的真实网络环境、设备性能、地理位置等千差万别。因此，仅仅依靠合成监控是不够的。我们需要 真实用户监控 (Real User Monitoring, RUM) 来收集用户在真实环境下的性能数据。

如何将 Performance API 数据上报到后端：

通过 PerformanceObserver 收集到的 FP、FCP、LCP 以及其他 PerformanceEntry 数据，可以序列化后通过 navigator.sendBeacon() 或 fetch() 发送到后端服务进行聚合和分析。

// RUM 数据上报示例
const reportPerformanceMetrics = (metrics) => {
    const data = JSON.stringify(metrics);
    // 使用 sendBeacon 确保在页面卸载前发送数据，不阻塞页面
    if (navigator.sendBeacon) {
        navigator.sendBeacon('/api/performance-report', new Blob([data], { type: 'application/json' }));
    } else {
        // Fallback for older browsers
        fetch('/api/performance-report', {
            method: 'POST',
            body: data,
            headers: { 'Content-Type': 'application/json' }
        }).catch(error => console.error('Failed to send performance report:', error));
    }
};

const finalMetrics = {}; // 收集所有 FP, FCP, LCP 等

new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-paint') finalMetrics.fp = entry.startTime;
        if (entry.name === 'first-contentful-paint') finalMetrics.fcp = entry.startTime;
    }
}).observe({ entryTypes: ['paint'] });

new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const lastEntry = entries[entries.length - 1];
    finalMetrics.lcp = lastEntry.startTime;
}).observe({ entryTypes: ['largest-contentful-paint'], buffered: true });

// 页面卸载前发送数据
window.addEventListener('beforeunload', () => {
    reportPerformanceMetrics(finalMetrics);
});

// 或者在页面完全加载并稳定后发送
window.addEventListener('load', () => {
    // 确保 LCP 稳定，可能需要稍微延迟
    setTimeout(() => {
        reportPerformanceMetrics(finalMetrics);
    }, 1000); // 延迟 1 秒，给 LCP 足够时间更新
});

通过 RUM，我们可以获得更真实、更全面的用户体验洞察，结合合成监控，形成一个闭环的性能优化流程。

7. 持续优化，提升用户体验

今天我们深入探讨了利用 Performance API 进行首屏加载耗时分析，并着重归因了 FP、FCP 和 LCP 三大核心指标。从网络延迟到渲染阻塞，再到 JavaScript 执行，每一个环节都可能影响最终的用户体验。

性能优化是一个持续的过程，它要求我们不断测量、分析、优化和验证。掌握 Performance API 这些强大的工具，能够帮助我们精准定位问题，做出明智的优化决策，最终为用户提供更快、更流畅的 Web 体验。记住，性能不仅仅是技术问题，更是用户体验和业务成功的基石。

1. 引言：为什么首屏加载如此重要？

2. Performance API 基础：浏览器性能分析的利器

2.1 performance 对象简介

2.2 PerformanceObserver：异步监听性能事件

2.3 performance.getEntriesByType()：同步获取性能条目

3. 核心指标解析：FP、FCP、LCP

3.1 FP (First Paint) – 首次绘制

3.2 FCP (First Contentful Paint) – 首次内容绘制

3.3 LCP (Largest Contentful Paint) – 最大内容绘制

4. 深入分析与归因实践

4.1 网络阶段 (Network Phase)

4.2 渲染阶段 (Rendering Phase)

4.3 JavaScript 执行与阻塞

5. 综合案例分析与优化策略

6. RUM (Real User Monitoring) 与合成监控 (Synthetic Monitoring)

7. 持续优化，提升用户体验

发表回复 取消回复

2.1 `performance` 对象简介

2.2 `PerformanceObserver`：异步监听性能事件

2.3 `performance.getEntriesByType()`：同步获取性能条目

发表回复取消回复