前端性能优化：从请求到资源的精细调控
在用户体验为王的时代，前端性能直接决定产品的留存率。本文聚焦 “减少不必要的传输与加载损耗”，从 合并HTTP请求、启用压缩、减少Cookie、资源加载顺序 四个维度，拆解优化思路与落地方法。
一、合并HTTP请求：突破浏览器并发瓶颈
核心痛点：HTTP/1.1的并发限制
浏览器对同一域名的并发连接数有限（如Chrome为6个），过多请求会排队等待，拖慢整体加载速度。合并请求可减少连接建立、协议协商的开销。
落地实践：
-
资源合并：
- 雪碧图（CSS Sprites）：合并小图标为一张图，通过
background-position定位，减少图片请求数。 - 代码打包：借助Webpack将零散JS/CSS合并为 bundles，避免“请求爆炸”。
- 权衡：超大文件会阻塞首屏，需拆分临界资源（首屏必需）与非临界资源（懒加载）。
- 雪碧图（CSS Sprites）：合并小图标为一张图，通过
-
接口聚合：
- 后端提供合并接口（如将用户信息、商品列表接口合并为一个），或采用GraphQL灵活获取数据，减少HTTP往返。
-
案例参考：
某电商首页通过合并12个图标请求为1张雪碧图，接口聚合减少5次请求，首屏加载时间缩短200ms。
二、启用压缩：让传输“轻装上阵”
原理：文本资源的“瘦身术”
Gzip、Brotli等算法可对HTML、CSS、JS、JSON等文本类资源进行高比例压缩（Gzip压缩率达60%~70%，Brotli更优），大幅减少传输体积。
落地步骤：
-
服务器配置（以Nginx为例）：
gzip on; # 开启Gzip gzip_types text/html text/css application/json; # 指定压缩文件类型 gzip_comp_level 5; # 压缩级别（1-9，平衡性能与压缩率） gzip_brotli on; # 启用Brotli（需安装模块） -
前端配合：
- 静态资源（如JS/CSS）构建时预生成
.gz文件，减少服务器实时压缩开销。 - 图片类资源优先用WebP/AVIF（本身已压缩），避免重复压缩。
- 静态资源（如JS/CSS）构建时预生成
-
收益对比：
Brotli比Gzip压缩率高5%~15%，但需服务器支持；Gzip兼容性更优，二者结合可覆盖99%场景。
三、减少Cookie：为请求头“减脂”
隐藏损耗：Cookie的强制传输
Cookie会随同域名下的所有请求（包括静态资源）发送，冗余内容会大幅膨胀请求头体积（尤其移动端弱网环境）。
优化策略：
-
静态资源域名分离：
将图片、脚本部署到独立CDN域名（如cdn.example.com），避免携带主站Cookie（主站Cookie仅在example.com下传输）。 -
Cookie瘦身：
- 清理过期/无效Cookie，后端通过
Max-Age控制有效期。 - 精简内容：用短Token替代复杂用户信息，或迁移到LocalStorage（需权衡安全性）。
- 清理过期/无效Cookie，后端通过
-
效果验证：
某站点分离CDN后，静态资源请求头体积从500B降至80B，请求速度提升30%。
四、斟酌资源加载顺序：编排“优先级”提升首屏速度
浏览器渲染逻辑：资源加载决定渲染节奏
HTML解析时，CSS阻塞渲染、JS阻塞解析，资源加载顺序直接影响首屏可见时间。
优化方法：
-
关键资源前置：
- CSS放
<head>，优先构建渲染树； - 首屏交互JS（如支付逻辑）尽早加载，非关键JS（如统计脚本）后置。
- CSS放
-
懒加载与预加载：
- 图片懒加载：通过
loading="lazy"或Intersection Observer，延迟首屏外图片加载。 - 预加载关键资源：
<link rel="preload" href="font.woff2" as="font">，提前加载字体/脚本。
- 图片懒加载：通过
-
脚本异步化：
async（脚本下载完立即执行，无序）或defer（ DOM解析完执行，有序 ），避免阻塞HTML解析。
-
案例参考：
某新闻APP调整图片加载顺序，首屏图片优先加载，非首屏图片懒加载，首屏时间从3.2s降至2.0s。
总结：从“传输”到“加载”的协同优化
四个优化点环环相扣：
- 合并请求减少连接开销，压缩降低传输体积，减少Cookie瘦身请求头，资源排序提升加载效率。
实际落地需结合业务场景（如电商首屏需快速渲染，后台系统可侧重交互），通过Performance、Lighthouse持续监控，让优化更精准。
前端性能优化没有银弹，但每一处细节的打磨，都在提升用户的“秒开”体验 。