上周朋友发来一个链接，说他们首页加载要五秒。我打开一看，白屏三秒，然后内容哗啦一下全出来。LCP直接爆表。这不是个例。
前端性能优化这事，说复杂能写本书，说简单就是别让用户等。但怎么等，等多久，等的时候看什么，全是取舍。
先搞清楚浏览器在忙什么
你打开一个页面，浏览器先要下载HTML，解析出DOM。遇到CSS，它得停下来构建CSSOM。遇到同步JS，它还得暂停解析去执行。这期间页面就是白的。
很多人一上来就压缩图片、上CDN。方向没错，但顺序可能反了。你先得知道哪个资源在阻塞渲染。打开DevTools的Performance面板，录一下。看到那条长长的紫色块了吗？那就是在算样式和布局。关键渲染路径上的资源越少越好。
比如，把首屏不需要的CSS拆出去。用media属性或者rel=preload。JS呢，加defer或者async。别把一堆polyfill塞在head里同步执行。说实话，现在浏览器都支持ES6了，Babel转出来的代码有时候比原生还大。
还有字体。自定义字体一加载，文字可能先隐形再出现，这叫FOIT。用户体验很糟糕。用font-display: swap让文字先用系统字体渲染，字体加载完再替换。但换的时候可能会闪一下，自己权衡。
别让首屏等太久
首屏时间怎么砍？代码分割是常规操作。但切得不对，反而更慢。比如每个路由一个chunk，但用户点第一个页面就要下载主包加路由包。主包如果太大，还是白屏。
我的做法是，把首屏用不到的组件、第三方库、工具函数全拆出去。用动态import。但要注意，动态import的模块如果依赖主包里的东西，可能还是得等。这事没那么玄，就是看网络瀑布流。
图片优化更是重灾区。一张2MB的banner图，直接拖慢LCP。用WebP或者AVIF，尺寸按需给。别一张图缩到200px宽还传原图。懒加载用loading=’lazy’，但首屏图片别懒加载，否则LCP更差。
缓存策略也得细。强缓存给带hash的资源，一年都行。HTML用协商缓存，别强缓存，不然更新不了。CDN边缘节点要选对，别跨运营商。
preload是告诉浏览器这个资源很重要，赶紧下。prefetch是告诉浏览器这个资源未来可能用，空闲时下。别滥用preload，不然带宽被抢，反而拖慢首屏。preconnect是提前建连，DNS、TCP、TLS。但建连多了也耗资源，只对关键域名用。
交互卡顿比白屏更烦人
白屏忍几秒就过去了。但点个按钮半天没反应，用户会骂人。这往往是因为主线程被长任务堵住了。
一个函数跑了200ms，期间用户点啥都没用。用Performance面板看，火焰图里那个长条就是罪魁祸首。把大任务拆成小任务，用setTimeout或者requestIdleCallback。或者丢给Web Worker。但Worker通信也有开销，别啥都往里塞。
重排重绘是老生常谈。但很多人改样式时，还是一个个改。最好用class一次性改，或者用cssText。读取offsetHeight这种属性会强制同步布局，别在循环里读。
列表渲染用虚拟滚动。只渲染可视区域。但滚动事件要节流，用passive: true。动画用transform和opacity，别碰width和left。
还有事件处理。比如输入框搜索，别每敲一个字母就发请求。防抖，等用户停300ms再发。滚动加载，用节流，别一滚就查。这些老办法，现在依然管用。
监控不是看个总分就完事
实验室数据（Lighthouse）和真实用户监控（RUM）是两回事。你本地跑个100分，用户手机上可能只有30分。因为设备性能、网络环境千差万别。
用PerformanceObserver监听LCP、CLS、INP。把数据上报。但别只看平均值，要看长尾。P75、P95才是真相。有些用户可能用着三年前的安卓机，你的优化对他们来说就是杯水车薪。
第三方脚本是性能黑洞。一个统计代码，一个客服SDK，一个广告。它们可能同步加载，可能跑一堆计算。能异步就异步，能延迟就延迟。实在不行，跟业务方吵一架。
另外，别忽略内存泄漏。页面用久了越来越卡，可能是监听器没解绑，或者闭包引用了DOM。用Chrome的Memory面板拍快照对比。
最后说个案例。之前有个项目，首屏加载慢。查了半天，发现是某个UI库按需引入没配好，整个库都打进去了。换了配置，体积从1.2MB降到300KB。就这一下，LCP从4.5秒到2.1秒。所以，别急着上黑科技，先看看打包产物。
优化没有银弹，只有取舍。你省了首屏，可能就丢了交互。你加了缓存，可能就踩了更新不及时的坑。多测，少猜。