别盲目改代码，先盯死这3个致命指标
打开 PageSpeed Insights，输入你的网址。听我一句劝，别去死磕那个综合评分，直接看底部的 Core Web Vitals（核心网页指标）。这3个数据才是决定用户去留的生死线。
最大内容绘制，决定用户多久看到核心画面
累积布局偏移，决定页面元素会不会乱跳
交互到下一次绘制，决定点击按钮后卡不卡
LCP 就是用户看到首屏大图的时间，CLS 是按钮突然移位导致点错的元凶，INP 则是交互延迟。顺便提一句，INP 已经正式替代了 FID（首次输入延迟），它更能反映页面在整个生命周期中的交互响应能力。这三个指标飘红，你的转化漏斗就已经漏成了筛子。
图片瘦身：把MB级大图砍到KB级的魔法
移动端流量寸土寸金，一张 2MB 的 Banner 图就能让 4G 网络下的加载时间多出 3 秒。别再用传统的 JPG 死磕了，现在是 WebP 和 AVIF 的天下。
- 使用 Squoosh 或 TinyPNG 批量压缩现有图片
- 将首屏核心大图转为 WebP 格式，体积能砍掉 60%
- 为非首屏图片添加 loading='lazy' 属性实现懒加载
- 在 HTML 中使用 srcset 提供多尺寸适配移动端
如果你的业务对图片质量要求极高，可以尝试 AVIF 格式，它的压缩率比 WebP 还要高出 20% 左右，目前主流浏览器都已全面支持。
记住，永远不要为了高清而牺牲速度。在手机上，用户根本看不出 1080P 和 720P 的区别，但他们能瞬间感知到页面是秒开还是转圈圈。
代码脱水：干掉阻塞渲染的隐形杀手
很多建站团队喜欢堆砌华丽的特效，结果 CSS 和 JS 文件动辄几百 KB，直接阻塞了页面的首次渲染。代码必须脱水，只保留用户第一眼能看到的内容。
给非关键的 JS 加上 defer 或 async 属性，让它们在 HTML 解析完再执行。用 PurgeCSS 工具扫描项目，无情地删掉那些根本没被使用的 CSS 代码。
你可以使用 Critical 这样的开源工具，自动提取出首屏关键 CSS，剩下的部分再通过 link 标签异步加载。对于复杂的现代前端框架，务必开启 Tree Shaking 功能，确保打包出来的代码没有一丝多余的脂肪。
加速分发：让服务器就近吐出数据
物理距离是网速的天敌。如果服务器在北京，广州的用户访问必然慢半拍。CDN 的本质，就是把数据提前缓存到离用户最近的边缘节点。
不要让用户跨越千山万水去请求一张图片，CDN 就是那个把仓库建在用户家门口的物流系统。
配置阿里云、腾讯云或 Cloudflare 的 CDN 服务，并设置合理的缓存策略。静态资源（图片、CSS、JS）设置强缓存 Cache-Control: max-age=31536000，让浏览器直接读本地缓存。HTML 文件则设置协商缓存，确保内容更新。
在 HTML 头部加上 标签，提前与 CDN 域名建立连接，这能省下几百毫秒的 DNS 解析和 TCP 握手时间。记住这个公式：CDN节点覆盖 + 强缓存策略 = 秒开体验。
移动端特供：砍掉自嗨的冗余设计
PC 端看着很酷炫的视差滚动、全屏背景视频，到了移动端就是灾难。移动端优化的核心原则是：做减法。
- 延迟加载非核心的第三方脚本（如客服弹窗、社交分享组件）
- 使用 font-display: swap 防止自定义字体加载时的白屏闪烁
- 对字体文件进行子集化（Subsetting），只保留用到的汉字
- 精简 DOM 节点数量，尽量控制在 1500 个以内
如果某些数据必须异步请求，用骨架屏（Skeleton Screen）代替传统的 Loading 菊花图，能大幅降低用户的心理等待时间。
终极验收：拿什么证明优化真的有效？
优化完不是结束，没有数据支撑的优化都是自嗨。你需要建立一套长效的监控机制，确保网站性能不会随着后续迭代而退化。
用 PageSpeed Insights 复测，这只是实验室数据（Lighthouse）。更重要的是接入 Google Search Console，查看真实的 CrUX（Chrome 用户体验）数据，这才是真实用户在真实网络环境下的表现。
设定性能预算（Performance Budget），比如首屏 JS 不能超过 200KB。每次发版前跑一遍自动化测试，超标就打回重做。
实验室数据 + 真实用户数据双管齐下