前端性能优化：全链路进阶

2024前端性能优化全链路：从CRP到Core Web Vitals新标准

简单来说，咱们做性能优化，不能只盯着打包体积看。2024年了，如果你还在只关注首屏加载快不快，那你真的有点跟不上时代了。现在的性能优化讲究的是全链路，从你输入 URL 那一刻，到页面完全可交互，每一个环节都得抠。

咱们先聊聊 CRP（关键渲染路径）。很多新手一听到这个词就头大，其实没那么玄乎。你可以把它想象成浏览器在“拼图”。浏览器拿到 HTML 后，得先把 HTML 变成 DOM，把 CSS 变成 CSSOM，然后这俩一结合生成渲染树，最后再布局、绘制出来。这个过程的痛点在于，CSS 和 JS 都会阻塞渲染。如果你的 CSS 放在特别后面，或者 JS 没处理好，用户就会盯着白屏干等。

核心要点来了，2024年3月 Google 正式更新了 Core Web Vitals (CWV) 新标准。这可是个大动作，最大的变化就是 INP（Interaction to Next Paint）正式取代了 FID（First Input Delay）。以前我们用 FID 衡量“用户点击后浏览器多久才有反应”，但 FID 有个坑，它只测第一次交互的延迟。现在换成 INP，它衡量的是整个页面生命周期内所有交互的响应延迟。打个比方，就是现在更看重你在页面上疯狂点点点的时候，页面卡不卡，而不是只测那一下的反应速度。

除了 INP，另外两个核心指标还是老朋友：LCP（最大内容绘制）和 CLS（累积布局偏移）。LCP 看的是加载速度，CLS 看的是视觉稳定性（比如图片突然把文字挤下去了，这种体验极差）。

那在全链路优化里，我们怎么结合这些指标呢？

在 DNS 解析和 TCP 握手阶段：利用 dns-prefetch 和 preconnect 提前建立连接。
在请求和响应阶段：通过 HTTP/2 或 HTTP/3 的多路复用减少队头阻塞。
在 CRP 阶段：把关键的 CSS 内联，把非关键的 JS 加上 async 或 defer，别让它们挡着浏览器干活。
在渲染阶段：盯着 INP 指标，把那些执行超过 50ms 的“长任务”给拆了。

来个实战配置，这是我在项目里常用的头部优化策略，直接放在 HTML 的里，专门针对 CRP 进行优化：

<head>
    <!-- 预连接：告诉浏览器我们马上要连这个域名，提前把 TCP/TLS 握手做了 -->
    <link rel="preconnect" href="https://api.example.com">
    <link rel="preconnect" href="https://cdn.example.com">
    
    <!-- 预解析 DNS：针对第三方域名，如果不想建立完整连接，至少先解析 IP -->
    <link rel="dns-prefetch" href="https://fonts.googleapis.com">
    
    <!-- 内联关键 CSS：把首屏必须的样式直接写在这里，避免额外的请求等待 -->
    <style>
        /* Critical CSS for above-the-fold content */
        body { margin: 0; font-family: sans-serif; }
        .header { height: 60px; background: #333; }
        /* ... 其他关键样式 ... */
    </style>
    
    <!-- 非关键 CSS 异步加载：使用 preload 加载，但通过 onload 回调切换为 stylesheet -->
    <link rel="preload" href="/styles/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="/styles/main.css"></noscript>
    
    <!-- JS 处理：如果是非首屏必需的，一定要加 defer -->
    <script src="/scripts/analytics.js" defer></script>
</head>

💡 经验总结：别盲目追求 100 分。很多时候为了优化 CRP，我们会把首屏 CSS 内联，但这会导致 HTML 文件变大。如果你的页面是服务端渲染（SSR）的，每次 HTML 变了，内联的 CSS 也会跟着变，导致缓存失效。这时候就要权衡一下，是用缓存换 CRP 速度，还是用 CRP 速度换缓存。通常建议只对 LCP 元素相关的 CSS 进行内联，别把整个 node_modules 里的 CSS 都塞进去。

资源加载与构建优化：HTTP/3、Brotli压缩与Vite代码分割实战

聊完渲染路径，咱们得看看“货”是怎么运过来的。资源加载优化，其实，怎么让文件更小、路更短、跑得更快。

先说传输协议。现在都 2024 年了，如果你还在用纯 HTTP/1.1，那真的得升级了。现在的主流是 HTTP/2，甚至很多大厂已经在全面切 HTTP/3 (QUIC) 了。HTTP/2 的多路复用解决了队头阻塞，但 TCP 层的阻塞还是存在。HTTP/3 基于 UDP，彻底解决了这个问题，特别是在弱网环境下，速度提升非常明显。不过这通常需要运维在 CDN 层面配置，前端同学只要确保域名支持就行。

再说压缩。Gzip 是老黄历了，Brotli 才是现在的王。Brotli 的压缩率比 Gzip 高得多，尤其是在处理文本文件（JS、CSS、HTML）时。你只要在 Nginx 或者 CDN 配置里开启 Brotli，通常能再省下 20% 左右的流量。

重点要聊的是构建工具。以前我们用 Webpack，冷启动慢得让人怀疑人生。现在 Vite 这种基于原生 ESM 的工具简直是救星。Vite 利用浏览器原生的