08 · 用数据优化 · MODULE 08

Web 性能:把速度变成可度量的体验

性能优化不是压缩几个文件,而是围绕加载速度、响应性和视觉稳定性建立假设、测量、改造和回归防护。你会同时理解实验室数据与真实用户数据。

高级10 小时8 个核心主题

先用一句白话理解

优化性能像治理城市交通:只让一辆测试车跑得快没有意义,还要看真实高峰期、不同道路和普通车辆。Lighthouse 是封闭赛道,真实用户监控才是每天的交通数据。

学完你能做到什么

01

解释关键渲染路径及主要阻塞因素

02

测量并优化 LCP、INP 与 CLS

03

区分实验室数据、现场数据和代理指标

04

从网络、主线程、渲染和内存四个方向定位瓶颈

05

设置可进入持续集成的性能预算

把每个核心概念讲透

不要把知识点当作名词列表。下面每一项都要回到真实项目中回答:它解决什么问题,如何验证,以及在哪些条件下会失效。

01CORE CONCEPT

DOM/CSSOM、关键渲染路径与资源优先级

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“录制并读懂一次 Performance 时间线”,记录现象、预期、差异和结论。
02CORE CONCEPT

Core Web Vitals:LCP、INP、CLS

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“找出页面的 LCP 元素和主要长任务”,记录现象、预期、差异和结论。
03CORE CONCEPT

DevTools、Lighthouse、Performance API 与真实用户监控

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“修复一处由图片尺寸缺失造成的布局偏移”,记录现象、预期、差异和结论。
04CORE CONCEPT

响应式图片、现代格式、字体加载与 fetchpriority

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“为资源体积和关键指标建立自动门槛”,记录现象、预期、差异和结论。
05CORE CONCEPT

缓存、压缩、预加载、懒加载和 CDN 基础

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“录制并读懂一次 Performance 时间线”,记录现象、预期、差异和结论。
06CORE CONCEPT

代码分割、tree shaking、长任务与 Worker

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“找出页面的 LCP 元素和主要长任务”,记录现象、预期、差异和结论。
07CORE CONCEPT

样式计算、布局、绘制、合成与低成本动画

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“修复一处由图片尺寸缺失造成的布局偏移”,记录现象、预期、差异和结论。
08CORE CONCEPT

内存快照、泄漏定位和性能回归预算

先在浏览器中观察结构、样式、事件、网络和渲染行为。把这个概念放回“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”中,回答它解决了什么问题、依赖哪些输入、会在哪些边界失效。

验证方式用 DevTools、自动测试和跨浏览器结果验证假设:完成“为资源体积和关键指标建立自动门槛”,记录现象、预期、差异和结论。

这一章的学习步骤

1DOM/CSSOM、关键渲染路径与资源优先级
2Core Web Vitals:LCP、INP、CLS
3DevTools、Lighthouse、Performance API 与真实用户监控
4响应式图片、现代格式、字体加载与 fetchpriority
5缓存、压缩、预加载、懒加载和 CDN 基础
6代码分割、tree shaking、长任务与 Worker
7样式计算、布局、绘制、合成与低成本动画
8内存快照、泄漏定位和性能回归预算
STEP 01

录制并读懂一次 Performance 时间线

STEP 02

找出页面的 LCP 元素和主要长任务

STEP 03

修复一处由图片尺寸缺失造成的布局偏移

STEP 04

为资源体积和关键指标建立自动门槛

动手任务

PROJECT BRIEF

在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。

交付清单

  • 改造前后的性能报告
  • 按收益与成本排序的优化清单
  • 关键资源加载策略说明
  • 可自动检查的性能预算

批量写入 DOM 并测量耗时

