真实面经题目 · 原创解析

怎么优化网络链接速度？

优化网络连接速度，本质是缩短从用户发起请求到可用响应返回的整条链路耗时。前端不能只盯着资源体积，还要拆开 DNS、TCP/TLS 握手、协议协商、服务器处理、传输拥塞、缓存命中、资源优先级和渲染阻塞等环节。回答应先给出度量口径，再按连接建立、协议升级、缓存复用、资源调度、传输压缩、CDN 边缘化和监控闭环展开。

出现于：阿里巴巴 · 前端
计算机网络
01

60 秒回答模板

我会先把网络连接速度拆成两类：一类是连接建立速度，包括 DNS 查询、TCP 三次握手、TLS 握手、HTTP 协议协商；另一类是请求传输速度，包括服务器响应、缓存命中、带宽、拥塞控制和资源优先级。优化时先用 Performance API、Navigation Timing、Resource Timing、LCP、TTFB 等指标定位瓶颈，再针对性处理：DNS 预解析、preconnect、连接复用、HTTP/2 或 HTTP/3、TLS 1.3、CDN、缓存策略、资源压缩、懒加载、请求合并或拆分、接口并发控制，以及服务端和网关层的响应优化。最后通过真实用户监控和灰度对比验证，而不是凭感觉优化。

考点 先定义指标和瓶颈
主线 减少连接建立成本
易错点 只说压缩图片和减少资源大小，没有拆分 DNS、TCP、…
02

深入解析

01

先定义指标和瓶颈

优化网络连接速度不能直接从加 CDN、压缩图片开始，而要先明确慢在哪里。一次请求通常包含 DNS 查询、TCP 建连、TLS 握手、请求发送、服务端处理、首字节返回、内容下载等阶段。前端可以通过 Navigation Timing、Resource Timing、PerformanceObserver、浏览器 DevTools 瀑布图和线上 RUM 数据拆分耗时。比如 DNS 慢和后端 TTFB 慢是完全不同的问题，前者可能靠预解析或本地缓存缓解，后者需要服务端、网关、数据库或缓存链路优化。

02

减少连接建立成本

网络连接的固定成本主要来自 DNS、TCP 和 TLS。前端可以对关键域名使用 dns-prefetch 降低 DNS 查询等待，对首屏关键接口或静态资源域名使用 preconnect 提前完成 DNS、TCP 和 TLS 建连。服务端侧应开启 TLS 1.3、会话复用和合理的证书链，减少握手往返次数。需要注意预连接不是越多越好，过度 preconnect 会占用浏览器连接池、CPU 和移动端电量，反而挤压真正关键资源。

03

利用协议能力提升复用

HTTP/1.1 下同域连接数量有限，队头阻塞和多连接竞争比较明显；HTTP/2 通过多路复用、头部压缩和单连接并发，可以减少重复建连并提升资源传输效率。HTTP/3 基于 QUIC，在弱网和移动网络切换场景下通常具备更好的连接迁移和丢包恢复能力。协议升级不是口号，必须结合 CDN、网关、浏览器兼容性、服务端配置和实际资源形态验证收益。

04

提高缓存命中率

最快的网络请求是不用发起的请求，其次是命中浏览器缓存、CDN 缓存或服务端缓存的请求。静态资源应使用内容哈希文件名配合 Cache-Control 长缓存，HTML 通常使用较短缓存或协商缓存，接口数据则根据业务实时性设计本地缓存、HTTP 缓存、Service Worker 缓存或状态层缓存。缓存策略要避免两个极端：完全不缓存会浪费链路，盲目长缓存又可能造成版本更新不及时和用户看到旧数据。

05

压缩和裁剪传输内容

传输速度不仅取决于链路，还取决于传了多少内容。前端应减少首屏资源体积，使用代码分割、Tree Shaking、按路由加载、图片响应式尺寸、WebP 或 AVIF、字体子集化和 Brotli 或 gzip 压缩。接口层应避免返回冗余字段，支持分页、增量更新和按需查询。关键不是机械地压缩一切，而是优先处理首屏关键路径上的大资源和高频接口。

