橙心橙怡讲真的，我在前端这个圈子里待了十来年，面试过几百个候选人，也接手过不少“历史遗留”项目，被问得最多、也最容易被答成废话的一个问题就是：“为什么前端需要做优化？”
有人回答“为了加载快一点”，有人回答“为了用户体验好”，还有人直接背八股文，从“减少HTTP请求”一路背到“使用CDN”。这些答案对吗？对，但都停留在“术”的层面，没有回答“道”的问题。如果只是为了让页面打开快一点，那为什么不直接把所有内容塞进一个HTML文件里，没有网络请求，绝对够快？
真正的问题在于，前端优化这件事，从来不是单指某一次性能优化。它背后牵涉的是用户留存、运营成本、开发效率、团队协作，甚至公司收入。你优化的每一毫秒，背后都有一笔可以算得清的账。这篇文章我想换个角度，不给你背一遍“优化清单”，而是把“为什么需要做优化”这件事拆开揉碎，讲清楚它到底在解决什么问题、怎么落地、以及有哪些坑是面试题里根本不会告诉你的。适合刚入门但想看透本质的新人，也适合干了两三年但总觉得自己在做“表面优化”的同学。
1. 优化不是炫技：先算清楚“不优化”的代价
1.1 从一次线上事故说起
几年前我负责过一个面向C端用户的内容社区项目。功能不算复杂，主要就是信息流、文章详情、个人中心，技术栈是Vue 2 + Webpack 3。上线之前的测试阶段，大家用的都是公司千兆网，页面打开基本都是秒开，谁也没觉得有问题。
结果上线两周之后，运营反馈了一个情况：详情页的跳出率高得离谱。我们把数据拉出来一看，详情页在低端安卓机上的平均加载时间是7.8秒，白屏时间接近4秒，用户根本没等到内容出现就划走了。更严重的是，因为详情页里引了一组未做压缩的图片和一段全量引入的地图SDK，光JS就有2.3MB，导致页面在加载过程中直接卡死了部分低内存机型。
那次事故之后我们做了两件事：第一，紧急把地图SDK改成异步加载，图片全部走CDN并压缩格式；第二，做了完整的性能优化方案。优化后详情页在低端机上的加载时间降到了2.1秒，跳出率下降了30%多。看起来只是数据变化，但背后对应的是实打实的广告收入——每100个用户多看了两个页面，CPM模式下这就是真金白银。
这个案例其实回答了一个核心问题：前端优化的第一驱动力，从来不是“技术洁癖”，而是业务代价。页面打不开、打开慢、操作卡，用户不会觉得是网不好，只会觉得是你的产品不行。尤其在移动端，用户耐心极短，3秒内打不开，他就走了，而且大概率不会再回来。这个意愿，在行业里有大量公开数据可以佐证，但我更想强调的是：你不需要相信那些报告，你只需要在自己项目里埋个点，看下跳出率和页面加载时长的相关性，你自然就明白了。
1.2 优化解决的不只是“快”，而是三层问题
很多人一说前端优化就只想到“首屏加载时间”，这其实把问题看窄了。我习惯把前端优化要解决的问题拆成三层：
第一层是加载层，也就是“页面能不能尽快出现在用户面前”。这一层和网络、资源体积、请求数量、服务端响应速度强相关。
第二层是渲染层，也就是“页面出现了，但能不能流畅地交互”。这里涉及DOM操作频率、样式计算、动画性能、内存占用。我见过不少项目，首屏优化做得很好，但用户一滚动就掉帧，一输入就卡顿，这其实就是渲染层没有处理好。
第三层是体验层，它更隐蔽，包括加载状态的反馈、交互反馈的及时性、弱网环境的降级处理。举个例子，用户在弱网下点击提交按钮，如果没有loading状态和防重复提交逻辑，用户会以为没点上，又点了一次，结果提交了两份数据。这不是性能问题，但它是体验优化问题，而且经常被归到“前端优化”的大范畴里。
所以“为什么前端需要做优化”这个问题的答案是立体的：加载层解决的是能不能留住用户，渲染层解决的是用户愿不愿意继续用，体验层解决的是用户会不会信任你的产品。三层都要做，缺一个都会出问题。
1.3 算清这笔账：优化的ROI其实很容易量化
我经常跟团队里的同学说，做优化之前先别急着动手，先算账。这个账怎么算？其实就是四个数：当前指标、优化目标、投入人天、预期收益。
比如，你的页面当前首屏时间3.5秒，日活10万，每提升1秒首屏速度能降低1%的跳出率（这个系数建议你们自己用数据回归测一下，不同产品差异很大），假设每个用户每天为你贡献0.1元广告收入，那么每天优化带来的收益就是10万乘以1%再乘以0.1，等于100元。听起来不多，但换算到一个月就是3000元，一年就是3.6万元。而这还只是首屏一项指标。
同样的算法还可以套在资源体积上。图片从PNG换成WebP，平均单张图从200KB降到40KB，如果每天有50万次图片请求，那每天省下的CDN流量成本是很好算的。把这些账算清楚，你再拿着方案去找产品经理或老板申请资源，说服力完全不一样。这也是为什么我一直强调，做优化的人不能只懂代码，你得懂业务指标和成本结构，不然你做的优化在公司眼里就是“自嗨”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 前端优化的核心维度：别只盯着首屏时间
2.1 加载性能：资源体积、请求数量、网络链路的博弈
加载性能是前端优化里最经典、也最容易被量化的部分。它包含三个关键变量：资源体积、请求数量、网络链路。
资源体积决定了传输的“吨位”，JS、CSS、图片、字体，每一个字节都在消耗用户的流量和时间。请求数量决定了建立的连接数，尤其是在HTTP/1.1时代，浏览器对同一域名有并发连接数限制，资源再多也是排队加载。网络链路则决定了数据从服务器到用户设备的实际耗时，包括DNS查询、TCP握手、TLS握手、内容传输等环节。
这三个变量是互相牵连的。资源体积压缩了，传输时间变短；请求数量减少了，队头阻塞减轻；网络链路优化了（比如上CDN就近访问），往返时间缩短。但你必须理解，它们不是完全独立的：压缩资源可以减小体积，但如果你做了一个超大体积的的雪碧图，虽然请求数少了一个，但体积反而可能比分开加载还大。我在实际项目中见过很多这样的反面案例，把几十张图标合成一张雪碧图后，整张图500KB，而用户只是来看文章内容的，永远不会点开某些图标。优化的核心是“权衡”，不是“极致”。
注意：很多优化方案之间存在冲突。比如资源合并是为了减少请求数，但过度合并会导致单文件过大，反而阻塞首屏渲染。做优化之前，先明确你的核心目标是什么，再决定用哪套方案。
2.2 渲染性能：从HTML到像素的每一帧
加载性能解决的是“资源到了没有”，渲染性能解决的是“到了之后能不能画出来、画得快不快”。浏览器的渲染流程大体是：解析HTML生成DOM树，解析CSS生成CSSOM树，两者合并成渲染树，然后经过布局、绘制、合成，最终出现在屏幕上。
这里有一个经常被忽视的点：JavaScript的执行会阻塞DOM解析。当浏览器在解析HTML时遇到一个<script>标签，它必须停下来，先下载并执行完这段JS，才能继续解析后续的HTML。如果JS放在头部并且体积很大，白屏时间就会显著拉长。这是很多项目性能差的直接原因。解决方案也很成熟，要么把脚本放到<body>底部，要么使用defer或async属性，要么干脆用ES Module的异步加载能力。
渲染层还有一个高频问题就是“布局抖动”，也叫强制同步布局。当你连续读取offsetTop、offsetHeight这样的属性，同时又在修改DOM样式时，浏览器会被迫中断正在进行的渲染流程，提前执行一次布局计算。一次两次没什么感觉，但在一个循环里反复操作，页面就会掉帧。正确做法是先批量读取，再批量写入，或者用requestAnimationFrame把读写分到不同帧里。
2.3 构建性能：开发体验与CI效率的隐性损耗
很多公司只关注线上性能，忽略了构建性能。但我可以负责任地说，构建性能会真实地影响业务交付速度。举个很常见的场景：项目里引入了十几个大依赖，每次启动开发服务器都要等2分钟，每次打包部署都要跑10分钟。假设一个团队10个人，每个人每天打包5次，一天下来就是50次，每次多等5分钟，一天就浪费了250分钟。这不是小数字。
构建优化的手段也比较固定：按需引入第三方库、开启持久化缓存、引入多线程构建、合理配置SplitChunks、把不会再变的第三方库用DllPlugin或Module Federation单独预构建。团队规模越大，构建优化的ROI越高。所以我一直建议团队把“构建耗时”也放到性能监控的看板上去。
我在实际项目里做过一次Webpack 4到Webpack 5的升级，配合SWC替换Babel做转译，开发服务器冷启动时间从约40秒降到了8秒，增量构建从约3秒降到0.5秒。团队同学当时最直观的感受是“开发终于不用等编译了，手感和原生开发差不多”。从那之后，我再也没有把构建性能当成“不紧急不重要”的事。
2.4 运行期内存与长任务：移动端的隐形杀手
加载和渲染问题在PC端比较容易被感知，但运行期内存和长任务问题，几乎只在移动端暴露出来。低端安卓机的内存一般在4GB以下，可用内存可能只有1GB多，浏览器分到的内存更少。如果页面的全局变量、事件监听器、定时器没有及时清理，内存就会持续攀升，最后浏览器为了保命只能回收页面。
长任务就更隐蔽了。一个任务执行时间超过50ms，用户就会感觉到卡顿；超过1000ms，页面基本处于假死状态。长任务的来源通常是主线程上的复杂计算、大规模DOM操作、JSON解析、正则匹配等。遇到这种任务，标准做法是把任务拆成小片，用setTimeout或requestIdleCallback分片执行，或者直接用Web Worker丢到子线程去算。我自己经手过一个数据报表项目，需要在浏览器端对几万条数据做透视聚合，直接在页面里算要卡3秒，用Web Worker之后，页面瞬间清爽，这种体感差异用户是能明确感知到的。
实操心得：排查长任务不要靠肉眼。打开Chrome DevTools的Performance面板，录一段用户操作，看主线程的火焰图里有没有红色的Task块。红色基本就是长任务，点开能看到具体是哪个函数占用了时间。这是定位卡顿问题的第一选择。
3. 实际优化路径：从测量到落地一条龙
3.1 先测量再动手：指标和工具到底怎么用
我见过太多人一上来就“优化”，压缩图片、上CDN、开Gzip，一顿操作猛如虎，结果打开控制台一看，首屏时间还是3秒。原因很简单：你没测量出瓶颈在哪，怎么知道瓶颈是图片还是JS还是接口慢？
正确顺序应该是：先量化，再定位，最后优化。量化的核心指标有几个需要你记住：FP（First Paint，首次绘制）、FCP（First Contentful Paint，首次内容绘制）、LCP（Largest Contentful Paint，最大内容绘制）、CLS（Cumulative Layout Shift，累积布局偏移）、INP（Interaction to Next Paint，交互延迟）。这几个指标有明确的行业标准参考线：LCP在2.5秒以内算好，CLS小于0.1算好，INP小于200ms算好。
工具方面，我最常用的组合是这三件套：Lighthouse做整体评分和优化建议，Chrome DevTools Performance做运行时分析和长任务定位，WebPageTest做多机型多网络环境的真实场景测试。Lighthouse适合“体检”，Performance适合“手术”，WebPageTest适合“跨地域复测”。三个工具各有侧重，结合起来才能把页面从宏观到微观都看清。
我自己接手项目的第一周，从来不会改代码，只干一件事：把项目的首页、列表页、详情页分别在3G、4G、WiFi环境下跑一遍Lighthouse和WebPageTest，把所有指标记录下来，列成一张表。这张表就是后面所有优化工作的基线。没有基线，你后面做的任何优化都说不清楚到底有没有效果。
3.2 资源层优化：压缩、拆包、缓存与CDN
资源层的优化是见效最快、也最容易操作的，我按优先级给你排个序：
第一优先级是图片优化。大部分项目图片占的带宽超过60%，但很多团队对图片的优化只停留在“压缩一下”。正确做法是根据场景选格式：照片用WebP或AVIF，图标和Logo用SVG，纯色小图可以用PNG甚至Base64（但要控制大小）。图片尺寸要在服务端根据实际展示区域下发，而不是把2000px的图缩到300px显示。响应式场景用srcset，让浏览器按需选择。
第二优先级是代码拆包。现代打包工具默认都会做代码分割，但默认配置往往不够好。我习惯把第三方依赖单独拆成一个vendor包，把业务代码按路由拆成多个chunk，再把“首屏不需要”的模块用动态import()包起来。这里的关键是：拆分粒度不能太细也不能太粗。太细会导致请求数暴增，太粗又起不到按需加载的作用。我一般以“路由级拆包 + 公共模块单独抽离 + 单包不超过500KB”为标准。
第三优先级是静态资源缓存和CDN。缓存策略直接影响二次访问的速度。静态资源文件名带hash，设置长缓存，比如Cache-Control: max-age=31536000；HTML文件设置no-cache，保证每次能拿到最新页面。CDN解决的是物理距离问题，把静态资源分发到离用户最近的节点。这里有个容易踩的坑：CDN上的文件名必须是带hash的，否则你更新了代码，CDN可能还在用旧缓存给用户发货。
提示：图片上传时如果能把“原图未压缩”这个问题从源头解决掉，比什么优化方案都强。我经历过一个项目，运营直接上传一张5MB的原始照片，服务端没做任何处理，图片优化做得再好也没用。建议在服务端做上传即压缩、按规格裁剪的链路。
3.3 渲染层优化：懒加载、骨架屏、虚拟列表
渲染层的优化目标只有一个：让用户越快看到内容越好，让交互过程越顺滑越好。
懒加载是首屏之外的资源常用的手段。图片懒加载用loading="lazy"就能搞定，只对首屏以外的图片生效；组件懒加载配合路由懒加载，让用户访问到哪个页面才加载哪个页面的代码。这里有个细节：懒加载不能盲目用。首屏内的图片不能懒加载，否则浏览器要额外执行JS去判断元素是否进入视口，反而拖慢首屏。LCP对应的图片需要预加载，否则首屏最大元素会晚一步出现。
骨架屏是我强烈推荐的一项体验优化。它的核心价值不是性能提升，而是感知性能提升。数据还没回来的时候，页面先用灰色块勾勒出内容布局，用户知道“内容正在加载”，而不是面对一块白屏。有数据表明，同样的加载时间，有骨架屏的页面用户感知等待时间显著更短。实现方案不复杂，可以直接手写一个占位组件，也可以用vue-content-loader这样的现成库。
虚拟列表解决的是长列表的性能问题。一次性渲染一万条DOM，浏览器直接卡死，这是必然的；虚拟列表的思路是，不管数据有多长，永远只渲染用户可视区域内的几十条。这个方案看起来很美，但实现起来有几个坑：要准确计算每一项的高度（或自适应测量）、要处理滚动条模拟、要在快速滚动时防止白屏。如果用的是React，可以直接用react-window或react-virtualized；Vue就用vue-virtual-scroller。这些库已经非常成熟，不建议你从零造轮子，除非你的场景极其特殊。
3.4 代码层优化：JS执行成本、SSR/CSR选型、Web Worker
有一类优化是只改代码逻辑，不碰工程配置，我把它归为代码层优化。这类优化要求你对JavaScript语言的执行特性有比较深的理解。
先说JSON的处理。很多人不知道，JSON.parse在解析大字符串时是非常耗性能的。有个热搜词是“json.stringify 前端性能优化”，这确实是个常见的优化点。比如你在前端把一个多字段的对象通过JSON.stringify转成字符串，再传给后端；如果这个对象里有很多无用的字段，比如后端根本不在乎的临时状态，那stringify的时间和传输的体积都是纯浪费。更好的做法是，在发送之前先把对象清洗一遍，只保留需要提交的字段。同理，JSON.parse要注意数据量，一个几MB的JSON字符串解析起来，主线程是明显会卡的。
另一个值得展开的是SSR/CSR选型问题。很多人以为SSR是为了SEO，其实SSR最关键的价值是首屏性能。在弱网和低端机上，纯CSR要先下载JS、再解析执行、再请求数据、再渲染内容，四步走完黄花菜都凉了；SSR在服务端就把HTML拼好，用户拿到的第一口就是有内容的。代价是服务端成本上升，且需要处理组件在服务端渲染时的副作用问题。如果你做一个To B后台系统，不建议上SSR，因为用户大多在办公网络里，CSR够用且简单；如果是To C的内容产品、电商落地页，强烈建议评估SSR或至少做预渲染。
对于大计算量的任务，比如模板渲染、数据转换、加密/解密、图片处理，能用Web Worker就扔给Web Worker。Web Worker是浏览器里的独立线程，独自跑逻辑，不会阻塞UI更新。但要注意，Worker里不能直接操作DOM，不能访问window对象，数据通过postMessage做结构化克隆传递。大文件上传场景也可以结合Worker，把文件分片的哈希计算放到子线程里，避免上传前计算哈希导致页面卡顿。
4. 优化落地后的工程化止损：让优化成为一种持续行为
4.1 优化成果会退化：没有机制保护的优化撑不过半年
很多团队做优化是“一次性工程”：这个季度性能差，大家冲一把，指标好看了；下个季度新功能上线，又是一顿堆代码，性能又回去了。为什么？因为性能优化没有一个“护城河”，代码只要继续演进，就一定会引入新问题。
我用一个真实例子来说明。某项目原来首屏体积控制在200KB以内，后来加了一个富文本编辑器、一个图表库、一个拖拽组件，每个人都是在“自己负责的页面”里加依赖，觉得自己加的几十KB不算什么。但半年之后，入口文件的体积变成了2MB。没有人故意做坏事，每个人都是“合理”地加了一个东西，但合在一起的后果是很可怕的。
所以优化必须工程化，必须有机制兜底。机制包含三个层面：工具层面有Lighthouse CI，流程层面有性能预算审批制度，文化层面有定期的性能Review。这三个我都建议团队逐步建设，缺一个都不稳。
4.2 配置Lighthouse CI：把性能检查接到每一次提交里
Lighthouse CI是我认为性价比最高的一项工程化改造。它的核心理念是：把Lighthouse跑在CI流水线里，每次提交代码时自动测量性能指标，如果指标低于预设的阈值，构建直接失败。
接入流程不复杂：本地装@lhci/cli，写一个lighthouserc.js配置文件，里面指定要检测的URL、模拟的设备和网络条件、性能预算。预算可以具体到“LCP不得大于2.5秒”“TotalBlockingTime不得大于200ms”“最大JS文件不超过300KB”。CI构建时跑一遍，把结果上传到Lighthouse CI服务器或输出到控制台注释。如果某一次提交导致性能回退，PR就会被卡住，开发者必须处理或明确说明原因。
这个机制的价值不只是“拦住坏人”，更重要的是它把性能变成了一种团队共识。新人进来写代码，不用谁跟他反复强调“注意性能”，CI会在他的第一个PR里就给他上一课。我个人认为，这是所有工程化优化里最值得先做的一件事。
4.3 性能监控与数据上报：上线之后不是结束，而是开始
很多团队做完性能优化就“完事大吉”，实际上，上线之后的工作比优化本身更重要——性能监控。我给自己的项目定的规矩是：核心页面必须接入真实用户监控，也就是RUM（Real User Monitoring）。用PerformanceObserver监听FCP、LCP、CLS、INP这些指标，把数据通过navigator.sendBeacon在页面卸载时上报到自己的打点服务。
埋点方案整体不复杂，难的是数据出来之后怎么用。我是这样看的：每月固定看两个数的变化趋势，一个是核心页面的LCP中位数，一个是有性能问题的用户比例。如果LCP中位数稳中有降，说明优化在生效；如果突然上涨，立刻回看发布记录，定位是哪个版本带进来的。有了这套监控，你就不会等用户投诉才去优化，也不会优化完之后不知道效果是持久还是短命。
4.4 团队规范与文档沉淀：经验这种东西，不写下来就归零
做优化做得多了你会发现，很多“经验”其实就是那么几条，比如“第三方脚本要异步”“图片要压缩”“循环里的DOM操作要收敛”。但每一条经验背后都是踩坑踩出来的。如果这些经验只存在个别老员工脑子里，他一旦离职，这些经验就归零了。
所以我特别建议维护一份“前端性能优化手册”之类的文档，不需要多厚，但要把每个项目的基线数据、做过哪些优化、优化前后的对比、踩过什么坑都记下来。这份文档的价值不在于“写得好看”，而在于新人在看代码时能快问快答。文档的形态不限制，可以是仓库里的MD文件，也可以是内部知识库的一个专栏。关键是内容要死磕细节。比如写“图片压缩”这一条时，别只写“图片要压缩”，要写明“我们的场景是电商列表页，缩略图用400宽的WebP，质量系数75，体积控制在30KB以内，超出的自动降级JPEG”。
注意：规范不是“说一说”就行的。如果你没有CI卡口和监控告警，你自己定的规范大概率会在半年内变成一纸空文。规范要配机制，机制要比规范更狠。
5. 常见问题与排查技巧实录
5.1 明明做了懒加载，为什么首屏还是慢？
这个问题我在实际项目中遇到过太多次。排查思路很简单：先把懒加载去掉，看看首屏是不是变快了。如果变快了，说明懒加载本身拖累了首屏；如果还是一样的慢，说明瓶颈根本不在这里。
最常见的原因有两个：一是把首屏内的资源也加了懒加载，导致浏览器要先执行一段JS去判断资源是否在视口内，反而阻塞了渲染；二是懒加载的占位图做得不对，占位图本身是一个很大的透明图片，或者组件初始化时就加载了所有图标。建议按这个顺序检查：先看首屏HTML里有没有内联的关键CSS，再看首屏资源有没有被preload，最后检查首屏内的图片是不是用了loading="lazy"。
还有一个小细节：很多懒加载库实现方式是监听scroll事件，而scroll事件触发频率极高，如果每次触发都去判断所有图片的位置，性能就非常差。现在好一点的方案是使用IntersectionObserver，它在浏览器层面做了优化，回调只在目标元素与视口交叉状态变化时触发，性能好得多。
5.2 图片已经压缩了，流量为什么还是那么高？
“压缩”和“流量下降”不能直接画等号。我排查过许多案例，最后发现原因往往是：代码里引用的是@2x或@3x的高清图，而图片的展示尺寸只有60px宽。单张图压得再小，架不住它是2000px宽的图。服务端如果不管你传什么图都原样存储，那么前端再怎么压也只是“亡羊补牢”。
正确做法是，在图片上传链路上就做处理：根据展示场景生成的裁剪规格，比如400px、800px、1200px几个挡位，前端根据容器宽度选择最合适的尺寸。另外要检查图片的缓存命中率，如果静态资源服务器没有设置长缓存，用户每次刷新都要重新下载图片，流量自然居高不下。我在排查一个慢速项目时发现，图片响应头里没有Cache-Control，用户每次返回上一页，所有图片全部重新请求，这流量和时间的浪费是非常冤枉的。
5.3 文件拆成很多个小包之后，为什么反而更慢了？
代码拆包拆得太过细碎，会在加载时触发大量小文件的并行请求。HTTP/1.1下浏览器对同一域名的并发TCP连接数有限，一堆小文件排着队等，整体加载时间反而被拉长。即使上了HTTP/2，连接复用可以缓解队头阻塞，但请求太多也会增加开销，因为每个请求都有headers要传。
常规的经验值是：首屏请求数控制在20个以内比较合理，单个JS文件体积在100KB到300KB之间更合适。拆包的时候先看构建产物的分析报告，比如用webpack-bundle-analyzer，找出哪里是体积大头，然后有针对地拆，而不是无脑按模块全拆。拆包的核心目标是“首屏只加载首屏需要的”，不是“能拆多少拆多少”。
5.4 加了CDN之后，遇到缓存不更新的问题怎么办？
加CDN后最常见的报错叫“此图片未经允许不可引用”，这类问题不是你权限配错了，通常是CDN上的旧资源没有失效，访问到的是一个被限制的旧版本。处理思路是：确认CDN刷新是否生效，一般CDN服务商都提供URL刷新接口，可以把新版本的URL主动刷新一遍；还有一种情况是Cache-Control设置的是max-age=604800这类长缓存，新版本上线后文件名如果没变，CDN会一直给老资源。所以静态资源的文件名带hash是标配，这样每次发版都会生成全新的URL，不存在“缓存不更新”的问题。
如果你自己控制产出文件名的规则，可以把hash改成内容hash，比如app.8f3d2a.js，文件内容变了hash才变。这比时间戳方案更合理，因为内容没变的文件hash不变，用户还能继续命中旧的缓存，不必为了某个小改动重新下载所有JS。
结尾
这篇文章写得比较长，但我觉得“前端为什么需要优化”这个问题值得被这样对待。它不是一个能靠背答案解决的问题，它需要你真正理解加载、渲染、体验之间的层次关系，知道测量先于优化，懂得用工程化机制让优化成果活得更久。
我个人在实际项目里最大的感受是：优化这个事情，不是一次性的“冲刺”，而是一种持续的质量意识。你不需要每次提交都追求指标满分，但你要让团队养成“动代码之前先想会不会影响性能”的习惯。这个习惯一旦建立起来，很多问题根本不会到线上才暴露。
最后再分享一个小技巧：做任何优化之前，先在本地跑一遍Lighthouse，把优化前的分数截图存档。改完之后再跑一遍，对比两张截图。这个习惯坚持下来，你会发现你对“哪些优化手段真正有效”的理解，会远远超过那些只会背八股文的人。优化这条路没有终点，但每一步都可以被测量、被验证、被沉淀。希望这篇内容对你有用。