性能优化概览
🎯 引言
这是「性能优化」课程的第一篇。做前端的同学大多有过这样的经历：功能都写完了，页面也能用，但打开就是慢半拍，图片一张张蹦出来，点按钮反应迟钝。功能正确只是及格线，快，才是用户能直接感受到的品质。
这门课不讲高深的理论，而是带你建立一套完整的性能优化思维：先搞懂为什么要优化、从哪里入手，再沿着加载、渲染、缓存、构建、指标五个方向逐个击破。本篇是地图，以概念为主，几乎没有代码。
学完本篇，你将能够：
- 说清楚性能优化为什么值得做，它对用户体验和 SEO 有什么影响。
- 记住性能优化的五个主要方向，知道每个方向解决什么问题。
- 掌握「定位瓶颈 → 针对性优化 → 数据验证」的基本套路，不再凭感觉改代码。
🧱 为什么需要性能优化
性能优化听起来像「锦上添花」，实际上它直接影响三件很实在的事：用户愿不愿留下来、老板要不要为此买单、搜索引擎给不给你流量。我们一个个说。
其一，页面慢，用户是真的会走。
回想你自己上网的体验：点开一个页面，白屏转了好几秒，你会耐心等，还是直接关掉换一家？大多数人选后者。用户不会区分「是网慢还是网站写得烂」，他只会觉得「这个网站不好用」，然后流失掉。对电商、资讯类站点来说，每一次流失背后都是实实在在的业务损失。
其二，慢的感受会累积成对产品的负面印象。
首屏慢只是第一层。滚动卡顿、输入延迟、点击没反应，这些「小卡」单次看都不严重，但叠加起来会让用户潜意识里觉得产品「不专业」「不可靠」。反过来，一个响应迅速的页面，用户甚至不会注意到它的存在，因为流畅本来就是应该的。
其三，性能会影响搜索排名。
Google 已公开把 Core Web Vitals（核心网页指标）作为搜索排名的参考因素之一。它用一组指标衡量页面的加载速度、交互响应和视觉稳定性（本课程第 6 篇会详细介绍）。也就是说，内容质量相近的两个页面，体验更好的那个在搜索结果里会更占优势。对靠自然流量生存的站点，这是很直接的优化动力。
💡 「慢」到底慢在哪里
用户嘴里的「这个网站慢」，其实是好几种不同的感受。学会把它们区分开，你才能找到对应的优化方向。我们按用户打开页面的时间顺序来感受一遍。
白屏阶段：等不到内容。 输入网址后屏幕一片空白，过了好几秒才出现内容。这通常是资源加载太慢：文件太大、请求太多、服务器响应慢。对应的解法是本课程的加载优化和缓存策略。
交互阶段：点了没反应。 内容出来了，但点按钮要顿一下才有反馈，输入文字有延迟。这一般是 JS 在执行耗时任务，把浏览器的主线程占住了，没空响应你的操作。这属于渲染优化要解决的问题。
浏览阶段：画面卡顿、内容乱跳。 滚动页面一卡一卡的，或者正要点一个按钮，图片加载完成把按钮顶走了，点到了别的地方。前者是渲染掉帧，后者是页面布局不稳定，这类体验问题在 Core Web Vitals 里有专门的指标衡量。
看，一句模糊的「慢」，拆开后对应的是不同阶段、不同原因。这就是为什么优化前必须先搞清楚：用户到底在哪个环节觉得慢。
🗺 整体思路：先测量，再优化
知道了为什么优化，下一个问题是：从哪开始改？很多新手的直觉是「我猜这里慢，先改了再说」，比如看到一篇文章讲某个技巧，就照搬到自己项目里。这是性能优化里常见的弯路。
正确的姿势是先测量，再优化。 就像医生看病要先检查再开药，性能问题也要先用工具量出瓶颈在哪，再对症下药。原因很简单：你感觉慢的地方，往往不是真正慢的地方。比如页面打开慢，你可能以为是接口慢，实际测量后发现是一张几 MB 的大图堵住了渲染。
测量的工具并不神秘：浏览器自带的 Chrome DevTools 就能看网络请求耗时、分析渲染过程，Google 的 Lighthouse 能一键给页面性能打分。这些工具的详细用法会在本课程第 6 篇展开，现在你只需要建立一个意识：任何优化之前，先拿到数据。
🧭 课程地图：五大优化方向
瓶颈可能出现在页面的不同阶段，我们把它们归成五个方向，也就是本课程的后续五篇。看完这张地图，你遇到性能问题时就能快速判断「这属于哪一类问题」。
方向一：加载优化（本课程第 2 篇）。
解决的是「资源怎么更快地到用户浏览器」。一个页面要下载 HTML、CSS、JS、图片、字体等一堆资源，加载优化就是让这个下载过程更省时间：压缩图片、按需加载、懒加载首屏之外的内容等。用户感知到的「打开慢」，大部分出在这一环。
方向二：渲染优化（本课程第 3 篇）。
资源下载完了，浏览器还要把它们画到屏幕上，这一步叫渲染。JS 长时间占用主线程、频繁触发页面重排重绘，都会让页面卡顿、掉帧。渲染优化解决的是「页面动起来顺不顺」的问题。
方向三：缓存策略（本课程第 4 篇）。
用户第二次访问时，很多资源其实没变过，完全可以不重新下载。缓存策略就是告诉浏览器「这些东西存起来，下次直接用」，让回访用户感受到接近秒开的速度。这是投入产出比很高的一类优化。
方向四：构建产物优化（本课程第 5 篇）。
我们写的源码和最终上线的代码之间隔着一道构建工序。打包出来的文件越小、拆分得越合理，浏览器下载和解析的负担就越轻。这一篇讲怎么给构建产物「瘦身」，比如代码分割、移除无用代码。
方向五：性能指标与工具（本课程第 6 篇）。
前面四个方向解决「怎么改」，这一篇解决「怎么量」：LCP、INP、CLS 这些指标分别衡量什么，DevTools 和 Lighthouse 怎么用，怎样给优化效果一个客观的数字评价。虽然放在后面，但它的思想（先测量）从下一篇开始就会一直用到。
五个方向不是孤立的。一个真实的优化案例往往横跨多个方向，课程按方向拆开讲，是为了让你每次只专注一类问题。
🛠 优化的基本套路
方向清楚了，最后说一套任何性能问题都通用的做事流程，一共三步：
第一步：定位瓶颈。 用工具测量，找到慢在哪里。是资源太大（加载问题）？还是 JS 执行太久（渲染问题）？没有测量结论，不动手写代码。
第二步：针对性优化。 瓶颈在哪个方向，就用哪个方向的手段。图片大就压图片，重复下载就配缓存，不要头痛医脚。
第三步：用数据验证效果。 改完之后重新测量，对比优化前后的数据。指标变好了，说明优化有效；没变化甚至更差，就回退方案、重新分析。
这个流程可以记成一句话：测量 → 优化 → 再测量。 它能帮你避开两个常见的坑：一是「凭感觉优化」，改了一堆代码但用户无感；二是「优化完就不管」，不知道改动到底有没有用，甚至把性能改得更差。
🧾 小节总结
- 性能优化直接影响用户体验、用户留存和搜索排名，不是可有可无的锦上添花。
- Google 已把 Core Web Vitals 作为搜索排名的参考因素之一，性能差的页面在搜索结果中会吃亏。
- 用户说的「慢」要拆开看：白屏久多半是加载问题，点了没反应多半是渲染问题，画面乱跳是布局稳定性问题。
- 优化的正确姿势是先测量再优化：凭感觉改代码，往往改不到真正的瓶颈上。
- 本课程按五个方向展开：加载优化、渲染优化、缓存策略、构建产物优化、性能指标与工具。
- 通用套路三步走：定位瓶颈 → 针对性优化 → 用数据验证效果，简称「测量 → 优化 → 再测量」。
❓ 知识问答
Q1：我的项目是个小网站，访问量不大，也需要性能优化吗？
A：需要，但可以抓大放小。小网站不需要复杂的优化方案，把收益明显的几件基础事做好（压缩图片、配置缓存）就够了。性能意识应该从项目早期建立，等用户抱怨再补，成本会高很多。
Q2：是不是把网上看到的优化技巧都用上，页面就一定快？
A：不是。优化技巧都有适用场景，不测量就盲目堆砌，可能白忙一场甚至起反效果。比如给一张首屏必须立刻显示的大图加懒加载，反而会让它出现得更晚。先定位瓶颈，再选对应的手段。
Q3：Core Web Vitals 是什么？需要现在就掌握吗？
A：它是 Google 提出的一组衡量页面体验的指标，分别关注加载速度、交互响应和视觉稳定性。本篇只需要知道它会影响搜索排名即可，具体指标含义和查看方法在本课程第 6 篇会详细讲。
Q4：性能优化和后端有关系吗？接口慢算前端的事吗？
A：接口慢属于后端优化范畴，但前端也有能做的事，比如合理的加载占位、非关键数据延后请求。本课程聚焦前端能控制的部分：资源加载、页面渲染、缓存和构建产物。
Q5：优化到什么程度算「够了」？
A：看数据，不看感觉。可以用 Lighthouse 跑分或对照 Web Vitals 的官方阈值来判断。达到健康水位后，继续抠细节的收益会递减，这时候把精力放回业务功能往往更划算。
🧪 小练习
练习一：找一个你常访问的网站（或者你自己的项目），用 Chrome 打开后按 F12 打开 DevTools，切到 Network 面板并刷新页面。观察两件事：哪个资源体积较大、哪个请求耗时较长。试着回答：这个页面的瓶颈更可能在哪个方向？
练习二：JS 自带的 performance.now() 可以拿到当前时间戳（单位毫秒），前后各取一次、相减，就能量出一段代码的执行耗时。补全下面的代码，量一量循环求和花了多少时间，用 Node.js v22 保存为 .js 文件直接运行：
const start = performance.now();
let sum = 0;
for (let i = 0; i < 1000000; i++) {
sum += i;
}
// 请在这里编写代码：再取一次时间戳，算出并打印耗时（毫秒，用 Math.round 取整）
多运行几次，观察耗时是否稳定。想想：如果只运行一次就下结论，可能会有什么问题？
🎉 恭喜你已经建立起性能优化的整体认知啦！现在你手里有了一张地图（五大方向）和一套打法（测量 → 优化 → 再测量）。下一篇我们进入第一个实战方向「加载优化」，看看怎么让页面资源更快地到达用户的浏览器。