html
<!doctype html>
<html lang="zh-CN">
  <meta charset="utf-8" />
  <button id="render">渲染 1000 行</button>
  <output id="cost">尚未运行</output>
  <ul id="list"></ul>
  <script>
    document.querySelector("#render").addEventListener("click", () => {
      performance.mark("render-start");
      const fragment = document.createDocumentFragment();
      for (let index = 1; index <= 1000; index += 1) {
        const item = document.createElement("li");
        item.textContent = "数据行 " + index;
        fragment.append(item);
      }
      document.querySelector("#list").replaceChildren(fragment);
      performance.mark("render-end");
      const entry = performance.measure("render", "render-start", "render-end");
      document.querySelector("#cost").value = entry.duration.toFixed(2) + " ms";
    });
  </script>
</html>

先让它跑起来,再逐行修改。最有效的学习方式,是观察你的改动如何影响结果。

三级练习:从复现到生产

每一级都比上一级少一点提示、多一点约束。只有在不看答案也能完成验收时,知识才真正变成能力。

01
LEVEL 1 · 基础复现

让核心机制第一次跑通

  • 录制并读懂一次 Performance 时间线
  • 找出页面的 LCP 元素和主要长任务
  • 修复一处由图片尺寸缺失造成的布局偏移
  • 为资源体积和关键指标建立自动门槛
02
LEVEL 2 · 独立改造

改变约束,验证你真的理解

  • 不看教程,独立完成:解释关键渲染路径及主要阻塞因素
  • 不看教程,独立完成:测量并优化 LCP、INP 与 CLS
  • 不看教程,独立完成:区分实验室数据、现场数据和代理指标
  • 不看教程,独立完成:从网络、主线程、渲染和内存四个方向定位瓶颈
  • 不看教程,独立完成:设置可进入持续集成的性能预算
03
LEVEL 3 · 生产挑战

把实验变成能交付的工程

  • 改造前后的性能报告
  • 按收益与成本排序的优化清单
  • 关键资源加载策略说明
  • 可自动检查的性能预算
  • 检查兼容性、可访问性、性能、安全与渐进增强,并把检查结果写进项目复盘。

最容易踩的坑

01

只看一次 Lighthouse 分数就宣布优化完成

02

为了体积删除真正改善用户体验的能力

03

过度预加载,反而抢占关键资源带宽

04

优化平均值,却忽略慢设备和长尾用户

先回答,再展开参考答案

Q01这一课最核心的业务目标是什么?

性能优化不是压缩几个文件,而是围绕加载速度、响应性和视觉稳定性建立假设、测量、改造和回归防护。你会同时理解实验室数据与真实用户数据。

Q02如果只能保留三个验收结果,应该保留什么?

改造前后的性能报告;按收益与成本排序的优化清单;关键资源加载策略说明

Q03学习过程中最需要主动避免什么?

只看一次 Lighthouse 分数就宣布优化完成;为了体积删除真正改善用户体验的能力;过度预加载,反而抢占关键资源带宽;优化平均值,却忽略慢设备和长尾用户

Q04怎样证明你不是“看懂了”,而是真的会做?

独立完成“在模拟中端手机和慢速网络下优化知识工作台,先记录基线,再逐项改造图片、字体、脚本和渲染路径,最终建立性能预算。”,并用测试、数据或运行结果逐项验收交付清单。

PRODUCTION READINESS

本课完成检查表

全部能打勾,再进入下一课。

  • 目标明确:解释关键渲染路径及主要阻塞因素
  • 核心机制已用最小实验验证:录制并读懂一次 Performance 时间线
  • 风险已检查:只看一次 Lighthouse 分数就宣布优化完成
  • 风险已检查:为了体积删除真正改善用户体验的能力
  • 风险已检查:过度预加载,反而抢占关键资源带宽
  • 风险已检查:优化平均值,却忽略慢设备和长尾用户
  • 交付物可复现:改造前后的性能报告
  • 交付物可复现:按收益与成本排序的优化清单
  • 交付物可复现:关键资源加载策略说明
  • 交付物可复现:可自动检查的性能预算

继续深入的官方资料

课程版本基线:2026 年 7 月。涉及版本号时,以链接中的官方文档为最终依据。