我刚接手一个老系统的性能优化时遇到过一桩挺典型的案例首页加载耗时接近8秒团队一连几周都在死磕数据库索引、并发参数、服务器配置指标一动没动。后来用浏览器开发者工具拉了一遍瀑布图真相其实特别朴素——页面里有一张未经压缩的素材图片体积4.5MB一个详情接口一次性返回了220多个字段而前端真正渲染用到的不到60个。那段时间我反复想一个问题我们总是习惯把“优化”理解成“让系统跑得更快”但在前端这个场景里很多时候最值钱的优化恰恰是“让系统少传一点”。“减少不必要的传输”看起来像是常识架构师真正把它当成一个独立的优化方向去设计和度量时才发现里面有大量策略取舍、技术选型和数据验证的工作。这篇文章面向的是系统架构师、在想做前端性能治理的后端工程师也包括正在备考系统架构设计师软考的朋友。它对应的内容是“前端优化思路”里的一个关键小节核心要解决三件事传输量到底该怎么衡量、哪些手段能真正削减传输、削减之后如何验证收益。我会把实际项目里的做法、踩过的坑、以及软考案例题里的常见答题角度一并串起来讲尽量让这份内容既能落地也能成为你知识体系里的一环。1. 传输量问题的度量与分析先搞清楚数据从哪来的1.1 用三个核心指标建立衡量口径做架构优化第一件事不是动手改代码而是建立可量化的口径。在“减少不必要的传输”这个方向上我习惯只看三个指标。第一个是页面总字节数。打开浏览器开发者工具的 Network 面板把页面首次加载产生的所有资源体积相加就是总字节数。这个数字直接决定了用户在弱网环境下的等待时长也是后续优化前后对比的基准值。第二个是请求总数。一个页面发起的HTTP请求数量影响了浏览器并发连接的限制、服务端的连接开销以及整条链路里每个环节的耗时累加。尤其对于 HTTP/1.1 时代的存量系统请求数量往往比体积更能卡住性能。第三个是不可复用率。这个指标很多人会忽略它指的是“本次加载中有多少字节是不能被缓存复用的”。比如接口返回的动态数据、未设置 Cache-Control 的静态资源、每次刷新都会重新下载的图片它们都属于不可复用的传输。我把这三个指标整理成一个简单的表方便在团队里统一语言指标含义典型优化目标总字节数页面首次加载下载的所有资源大小削减30%以上请求总数页面产生的HTTP请求数量合并或裁剪至合理水平不可复用率无法被缓存的传输所占比例尽量控制在合理区间为什么强调这三个指标因为它们把“减少不必要的传输”从一句口号变成了可执行的优化清单。总字节数高优先做压缩和图片优化请求总数多优先做合并和拆包策略不可复用率高优先做缓存治理和接口裁剪。1.2 从瀑布图到服务端日志完整的数据收集链路光有指标还不够你得知道数据从哪一层来。我的习惯是分三层看。第一层是浏览器端。打开 DevTools 的 Network 面板重点看每个请求的 Timings 区间Stalled、Waiting (TTFB)、Content Download。其中 Content Download 是纯网络传输耗时如果某个资源这块特别长说明它的体积需要瘦身TTFB 长则是服务端响应慢属于另一类问题。第二层是代理层。如果系统用了 Nginx 或者 CDN通过访问日志可以统计每个资源的流量占比。比如 Nginx 的 $body_bytes_sent 字段配合 $request_uri 就能统计出哪些URL占据了大部分带宽。我见过不少系统仅从这个维度就能轻易发现某张背景图占了全站流量的 40%——这显然就是“不必要的传输”的头号目标。第三层是服务端。通过应用日志和数据库慢查询日志能定位接口返回了大字段但前端用不上这种“隐性浪费”。例如一个商品列表接口每条记录都带着完整的富文本详情但列表页真的只需要缩略图和价格。这层浪费不像图片体积那么显眼但在接口层面的优化空间往往比静态资源还要大。值得注意的一个坑是开发环境的数据不具备参考价值。开发环境通常走本机代理、资源未压缩、接口未开缓存测出来的结论和线上完全两个样。做传输量度量务必基于线上环境或者生产镜像环境最好配合多网速模拟比如 WebPageTest 的 3G/4G 档位才能得到真实可用的数据。2. 压缩与格式选择让必须传输的内容变小2.1 文本压缩的工程配置gzip 与 brotli 的取舍文本类资源HTML、CSS、JavaScript、JSON、SVG是“减少传输体积”最直接的战场方案也最成熟压缩。几乎所有现代浏览器都支持 gzipNginx 默认也带相关模块所以很多团队“开了 gzip 就完事”。但如果你只做到这一步等于放弃了至少 15% 到 25% 的额外收益。gzip 的配置很简单核心参数就几个压缩级别、最小压缩阈值、压缩类型。这里给一份我在生产环境用的 Nginx 配置供参考gzip on; gzip_comp_level 5; gzip_min_length 1024; gzip_types text/plain text/css application/javascript application/json image/svgxml;几点经验说明。压缩级别gzip_comp_level不是越高越好。级别 1 到 9级别越高压缩率越好但 CPU 开销也越高而且超过 6 之后压缩率提升很有限。我在业务系统里直接用 5动态接口和高频接口不建议超过 6否则在高峰期会明显增加 CPU 负载。gzip_min_length 1k意思是小于 1KB 的资源不压缩。因为压缩本身有开销对小文件来说压缩后的体积可能反而更大gzip 有固定头部所以这个阈值是为了避免负优化。gzip_types 要写全。很多团队漏掉 image/svgxml导致 SVG 白白浪费了可压缩空间——SVG 本质是文本压一遍能小 70% 以上。再说 brotli。Br 是谷歌推出的压缩算法压缩率比 gzip 平均再高 15% 到 20%但有两个门槛一是需要 Nginx 编译了 ngx_brotli 模块二是浏览器需要支持 Accept-Encoding: br。主流浏览器基本都是支持的但如果你面向的是政企、老系统、老旧浏览器用户群就得谨慎。我的建议是CDN 层面如果支持 brotli直接用自建 Nginx 的话可以先保留 gzip 不做切换留到后面版本迭代时再评估避免为了一点压缩率引入兼容性风险。2.2 图片体积治理格式选择优先级与降级策略图片是前端传输体积的大头尤其对于营销页、电商系统。我记得一次性能分析里一个页面的总字节数是 2.1MB其中图片占了 1.8MB——这个结构非常典型。图片优化的核心逻辑是在满足视觉质量的前提下选择体积最小的格式。我的选择优先级是这样的首先能转 WebP 就转 WebP。WebP 在同等画质下比 JPEG 小 25% 到 35%比 PNG 小 50% 以上。现在浏览器对 WebP 支持率非常高用 CDN 的图片处理功能缩略、转格式、质量调整可以很轻松地在不改代码的情况下完成转换。其次AVIF。它是比 WebP 更激进的格式压缩率还能再提升 20% 到 30%但编码耗时和浏览器兼容性需要权衡。我的建议可以先小范围灰度不适合做全站默认。第三SVG 用于图标和简单图形。相比 PNG 格式的图标SVG 体积小、可缩放、可用 CSS 控制颜色很多场景应该优先使用。注意移除 SVG 里的冗余信息比如元数据、注释、无用的编辑器生成代码能进一步缩小体积。第四PNG 只在必须透明且复杂场景下使用。单纯为了透明背景优先考虑 WebP 的透明通道支持。除了格式还有一个更底层的策略响应式图片。用 srcset 属性为不同屏幕宽度提供不同尺寸的图片让手机用户只下载手机需要的图片而不是一张给 4K 屏幕准备的 4MB 大图。这属于“传得少”的经典实现。2.3 接口响应裁剪从源头减少动态数据静态资源压缩之外容易被架构师忽略的是动态接口的返回体。一个接口返回 1MB 的 JSON就算 gzip 压缩后降到 120KB——别忘了压缩是在传输层发生的服务端生成 JSON、序列化、传输、前端解析每一步都有成本。而且在弱网环境下压缩之后 120KB 依然要穿过带宽瓶颈。接口裁剪可以从几个层面做字段按需返回。最常见的方法是后端约定一个 fields 参数前端声明需要哪些字段后端只返回这些。实现不复杂但收益很可观。我给一个业务系统做过类似改造详情接口的响应从 96KB 降到 31KB压缩后更低前端渲染也快了。列表接口分页。很多团队有“一次查全量”的习惯尤其后台管理系统。正确的做法是服务端分页配合“滚动加载”或“点击加载更多”做交互。别把“前端我做了虚拟滚动”当成万能药虚拟滚动只是缓解了 DOM 渲染压力数据还是全都传过来了。真正的“不必要传输”削减必须从接口层就控制返回量。避免重复返回嵌套大字段。比如 DTO 里含有一个对象属性里头带着 base64 编码的图片内容这种数据结构在设计时就应该拆掉。接口设计阶段就该定一条规矩凡是能通过静态资源 URL 引用的内容一律不允许放进接口响应体。这一节的核心认知是压缩解决的是“体积”问题但接口响应裁剪解决的是“传输源头”的问题——与其压缩后传输不如先问一句“这一条到底该不该传”。3. 缓存复用让重复传输根本不会发生3.1 HTTP缓存策略的架构级设计如果说压缩是“把要传的东西变小”那么缓存就是“让要传的东西不再传”。HTTP 缓存是这里面最基础、收益最高、也最容易出错的一层。一个成体系的 HTTP 缓存策略核心是区分两类资源一类是动态HTML页面比如 index.html。这类资源需要实时性必须保证用户在刷新后能拿到最新版本所以缓存策略要么 Cache-Control: no-cache要么强缓存但配合 ETag/Last-Modified 做协商缓存校验。这里的关键词是“no-cache 不等于不缓存”它表示“缓存前必须回到服务器做验证”验证通过了可以继续用本地副本验证失败就返回新内容。这套机制既能省流量又能保证不脏。另一类是带指纹的静态资源也就是文件名里带哈希值的 JS、CSS、图片。这类资源的内容变了文件名就变所以可以放心大胆地做强缓存Cache-Control: public, max-age31536000, immutableimmutable 是很多团队容易忽略的字段它告诉浏览器“这个资源在过期之前不会变”可以完全跳过协商缓存。这样用户在二次访问时连发请求验证都不需要直接从本地缓存读取传输量直接变成 0。这个 header 对带指纹的静态资源是绝对安全的。相反如果静态资源不设缓存或者设成 no-cache那么用户每次访问都要重新下载所有 JS/CSS页面总字节数再小也扛不住每次完整传输。这属于“架构级失误”不是性能问题是配置问题。3.2 指纹机制与缓存穿透的坑我踩过一个大坑值得单独说一下。早期团队在 Nginx 层统一给所有资源都设置了 max-age86400一天包括 index.html。结果发布新版本后用户浏览器因为还在缓存期内继续用旧 HTML而旧 HTML 引用的还是旧版本的 JS/CSS 文件。等到缓存过期再回源校验时才有可能拿到新版本。于是每次上线后总有一批用户要过上一天才能看到新功能这期间报错率还特别高。问题的根因不是缓存不够激进而是把“入口HTML”和“带指纹静态资源”混为一谈。修正方案index.html 走 no-cache 协商缓存带指纹静态资源走 immutable 强缓存。这样发布新版本时HTML 立即更新HTML 引用的新文件名又让浏览器自动去下载新资源既不会漏也不会错。另外一个相关问题是“缓存黑洞”。有些团队喜欢在 localStorage 里存接口数据或页面数据为了省网络请求。但存储的数据没有版本号、没有过期时间也没有清理机制时间一长就会出现“数据是旧的不说用户想刷新都刷不掉”的尴尬局面。我的经验是localStorage 适合存低频变化且需要跨会话保留的数据比如用户偏好、草稿、令牌不适合做接口数据缓存。真要缓存数据交互优先考虑 service worker并且一定要设计版本更新机制和主动废弃策略。3.3 服务端缓存与 CDN 的回源开销前端“减少传输”不仅仅关乎浏览器到服务器的这一段也包括服务器到源站、源站到后端服务的链路。CDN 的价值在于把资源缓存在离用户最近的边缘节点让大部分请求在边缘就被命中根本到不了源站。但 CDN 缓存也有自己的坑。如果 CDN 回源策略没配好比如源站返回的 Cache-Control 配了 no-storeCDN 就没法缓存所有请求直接穿透到源站CDN 变成了一个“纯代理”白白增加了一段网络跳转。架构师在配置 CDN 时一定要去源站资源看响应头确认 CDN 的缓存命中率。我见过一个项目CDN 命中率只有不足 10%一查全是源站的响应头没配对修正之后命中率直接到了 90% 以上系统吞吐和延迟数据全面改善。后端接口层也可以考虑反向代理缓存对结果短时间内不会变化的 GET 接口比如配置类、字典类数据做几秒到几分钟的缓存。这一层能防止“同一份数据被一百个用户重复拉一百遍”的浪费。记住一个原则缓存的本质是“用空间换时间用规则降低重复传输”架构师设计缓存方案时要在新鲜度和复用率之间找到业务可接受的平衡点。4. 资源数量与依赖体积的架构级精简4.1 合并资源的策略随传输模型而变早年做前端优化有一条铁律是“尽可能减少HTTP请求数”典型做法是把所有 JS 合并成一个文件、所有 CSS 合并成一个文件。这个策略的核心逻辑是HTTP/1.1 时代浏览器对同一域名有并发连接数限制通常是6个超出部分的请求只能排队所以请求数量直接决定加载时间。但在 HTTP/2 普及之后这个逻辑被根本性动摇了。HTTP/2 的多路复用允许大量请求在同一个连接上并发进行连接数不再是瓶颈排队时间大幅下降。此时“把所有代码打成一个文件”反而成了负优化每次改动一行代码整个大文件缓存失效用户就得重新下载几百KB。正确的做法是拆细粒度让缓存按模块生效——改A模块B、C模块的文件还是可以从缓存里直接取用。这里要意识到一个架构层面的判断标准传输模型变了优化策略必须跟着变。“请求数越少越好”在 HTTP/1.1 时代是正确的在 HTTP/2 时代则要换成“并行请求多没问题重点是单文件体积别过大、缓存粒度别过粗”。很多从老项目升级上来的团队只顾着开启 HTTP/2却依然沿用合包策略等于两头都吃亏。4.2 拆包、按需加载与首屏传输量控制“减少不必要的传输”还有一个更细的切入点不是每个用户都需要全部代码。一个后台管理系统可能有几十个页面模块如果首次访问时把全部代码都下载一遍那么用户只是登录看一眼首页就白白传了十几兆字节这显然很不合理。现代前端工程化的解法是代码分割与按需加载路由级拆包按照路由把页面拆成独立 chunk用户进入哪个页面才加载哪个页面的代码。这是最常用、收益最明显的方案。第三方库独立分包固定不变的三方依赖react、vue、antd 等单独打成 vendor 文件利用强缓存长年不失效。业务代码频繁迭代但它们不需要被重新下载。动态 importconst Module await import(./module.js)实现真正意义上的“用到时才加载”。我在一个实际业务系统里做过一次拆包改造首屏 JS 总量从 1.2MB 降到 380KB首屏加载时间从 4.8 秒降到 2.1 秒。没有改任何业务代码纯粹是打包策略的调整。拆包的时候要留意一个细节chunk 粒度太细会导致大量碎片文件增加请求数量和管理成本。我通常把“页面级 chunk 2-3 个公共 vendor chunk”作为默认方案不需要追求极致按业务模块聚合即可。4.3 依赖体积审计与按需引入“让代码包变小”和“减少不必要的传输”之间有一个隐藏环节分析依赖体积。很多团队用了一个 200KB 的工具库实际用的方法只有 3 个。比如 moment.js 体积超大如果只是格式化日期用原生 Intl.DateTimeFormat 或轻量库 day.js 替代能省掉大量体积lodash 的全量引入可以改成import debounce from lodash/debounce的按需路径引用再配合 webpack 的 sideEffects: false 做 tree-shaking效果显著。我的习惯是每次大版本迭代前花半天时间跑一次webpack-bundle-analyzer把所有依赖的体积分布看一遍。有几次排查出一些遗留的旧依赖比如扫描项目里已经没有使用的 UI 组件库删掉之后 main bundle 直接瘦身了 15%。这种事情不做体积审计根本发现不了。记住代码体积的治理不是一次性的任务要像巡检一样定期做哪怕每次只减掉 5%长期积累下来就能形成很大的传输优势。5. 软考视角这一节的考点与答题思路5.1 考点映射系统架构设计师考试会怎么出题前面聊的都是实际操作但很多读者也是在备考系统架构设计师软考高级或者用软考大纲来做知识体系梳理。如果你把这个标题下的内容放进软考的框架里看会发现“减少不必要的传输”几乎布在了多个核心知识域里。从历年真题的分布来看涉及的方向主要有性能优化设计。考试会给出一个“网站响应缓慢/高并发下页面加载超时”的场景让你提出优化方案。此时减少HTTP请求数、启用数据压缩、配置缓存、CDN加速、图片处理优化这些就是标准答题点。嵌入式的性能设计少见但存在。系统架构师考试的应用场景不局限于互联网但性能方法论是通用的。比如嵌入式环境对资源更敏感“减少不必要传输”对低带宽场景的意义更突出。系统建模与架构设计。案例题里可能会出现描述现有架构缺陷的题型比如“单体应用中静态资源与动态请求未分离”“未配置CDN”等让你指出问题并给出改进方案。这些问题的答案本质上都指向“合理分层、就近访问、减少回源”。5.2 案例题落地从问题描述到方案输出软考案例题最考验的是“结构化答题能力”。我从阅卷角度的经验来聊一下怎么答这类题。如果一个题目描述“某企业网站由于页面体积过大、加载缓慢随着访问量增长服务器带宽成本显著上升请你提出优化方案。”那么你的答案要分条来写而且每条都要“方案理由预期效果”三件套启用 HTTP 压缩。理由文本类资源压缩率可达 70% 以上有效降低传输字节数。预期效果页面体积减少、响应时间缩短、带宽成本下降。静态资源缓存治理。理由通过 Cache-Control 和 ETag 设置使静态资源可被浏览器和CDN缓存减少重复传输。预期效果回源率下降重复访问加载时间大幅降低。页面静态化与 CDN 加速。对不频繁变化的内容生成静态化页面配合 CDN 边缘分发让用户就近获取资源减少跨国、跨地域传输延迟。接口按需返回字段。理由削减无用字段传输降低解析开销。预期效果接口响应体积下降 30%-50%首屏渲染时间缩短。这道题如果让你展开“动态接口的优化”前面第三节、第四节的内容就是最好的素材。关键是不要只写“做缓存”三个字而要把缓存的对象、策略、收益讲清楚阅卷人看的是表达的专业度。5.3 从软考到实践架构师该沉淀的优化方法论软考的价值不在于背题而在于逼你把知识结构化。当你在考场上能对于“减少不必要的传输”这个问题自然地拆解出压缩、缓存、裁剪、拆分四个方向时你在实际项目里就具备了系统排查的思路。我接触过很多刚入门的技术同学他们拿到一个“页面慢”的问题第一反应是“用什么工具”而不是“先看什么数据”。工具只是手段数据才是起点。所以我的建议是把这篇文章提到的“总字节数、请求总数、不可复用率”三个指标拿到你自己维护的系统里去测一遍然后按照压缩、缓存、裁剪、拆分四个方向列出候选优化项。你会发现真正要动手的地方往往比你想象的清晰得多。这也是架构师和一线开发在“优化”这个问题上最大的区别——前者靠数据和策略后者靠直觉和碰运气。考虑到这套内容属于前端优化思路里的一个章节我最后再给一个实操层面的收尾优化不是一次性的行为建议每次版本迭代时都跑一下 Lighthouse 或者 WebPageTest把关键指标的变化记录下来形成团队自己的性能预算。像控制预算一样去控制传输量才能避免一段时间后又偷偷劣化回去。这是我在多次项目反复之后觉得最值得养成的一个习惯。 减少不必要的传输：前端性能优化的核心策略与实践
我刚接手一个老系统的性能优化时遇到过一桩挺典型的案例首页加载耗时接近8秒团队一连几周都在死磕数据库索引、并发参数、服务器配置指标一动没动。后来用浏览器开发者工具拉了一遍瀑布图真相其实特别朴素——页面里有一张未经压缩的素材图片体积4.5MB一个详情接口一次性返回了220多个字段而前端真正渲染用到的不到60个。那段时间我反复想一个问题我们总是习惯把“优化”理解成“让系统跑得更快”但在前端这个场景里很多时候最值钱的优化恰恰是“让系统少传一点”。“减少不必要的传输”看起来像是常识架构师真正把它当成一个独立的优化方向去设计和度量时才发现里面有大量策略取舍、技术选型和数据验证的工作。这篇文章面向的是系统架构师、在想做前端性能治理的后端工程师也包括正在备考系统架构设计师软考的朋友。它对应的内容是“前端优化思路”里的一个关键小节核心要解决三件事传输量到底该怎么衡量、哪些手段能真正削减传输、削减之后如何验证收益。我会把实际项目里的做法、踩过的坑、以及软考案例题里的常见答题角度一并串起来讲尽量让这份内容既能落地也能成为你知识体系里的一环。1. 传输量问题的度量与分析先搞清楚数据从哪来的1.1 用三个核心指标建立衡量口径做架构优化第一件事不是动手改代码而是建立可量化的口径。在“减少不必要的传输”这个方向上我习惯只看三个指标。第一个是页面总字节数。打开浏览器开发者工具的 Network 面板把页面首次加载产生的所有资源体积相加就是总字节数。这个数字直接决定了用户在弱网环境下的等待时长也是后续优化前后对比的基准值。第二个是请求总数。一个页面发起的HTTP请求数量影响了浏览器并发连接的限制、服务端的连接开销以及整条链路里每个环节的耗时累加。尤其对于 HTTP/1.1 时代的存量系统请求数量往往比体积更能卡住性能。第三个是不可复用率。这个指标很多人会忽略它指的是“本次加载中有多少字节是不能被缓存复用的”。比如接口返回的动态数据、未设置 Cache-Control 的静态资源、每次刷新都会重新下载的图片它们都属于不可复用的传输。我把这三个指标整理成一个简单的表方便在团队里统一语言指标含义典型优化目标总字节数页面首次加载下载的所有资源大小削减30%以上请求总数页面产生的HTTP请求数量合并或裁剪至合理水平不可复用率无法被缓存的传输所占比例尽量控制在合理区间为什么强调这三个指标因为它们把“减少不必要的传输”从一句口号变成了可执行的优化清单。总字节数高优先做压缩和图片优化请求总数多优先做合并和拆包策略不可复用率高优先做缓存治理和接口裁剪。1.2 从瀑布图到服务端日志完整的数据收集链路光有指标还不够你得知道数据从哪一层来。我的习惯是分三层看。第一层是浏览器端。打开 DevTools 的 Network 面板重点看每个请求的 Timings 区间Stalled、Waiting (TTFB)、Content Download。其中 Content Download 是纯网络传输耗时如果某个资源这块特别长说明它的体积需要瘦身TTFB 长则是服务端响应慢属于另一类问题。第二层是代理层。如果系统用了 Nginx 或者 CDN通过访问日志可以统计每个资源的流量占比。比如 Nginx 的 $body_bytes_sent 字段配合 $request_uri 就能统计出哪些URL占据了大部分带宽。我见过不少系统仅从这个维度就能轻易发现某张背景图占了全站流量的 40%——这显然就是“不必要的传输”的头号目标。第三层是服务端。通过应用日志和数据库慢查询日志能定位接口返回了大字段但前端用不上这种“隐性浪费”。例如一个商品列表接口每条记录都带着完整的富文本详情但列表页真的只需要缩略图和价格。这层浪费不像图片体积那么显眼但在接口层面的优化空间往往比静态资源还要大。值得注意的一个坑是开发环境的数据不具备参考价值。开发环境通常走本机代理、资源未压缩、接口未开缓存测出来的结论和线上完全两个样。做传输量度量务必基于线上环境或者生产镜像环境最好配合多网速模拟比如 WebPageTest 的 3G/4G 档位才能得到真实可用的数据。2. 压缩与格式选择让必须传输的内容变小2.1 文本压缩的工程配置gzip 与 brotli 的取舍文本类资源HTML、CSS、JavaScript、JSON、SVG是“减少传输体积”最直接的战场方案也最成熟压缩。几乎所有现代浏览器都支持 gzipNginx 默认也带相关模块所以很多团队“开了 gzip 就完事”。但如果你只做到这一步等于放弃了至少 15% 到 25% 的额外收益。gzip 的配置很简单核心参数就几个压缩级别、最小压缩阈值、压缩类型。这里给一份我在生产环境用的 Nginx 配置供参考gzip on; gzip_comp_level 5; gzip_min_length 1024; gzip_types text/plain text/css application/javascript application/json image/svgxml;几点经验说明。压缩级别gzip_comp_level不是越高越好。级别 1 到 9级别越高压缩率越好但 CPU 开销也越高而且超过 6 之后压缩率提升很有限。我在业务系统里直接用 5动态接口和高频接口不建议超过 6否则在高峰期会明显增加 CPU 负载。gzip_min_length 1k意思是小于 1KB 的资源不压缩。因为压缩本身有开销对小文件来说压缩后的体积可能反而更大gzip 有固定头部所以这个阈值是为了避免负优化。gzip_types 要写全。很多团队漏掉 image/svgxml导致 SVG 白白浪费了可压缩空间——SVG 本质是文本压一遍能小 70% 以上。再说 brotli。Br 是谷歌推出的压缩算法压缩率比 gzip 平均再高 15% 到 20%但有两个门槛一是需要 Nginx 编译了 ngx_brotli 模块二是浏览器需要支持 Accept-Encoding: br。主流浏览器基本都是支持的但如果你面向的是政企、老系统、老旧浏览器用户群就得谨慎。我的建议是CDN 层面如果支持 brotli直接用自建 Nginx 的话可以先保留 gzip 不做切换留到后面版本迭代时再评估避免为了一点压缩率引入兼容性风险。2.2 图片体积治理格式选择优先级与降级策略图片是前端传输体积的大头尤其对于营销页、电商系统。我记得一次性能分析里一个页面的总字节数是 2.1MB其中图片占了 1.8MB——这个结构非常典型。图片优化的核心逻辑是在满足视觉质量的前提下选择体积最小的格式。我的选择优先级是这样的首先能转 WebP 就转 WebP。WebP 在同等画质下比 JPEG 小 25% 到 35%比 PNG 小 50% 以上。现在浏览器对 WebP 支持率非常高用 CDN 的图片处理功能缩略、转格式、质量调整可以很轻松地在不改代码的情况下完成转换。其次AVIF。它是比 WebP 更激进的格式压缩率还能再提升 20% 到 30%但编码耗时和浏览器兼容性需要权衡。我的建议可以先小范围灰度不适合做全站默认。第三SVG 用于图标和简单图形。相比 PNG 格式的图标SVG 体积小、可缩放、可用 CSS 控制颜色很多场景应该优先使用。注意移除 SVG 里的冗余信息比如元数据、注释、无用的编辑器生成代码能进一步缩小体积。第四PNG 只在必须透明且复杂场景下使用。单纯为了透明背景优先考虑 WebP 的透明通道支持。除了格式还有一个更底层的策略响应式图片。用 srcset 属性为不同屏幕宽度提供不同尺寸的图片让手机用户只下载手机需要的图片而不是一张给 4K 屏幕准备的 4MB 大图。这属于“传得少”的经典实现。2.3 接口响应裁剪从源头减少动态数据静态资源压缩之外容易被架构师忽略的是动态接口的返回体。一个接口返回 1MB 的 JSON就算 gzip 压缩后降到 120KB——别忘了压缩是在传输层发生的服务端生成 JSON、序列化、传输、前端解析每一步都有成本。而且在弱网环境下压缩之后 120KB 依然要穿过带宽瓶颈。接口裁剪可以从几个层面做字段按需返回。最常见的方法是后端约定一个 fields 参数前端声明需要哪些字段后端只返回这些。实现不复杂但收益很可观。我给一个业务系统做过类似改造详情接口的响应从 96KB 降到 31KB压缩后更低前端渲染也快了。列表接口分页。很多团队有“一次查全量”的习惯尤其后台管理系统。正确的做法是服务端分页配合“滚动加载”或“点击加载更多”做交互。别把“前端我做了虚拟滚动”当成万能药虚拟滚动只是缓解了 DOM 渲染压力数据还是全都传过来了。真正的“不必要传输”削减必须从接口层就控制返回量。避免重复返回嵌套大字段。比如 DTO 里含有一个对象属性里头带着 base64 编码的图片内容这种数据结构在设计时就应该拆掉。接口设计阶段就该定一条规矩凡是能通过静态资源 URL 引用的内容一律不允许放进接口响应体。这一节的核心认知是压缩解决的是“体积”问题但接口响应裁剪解决的是“传输源头”的问题——与其压缩后传输不如先问一句“这一条到底该不该传”。3. 缓存复用让重复传输根本不会发生3.1 HTTP缓存策略的架构级设计如果说压缩是“把要传的东西变小”那么缓存就是“让要传的东西不再传”。HTTP 缓存是这里面最基础、收益最高、也最容易出错的一层。一个成体系的 HTTP 缓存策略核心是区分两类资源一类是动态HTML页面比如 index.html。这类资源需要实时性必须保证用户在刷新后能拿到最新版本所以缓存策略要么 Cache-Control: no-cache要么强缓存但配合 ETag/Last-Modified 做协商缓存校验。这里的关键词是“no-cache 不等于不缓存”它表示“缓存前必须回到服务器做验证”验证通过了可以继续用本地副本验证失败就返回新内容。这套机制既能省流量又能保证不脏。另一类是带指纹的静态资源也就是文件名里带哈希值的 JS、CSS、图片。这类资源的内容变了文件名就变所以可以放心大胆地做强缓存Cache-Control: public, max-age31536000, immutableimmutable 是很多团队容易忽略的字段它告诉浏览器“这个资源在过期之前不会变”可以完全跳过协商缓存。这样用户在二次访问时连发请求验证都不需要直接从本地缓存读取传输量直接变成 0。这个 header 对带指纹的静态资源是绝对安全的。相反如果静态资源不设缓存或者设成 no-cache那么用户每次访问都要重新下载所有 JS/CSS页面总字节数再小也扛不住每次完整传输。这属于“架构级失误”不是性能问题是配置问题。3.2 指纹机制与缓存穿透的坑我踩过一个大坑值得单独说一下。早期团队在 Nginx 层统一给所有资源都设置了 max-age86400一天包括 index.html。结果发布新版本后用户浏览器因为还在缓存期内继续用旧 HTML而旧 HTML 引用的还是旧版本的 JS/CSS 文件。等到缓存过期再回源校验时才有可能拿到新版本。于是每次上线后总有一批用户要过上一天才能看到新功能这期间报错率还特别高。问题的根因不是缓存不够激进而是把“入口HTML”和“带指纹静态资源”混为一谈。修正方案index.html 走 no-cache 协商缓存带指纹静态资源走 immutable 强缓存。这样发布新版本时HTML 立即更新HTML 引用的新文件名又让浏览器自动去下载新资源既不会漏也不会错。另外一个相关问题是“缓存黑洞”。有些团队喜欢在 localStorage 里存接口数据或页面数据为了省网络请求。但存储的数据没有版本号、没有过期时间也没有清理机制时间一长就会出现“数据是旧的不说用户想刷新都刷不掉”的尴尬局面。我的经验是localStorage 适合存低频变化且需要跨会话保留的数据比如用户偏好、草稿、令牌不适合做接口数据缓存。真要缓存数据交互优先考虑 service worker并且一定要设计版本更新机制和主动废弃策略。3.3 服务端缓存与 CDN 的回源开销前端“减少传输”不仅仅关乎浏览器到服务器的这一段也包括服务器到源站、源站到后端服务的链路。CDN 的价值在于把资源缓存在离用户最近的边缘节点让大部分请求在边缘就被命中根本到不了源站。但 CDN 缓存也有自己的坑。如果 CDN 回源策略没配好比如源站返回的 Cache-Control 配了 no-storeCDN 就没法缓存所有请求直接穿透到源站CDN 变成了一个“纯代理”白白增加了一段网络跳转。架构师在配置 CDN 时一定要去源站资源看响应头确认 CDN 的缓存命中率。我见过一个项目CDN 命中率只有不足 10%一查全是源站的响应头没配对修正之后命中率直接到了 90% 以上系统吞吐和延迟数据全面改善。后端接口层也可以考虑反向代理缓存对结果短时间内不会变化的 GET 接口比如配置类、字典类数据做几秒到几分钟的缓存。这一层能防止“同一份数据被一百个用户重复拉一百遍”的浪费。记住一个原则缓存的本质是“用空间换时间用规则降低重复传输”架构师设计缓存方案时要在新鲜度和复用率之间找到业务可接受的平衡点。4. 资源数量与依赖体积的架构级精简4.1 合并资源的策略随传输模型而变早年做前端优化有一条铁律是“尽可能减少HTTP请求数”典型做法是把所有 JS 合并成一个文件、所有 CSS 合并成一个文件。这个策略的核心逻辑是HTTP/1.1 时代浏览器对同一域名有并发连接数限制通常是6个超出部分的请求只能排队所以请求数量直接决定加载时间。但在 HTTP/2 普及之后这个逻辑被根本性动摇了。HTTP/2 的多路复用允许大量请求在同一个连接上并发进行连接数不再是瓶颈排队时间大幅下降。此时“把所有代码打成一个文件”反而成了负优化每次改动一行代码整个大文件缓存失效用户就得重新下载几百KB。正确的做法是拆细粒度让缓存按模块生效——改A模块B、C模块的文件还是可以从缓存里直接取用。这里要意识到一个架构层面的判断标准传输模型变了优化策略必须跟着变。“请求数越少越好”在 HTTP/1.1 时代是正确的在 HTTP/2 时代则要换成“并行请求多没问题重点是单文件体积别过大、缓存粒度别过粗”。很多从老项目升级上来的团队只顾着开启 HTTP/2却依然沿用合包策略等于两头都吃亏。4.2 拆包、按需加载与首屏传输量控制“减少不必要的传输”还有一个更细的切入点不是每个用户都需要全部代码。一个后台管理系统可能有几十个页面模块如果首次访问时把全部代码都下载一遍那么用户只是登录看一眼首页就白白传了十几兆字节这显然很不合理。现代前端工程化的解法是代码分割与按需加载路由级拆包按照路由把页面拆成独立 chunk用户进入哪个页面才加载哪个页面的代码。这是最常用、收益最明显的方案。第三方库独立分包固定不变的三方依赖react、vue、antd 等单独打成 vendor 文件利用强缓存长年不失效。业务代码频繁迭代但它们不需要被重新下载。动态 importconst Module await import(./module.js)实现真正意义上的“用到时才加载”。我在一个实际业务系统里做过一次拆包改造首屏 JS 总量从 1.2MB 降到 380KB首屏加载时间从 4.8 秒降到 2.1 秒。没有改任何业务代码纯粹是打包策略的调整。拆包的时候要留意一个细节chunk 粒度太细会导致大量碎片文件增加请求数量和管理成本。我通常把“页面级 chunk 2-3 个公共 vendor chunk”作为默认方案不需要追求极致按业务模块聚合即可。4.3 依赖体积审计与按需引入“让代码包变小”和“减少不必要的传输”之间有一个隐藏环节分析依赖体积。很多团队用了一个 200KB 的工具库实际用的方法只有 3 个。比如 moment.js 体积超大如果只是格式化日期用原生 Intl.DateTimeFormat 或轻量库 day.js 替代能省掉大量体积lodash 的全量引入可以改成import debounce from lodash/debounce的按需路径引用再配合 webpack 的 sideEffects: false 做 tree-shaking效果显著。我的习惯是每次大版本迭代前花半天时间跑一次webpack-bundle-analyzer把所有依赖的体积分布看一遍。有几次排查出一些遗留的旧依赖比如扫描项目里已经没有使用的 UI 组件库删掉之后 main bundle 直接瘦身了 15%。这种事情不做体积审计根本发现不了。记住代码体积的治理不是一次性的任务要像巡检一样定期做哪怕每次只减掉 5%长期积累下来就能形成很大的传输优势。5. 软考视角这一节的考点与答题思路5.1 考点映射系统架构设计师考试会怎么出题前面聊的都是实际操作但很多读者也是在备考系统架构设计师软考高级或者用软考大纲来做知识体系梳理。如果你把这个标题下的内容放进软考的框架里看会发现“减少不必要的传输”几乎布在了多个核心知识域里。从历年真题的分布来看涉及的方向主要有性能优化设计。考试会给出一个“网站响应缓慢/高并发下页面加载超时”的场景让你提出优化方案。此时减少HTTP请求数、启用数据压缩、配置缓存、CDN加速、图片处理优化这些就是标准答题点。嵌入式的性能设计少见但存在。系统架构师考试的应用场景不局限于互联网但性能方法论是通用的。比如嵌入式环境对资源更敏感“减少不必要传输”对低带宽场景的意义更突出。系统建模与架构设计。案例题里可能会出现描述现有架构缺陷的题型比如“单体应用中静态资源与动态请求未分离”“未配置CDN”等让你指出问题并给出改进方案。这些问题的答案本质上都指向“合理分层、就近访问、减少回源”。5.2 案例题落地从问题描述到方案输出软考案例题最考验的是“结构化答题能力”。我从阅卷角度的经验来聊一下怎么答这类题。如果一个题目描述“某企业网站由于页面体积过大、加载缓慢随着访问量增长服务器带宽成本显著上升请你提出优化方案。”那么你的答案要分条来写而且每条都要“方案理由预期效果”三件套启用 HTTP 压缩。理由文本类资源压缩率可达 70% 以上有效降低传输字节数。预期效果页面体积减少、响应时间缩短、带宽成本下降。静态资源缓存治理。理由通过 Cache-Control 和 ETag 设置使静态资源可被浏览器和CDN缓存减少重复传输。预期效果回源率下降重复访问加载时间大幅降低。页面静态化与 CDN 加速。对不频繁变化的内容生成静态化页面配合 CDN 边缘分发让用户就近获取资源减少跨国、跨地域传输延迟。接口按需返回字段。理由削减无用字段传输降低解析开销。预期效果接口响应体积下降 30%-50%首屏渲染时间缩短。这道题如果让你展开“动态接口的优化”前面第三节、第四节的内容就是最好的素材。关键是不要只写“做缓存”三个字而要把缓存的对象、策略、收益讲清楚阅卷人看的是表达的专业度。5.3 从软考到实践架构师该沉淀的优化方法论软考的价值不在于背题而在于逼你把知识结构化。当你在考场上能对于“减少不必要的传输”这个问题自然地拆解出压缩、缓存、裁剪、拆分四个方向时你在实际项目里就具备了系统排查的思路。我接触过很多刚入门的技术同学他们拿到一个“页面慢”的问题第一反应是“用什么工具”而不是“先看什么数据”。工具只是手段数据才是起点。所以我的建议是把这篇文章提到的“总字节数、请求总数、不可复用率”三个指标拿到你自己维护的系统里去测一遍然后按照压缩、缓存、裁剪、拆分四个方向列出候选优化项。你会发现真正要动手的地方往往比你想象的清晰得多。这也是架构师和一线开发在“优化”这个问题上最大的区别——前者靠数据和策略后者靠直觉和碰运气。考虑到这套内容属于前端优化思路里的一个章节我最后再给一个实操层面的收尾优化不是一次性的行为建议每次版本迭代时都跑一下 Lighthouse 或者 WebPageTest把关键指标的变化记录下来形成团队自己的性能预算。像控制预算一样去控制传输量才能避免一段时间后又偷偷劣化回去。这是我在多次项目反复之后觉得最值得养成的一个习惯。