06

优化资源优先级

浏览器不是把所有请求同等对待，关键 CSS、主脚本、字体、首屏图片、接口请求之间存在优先级竞争。前端可以用 preload 提前声明关键资源，用 defer 或 async 避免脚本阻塞解析，用懒加载推迟非首屏图片和低优先级模块。对于接口请求，要避免页面初始化时一次性打爆并发，必要时按视口、路由和用户操作分层触发，让关键请求先完成，非关键请求延后。

07

靠近用户和稳定链路

如果用户距离源站很远，单纯前端优化空间有限，需要通过 CDN、边缘节点、就近接入、智能 DNS 和多地域部署缩短物理距离。静态资源适合放到 CDN，动态接口可以考虑边缘缓存、网关聚合或区域化服务。移动网络和跨境访问还要关注丢包、抖动、运营商线路和回源质量。链路优化的核心是让请求少绕路、少跨区域、少回源，并在异常线路下具备降级能力。

03

易错点

  • 只说压缩图片和减少资源大小，没有拆分 DNS、TCP、TLS、TTFB 等阶段。
  • 把网络优化全部归给前端，忽略服务端处理、网关回源和数据库查询造成的 TTFB。
  • 滥用 preconnect、preload 等提示资源，导致连接池和带宽被非关键资源抢占。
  • 认为 HTTP/2 或 HTTP/3 一定更快，没有说明依赖服务端、CDN 和真实场景验证。
  • 缓存策略只说强缓存，没有解释文件哈希、协商缓存、失效机制和数据新鲜度。
  • 接口优化只会说合并请求，没有分析缓存粒度、首屏依赖和无用字段膨胀问题。
04

面试官追问

DNS 预解析和 preconnect 有什么区别？

dns-prefetch 主要提前完成域名解析，减少真正请求时等待 DNS 的时间；preconnect 更进一步，会尝试提前建立 DNS、TCP 和 TLS 连接。前者成本低，适合较多可能访问的外部域名；后者成本更高，只适合首屏确定会用到的关键域名。预连接过多会浪费连接池和设备资源，所以要通过瀑布图验证。

HTTP/2 一定比 HTTP/1.1 快吗？

不一定。HTTP/2 的优势是多路复用、头部压缩和减少重复建连，对大量小资源通常更友好。但如果服务器配置不佳、CDN 支持不完整、资源本身过大，或者单连接丢包导致多个流受影响，收益可能不明显。实际项目要结合资源数量、网络环境、服务端实现和监控数据判断，而不是简单认为协议越新越快。

为什么 CDN 可以提升网络速度？

CDN 的核心价值是把静态资源或可缓存内容放到离用户更近的边缘节点，减少跨地域传输和源站回源压力。它还能利用运营商线路优化、缓存命中、压缩和协议升级提升整体访问稳定性。但 CDN 不是万能的，如果缓存命中率低、回源慢、节点调度错误或动态接口不可缓存，用户仍然可能感知很慢。

前端如何判断是网络慢还是后端慢？

可以通过浏览器 DevTools 或 Performance API 拆解请求耗时。如果 DNS、Initial connection、SSL 时间长，说明连接建立阶段有问题；如果 Waiting for server response 或 TTFB 很高，通常是服务端处理、网关、回源或数据库慢；如果 Content Download 时间长，则可能是资源太大、带宽不足或链路质量差。判断清楚阶段后再决定优化手段。

接口请求太多时应该合并还是拆分？

不能绝对说合并或拆分更好。首屏强依赖的多个小接口，如果每个都有独立鉴权、网关转发和服务端处理成本，可以考虑 BFF 聚合减少请求瀑布；但把所有接口粗暴合成一个大接口会增加无用字段、降低缓存粒度并拖慢关键数据返回。合理做法是按页面关键路径、缓存粒度和业务变更频率设计接口边界。