📚 课程目录第1章课程导论

1、课程导论：什么是缓存与瀑布图？为什么联合诊断能定位速度瓶颈

大家好，我是小张。做前端性能优化这些年，有一个问题始终绕不开——页面加载慢，到底慢在哪？

你想想看，老板说“首页打开要3秒”，你打开DevTools一看，网络请求几十个，有的几毫秒，有的几百毫秒，还有的干脆pending几十秒。一头雾水，对吧？

我自己刚入行时也这样。后来我才发现，两样东西能帮我们快速定位病因：缓存和瀑布图。今天这门课，咱们就从它俩说起。

缓存不是啥新概念。现实里，你把常用手机号存到通讯录，下次直接拨打，不用翻通话记录——这就是缓存。

在Web世界里，缓存就是把资源（HTML、CSS、JS、图片等）存到某个离用户更近的地方。下次请求时，直接返回存好的副本，省掉网络传输时间。

核心数据：据HTTP Archive统计，合理利用缓存可使页面加载时间降低40%~60%。我自己接手过一个电商项目，调整了静态资源的缓存策略，首屏直接从2.8秒降到了1.1秒。

常见缓存类型我用表格列一下：

缓存层级	典型实现	作用范围	我踩过的坑
浏览器缓存	强缓存（Expires/Cache-Control）、协商缓存（Etag/Last-Modified）	单个用户	强缓存设置过长导致用户看不到新版本，我曾经因此被产品骂“你改的代码呢？！”
CDN缓存	边缘节点缓存	区域用户	CDN回源策略没配好，导致明明有缓存却每次都回源，瀑布图里一片200，慢得像乌龟
Service Worker缓存	离线缓存、预缓存	受控页面	离线缓存逻辑写错了，用户刷新后看到旧页面，数据也不是最新的
后端缓存	Memcached、Redis等	服务器集群	缓存穿透时，数据库直接被压垮；后来加了布隆过滤器才稳住

你可能会问：“缓存这么有用，为什么还要看瀑布图？”

好问题。缓存能帮我们绕过网络请求，但请求还是发出了，没命中怎么办？这时候，我们得靠瀑布图看看到底发生了什么。

瀑布图（Waterfall）就在浏览器的开发者工具里。每当页面发起一个网络请求，它就记录下这个请求的完整生命周期——从DNS解析到下载完成，每段花了多少时间。

举个例子，我在优化一个有几百张产品的列表页时，发现其中一个JSON接口瀑布图里“TTFB(首字节时间)”长达8秒。翻看详细信息，发现是服务器处理时间太长、慢SQL在作祟。如果不看瀑布图，你可能只会觉得“接口慢”，却不知道慢在哪里。

瀑布图里几个关键指标：

一个小技巧：在Chrome DevTools的Network面板，可以右键点击列头勾选“Waterfall”的更多详情，比如Connection、DNS、SSL等。把这些拆开看，能一眼看出瓶颈在网络的哪个环节。

单独看缓存，你只能知道资源有没有被存下来，但不知道没被缓存时具体哪里慢。单独看瀑布图，你能看到每个阶段的时间，但不知道哪些时间原本可以被缓存避免。

举个例子：

瀑布图显示某个接口的TTFB是200ms，看起来正常，但如果你知道这个接口的数据其实一天才变一次，应当用CDN缓存，那200ms就是浪费——联合诊断才能发现“慢得没必要”。
反过来，缓存明明生效了，但用户还是觉得慢。看瀑布图发现是资源并行下载太多、造成了渲染阻塞——联合诊断又发现“缓存被用错了地方”。

所以，我的经验是：把缓存视为“理想态”，把瀑布图视为“真实态”。两者对照，哪里被缓存避开了、哪里没避开、哪里虽然被缓存了但还有优化空间，一目了然。

下面这张SVG图，概括了本章的知识框架。它把缓存和瀑布图放在两个面上，然后通过“联合分析”得到瓶颈定位与优化方向。你可以把它贴在工位上，做性能排查时照着过一遍：

你可以看到，左侧缓存分析检查策略、命中率、漏掉的资源；右侧瀑布图分析时间线、阻塞原因、缓存前后对比；两者在中间汇聚，得出瓶颈定位，最后落到优化方案。这就是我们这门课的核心方法。

注意：联合诊断不是一次性做完就完事。性能优化是迭代过程。改完缓存策略后，一定要再抓一次瀑布图，验证效果。我曾经改完CDN配置，得意地关了DevTools，结果第二天用户反馈更慢了——原来新配置没生效，CDN回源超时导致瀑布图里一片红色。不看瀑布图就是盲人摸象。

缓存回答“能不能省”，瀑布图回答“哪里在花时间”。两者合起来用，才能精准出击。

接下来的章节里，我会用大量真实案例和代码，带你一步步掌握这套诊断方法。别急，我们先打好基础。