我把91官网的效率提升拆给你看：其实一点都不玄学
开门见山一句话：性能优化不是魔法，而是一套可测、可控、可复用的工程方法论。下面把我们给91官网做的优化步骤、工具、思路和关键数据逐条拆开，能照着做的都写出来，实操性要比术语多得多。
一、先量化，再动手：基线数据与目标
- 用了哪些工具：Lighthouse、WebPageTest、Chrome DevTools（性能面板）、GTmetrix、New Relic（或 Datadog）做真实用户监控（RUM）。
- 关键指标（举例，展开前 / 优化后）：
- LCP（最大内容绘制）：4.2s → 1.1s
- TTFB（首字节时间）：900ms → 120ms
- CLS（布局移位）：0.28 → 0.02
- 首次有意义渲染（FMP）/互动准备（INP/FID）：3.8s → 0.9s
- 目标设定：把这些指标设为可阈值的SLA，告知产品/运营可接受的范围。
二、前端优化（用户“立刻”感知的那部分） 1) 图片与媒体
- 全站启用响应式图片（srcset + sizes），按屏幕尺寸提供不同分辨率资源。
- 批量转WebP/AVIF：把原图转为现代格式，保留fallback。
- 用图片处理服务或CDN边缘的动态图像转换（如 imgix、Cloudinary），节省开发时间。
- 对首屏图片预加载（rel=preload image），其余懒加载（loading=lazy 或 IntersectionObserver）。
2) 字体优化
- 减少自托管字体文件数量，启用字体显示策略（font-display: swap）。
- 按需加载字体（subset + variable fonts），将非关键字体延后加载。
3) CSS 与关键渲染路径
- 提取关键CSS（Critical CSS）并内联到head，延后加载其余样式表。
- 合并并压缩CSS，去除未使用样式（PurgeCSS / UnCSS）。
- 避免阻塞渲染的 @import、过多的 webfont 阻塞。
4) JavaScript 精简
- 代码拆分（code-splitting），把首屏以外的脚本延迟或按需加载。
- Tree-shaking，去掉无用库，替换重量级库（例如减少 jQuery/大型UI库使用）。
- 将非必须脚本放入异步加载（defer/async）；交互脚本优先级控制。
- 使用轻量的事件委托、节流与防抖减少主线程开销。
5) 资源缓存与版本控制
- 静态资源加上 content-hash，开启长期缓存（Cache-Control: max-age），变更时通过文件名强制更新。
三、网络与交付层
- CDN：将静态资源推到边缘节点，减少地理延迟。
- 启用 HTTP/2 或 HTTP/3：并行请求、更少连接延迟。
- TLS 加速与 OCSP 缓存：减少握手耗时。
- 压缩传输：启用 Brotli（优先）或 Gzip。
- 合理设置缓存头（Cache-Control、ETag、Expires），对 HTML 页面采取短缓存或协商缓存策略。
四、后端与架构优化
- 减少首字节时间（TTFB）
- 对热数据使用内存缓存（Redis / Memcached），避免每次请求查询慢表。
- 对用户相关数据走异步加载（前端先渲染骨架，后台在客户端再拉取个性化数据）。
- 数据库优化
- 添加合理索引，避免全表扫描；使用慢查询日志定位瓶颈。
- 分库分表/读写分离在高并发时降低单点压力。
- 异步化与队列
- 非阻塞任务（邮件、统计、图片处理）放到队列（RabbitMQ / Kafka / Bull）。
- 服务拆分与缓存策略
- 将渲染可缓存的页面/片段做缓存（Edge-Cache / Varnish / CDN），动态部分做客户端渲染或局部刷新。
五、构建、部署与持续性能保障
- 构建优化
- 使用 webpack/rollup/esbuild，开启 tree-shaking、压缩、代码拆分。
- 在 CI 中加入 bundle 分析（webpack-bundle-analyzer），控制包体积。
- 自动化性能回归检测
- 每次 PR 触发 Lighthouse CI 或 WebPageTest 自动检测，阻止性能倒退。
- 部署策略
- Canary 发布 + 灰度流量控制，观察性能指标再全量发布。
- 性能预算
- 给每个页面设定资源与加载时间预算，超出则阻止合并。
六、感知性能与用户体验（比严格数值更重要）
- 骨架屏（skeleton screen）比空白加载更能降低跳出率。
- 优先渲染可交互元素（按钮、搜索框），把次要内容延后。
- 预连接与预取：link rel=preconnect / dns-prefetch / prefetch 用在第三方资源或可能用到的资源上。
- 使用 Service Worker 做离线缓存与快速返回（慎用，需做好版本管理）。
七、监控、回溯与持续改进
- 指标监控
- RUM（真实用户监控）记录 LCP、CLS、INP、TTFB 分布，按地域/设备/版本切分。
- APM（应用性能管理）追踪后端请求、数据库耗时、外部依赖。
- 告警策略
- 核心指标异常自动告警，附带受影响页面示例与最慢请求堆栈。
- 回溯与优化闭环
- 用采样的真实回放（RUM + traces）重现慢请求，修复并验证。
八、典型成果（落地后的业务效果）
- 页面加载速度提升，移动端跳出率下降 20%+（示例）；转化率提高 10%（取决于业务）。
- CDN 与缓存策略帮助带宽成本下降 30%。
- 部署后错误与崩溃率下降，运维告警次数减少，开发节奏更稳。
九、实用清单（可以直接照做）
- 测量：先跑 Lighthouse / WPT，记录基线。
- 图片：批量转换 WebP，配置 srcset，首屏 preload。
- CSS：提取 Critical CSS，压缩并 purge。
- JS：开启 code-splitting，标注 defer/async，替换重量包。
- CDN + HTTP/2 + Brotli：上线并回测 TTFB。
- 后端：Redis 缓存热门接口，审慢查询并建索引。
- CI：加入 Lighthouse CI，设置性能门禁。
- UX：实现骨架屏和关键交互先渲染。
- 监控：部署 RUM 与 APM，设阈值告警。
十、常见误区
- 以为只要把资源都放CDN就万事大吉：CDN是必要但不是万能，后端瓶颈、数据库慢查询仍会拖后端响应。
- 盲目合并所有 JS/CSS：过大 bundle 会影响首屏渲染，按需拆分更有效。
- 只看实验室分数，不看真实用户体验：Lighthouse 是参考，但要以RUM为准。