答案：HTTP/1.x通过域名分片和资源合并增加并发，而HTTP/2利用多路复用减少连接数，提升传输效率。
JS网络请求性能优化，核心在于系统性地减少延迟和提高吞吐量。这通常意味着要充分利用浏览器并发机制，拥抱HTTP/2协议带来的革命性特性，并结合资源预加载、请求合并、智能缓存、数据压缩等一系列手段，从根本上提升前端应用的响应速度和用户体验。
解决方案
在我看来，优化JavaScript网络请求是一个多维度的工程，它不仅仅是写几行代码那么简单，更涉及到对网络协议、浏览器行为以及用户场景的深刻理解。
我们先从最直观的“并行请求”说起。在HTTP/1.x时代，浏览器对同一域名下的并发请求数量是有限制的，通常是6-8个。这意味着如果你有几十个小文件要下载，它们会排队，造成“队头阻塞”。为了绕开这个限制，我们曾经会做“域名分片”（Domain Sharding），也就是把资源分散到不同的子域名下，比如
static1.example.com
、
static2.example.com
，这样浏览器就能同时建立更多连接来下载资源。这种做法在当时确实有效，但也有额外的DNS解析开销。
不过，随着HTTP/2的普及，这种思维模式就得彻底改变了。HTTP/2引入了多路复用（Multiplexing），允许在一个TCP连接上同时发送多个请求和响应，彻底解决了队头阻塞的问题。这意味着，你不再需要通过域名分片来增加并发，甚至过度分片反而可能因为TLS握手和连接管理开销而适得其反。现在，我们更应该专注于减少连接数，让所有请求都通过一个连接高效传输。
当然，并行请求在逻辑层面依然重要。比如，当你的页面需要同时从多个API接口获取数据时，
Promise.all
或
Promise.allSettled
就是你的好帮手。它们能让你并行发起多个请求，并在所有请求都完成（或部分完成）后统一处理结果，这比串行请求效率高得多。我个人觉得，合理地使用这些API，能让数据加载时间大幅缩短，用户感知到的等待时间也自然就少了。
除了并行，预加载（Preload）、预连接（Preconnect）和预获取（Prefetch）也是非常实用的策略。
能告诉浏览器这个脚本很快就会用到，赶紧下载。
则能提前与后端API服务器建立连接，省去了DNS解析和TLS握手的时间。而
则可以预先加载用户可能访问的下一个页面资源。这些看似简单的
link
标签，却能在关键时刻为用户节省宝贵的等待时间。我通常会在关键路径资源上使用preload，对可能但非必然的资源使用prefetch。
再者，缓存策略是网络优化的基石。合理设置
Cache-Control
、
ETag
等HTTP缓存头，可以大大减少重复请求。Service Worker更是能提供强大的离线缓存能力，让你的应用在网络不佳甚至无网络环境下依然可用，并且能实现“秒开”体验。我曾经用Service Worker为一些静态资源和API响应做了缓存，效果立竿见影，用户再次访问时几乎是瞬间加载。
数据压缩也是不可或缺的一环。Gzip和Brotli是目前最常用的压缩算法。确保你的服务器配置了这些压缩，能显著减少传输的数据量。同时，图片优化也别忘了，选择合适的图片格式（如WebP）、压缩图片大小、使用响应式图片，都能减少图片加载对网络请求的压力。
最后，CDN（内容分发网络）的应用也至关重要。将静态资源部署到CDN上，可以利用CDN在全球范围内的节点，让用户从距离他们最近的服务器获取资源，大大降低网络延迟。
HTTP/1.x与HTTP/2环境下，并行请求的优化策略有何不同？
这是一个非常关键的问题，因为它直接影响我们如何设计前端架构和部署策略。在我看来，理解这两种协议的差异，是现代前端工程师的必备技能。
在HTTP/1.x时代，我们面对的核心挑战是“队头阻塞”（Head-of-Line Blocking）。简单来说，就是浏览器在同一个TCP连接上，必须按照请求的顺序来发送和接收响应。如果前面的请求响应慢了，后面的请求即使已经准备好，也只能等着。为了缓解这个问题，浏览器通常会对每个域名限制并发连接数（比如Chrome是6个）。
基于这个限制，HTTP/1.x的并行请求优化策略主要有：
域名分片（Domain Sharding）：这是最直接的手段。通过将资源分散到多个子域名下，比如
img1.example.com
、
img2.example.com
，可以欺骗浏览器，让它认为这些是不同的域名，从而建立更多的TCP连接来并行下载资源。我过去在一些老项目中经常用这招，虽然能提升并发，但代价是增加了DNS解析时间，而且建立多个TCP连接本身也有开销。资源合并（Resource Concatenation）：将多个CSS文件或JS文件合并成一个大文件，减少请求数量。这样虽然减少了请求数，但如果其中一个文件有更新，整个大文件都需要重新下载，不利于缓存。CSS Sprites：将多个小图片合并成一张大图，通过CSS背景定位来显示，减少图片请求。
然而，当进入HTTP/2时代，情况就完全不同了。HTTP/2的核心特性是“多路复用”（Multiplexing）。它允许在一个TCP连接上同时发送多个请求和响应，并且这些请求和响应是独立、乱序的。这意味着，一个请求的延迟不再会阻塞其他请求。
因此，HTTP/2下的并行请求优化策略发生了根本性转变：
域名分片不再必要，甚至有害：因为HTTP/2本身就能在一个连接上高效处理多个请求，再去做域名分片反而会增加额外的TLS握手开销和连接管理负担，得不偿失。我建议在HTTP/2环境下，尽量将所有资源都放在一个域名下。服务器推送（Server Push）：这是一个HTTP/2独有的强大功能。服务器可以在客户端请求HTML的同时，主动将客户端可能需要的CSS、JS等资源推送过去，省去了客户端解析HTML后再发起请求的时间。这能显著提升首次渲染速度。请求优先级（Request Prioritization）：HTTP/2允许客户端和服务器为请求设置优先级，确保关键资源能优先传输。头部压缩（HPACK）：HTTP/2对请求头进行了压缩，减少了每次请求的数据量，尤其对于大量小请求来说，效果明显。
总结一下，HTTP/1.x的并行优化是“绕过”连接限制，通过增加连接数来实现；而HTTP/2的并行优化是“利用”多路复用，通过减少连接数、优化单个连接内的传输效率来实现。这两种策略的底层逻辑完全相反，但目标都是提升并行度。
除了并行请求，还有哪些现代浏览器API或技术可以显著提升网络性能？
除了并行请求，现代浏览器和Web技术栈提供了很多强大的API和技术，它们能从不同维度优化网络性能，不仅仅是提升并发那么简单。我个人在项目中尝试过一些，觉得效果非常显著。
Service Workers：网络请求的“超级代理”Service Workers是运行在浏览器后台的脚本，它能拦截、修改甚至生成网络请求。这简直是前端性能优化的“瑞士军刀”。
离线缓存：Service Worker最强大的能力之一就是实现离线访问。你可以缓存应用的静态资源（HTML、CSS、JS、图片），甚至API响应。这样，用户再次访问时，即使没有网络，应用也能瞬间加载，提供“离线优先”的体验。自定义缓存策略：你可以根据请求类型、网络状况等设置不同的缓存策略，比如“网络优先”、“缓存优先”、“仅缓存”等，极大地提升了灵活性和用户体验。后台同步和消息推送：虽然与直接的网络请求性能关联不大，但它们也间接提升了用户体验，比如在网络恢复后自动同步数据，或者在后台接收通知。我曾经用Service Worker为公司的一个PWA应用实现了离线缓存，用户在地铁上也能流畅使用，用户反馈非常好。
Intersection Observer：按需加载的利器这个API可以让你高效地检测元素是否进入或离开视口。它非常适合实现图片、组件、甚至数据列表的“延迟加载”（Lazy Loading）。
图片懒加载：只有当图片进入用户视口时才开始加载，避免了页面初始加载时下载大量用户看不到的图片，从而减少了首次加载的资源量和网络请求。组件懒加载：对于一些不在首屏显示的复杂组件，也可以通过Intersection Observer来判断是否需要加载其对应的JS和CSS。它比传统的滚动事件监听更高效，因为它是由浏览器异步执行的，不会阻塞主线程。
Web Workers：解放主线程Web Workers允许你在后台线程中运行JavaScript脚本，而不会阻塞主线程。虽然它不能直接发起网络请求（需要通过主线程代理），但它能将耗时的计算任务（如大量数据处理、图像处理、复杂算法）从主线程中剥离出来。
提升UI响应性：当主线程被繁重计算阻塞时，页面会变得卡顿。Web Worker将这些计算放到后台，确保UI始终流畅响应用户的操作。间接优化网络请求：如果你的应用在处理网络返回的大量数据时导致卡顿，将数据解析或处理逻辑放到Web Worker中，可以避免影响页面渲染，让用户感觉应用更快。
RequestIdleCallback 与 requestAnimationFrame：调度非关键任务
requestAnimationFrame
：用于在浏览器下一次重绘之前执行动画相关的操作。它确保了动画的流畅性，避免了不必要的重绘和布局计算。
requestIdleCallback
：这个API允许你在浏览器空闲时执行一些非关键任务。比如，你可以在浏览器空闲时去发送一些埋点数据、预处理一些数据、或者进行一些不影响用户体验的后台工作。这能确保主线程在处理用户交互和关键渲染任务时保持畅通。
这些API和技术，各自在不同的场景下发挥作用，但它们的共同目标都是让Web应用更快、更流畅、更节省资源。合理地组合使用它们，能让你的应用在网络性能上达到一个新的高度。
如何评估和监控JavaScript网络请求的性能，并识别瓶颈？
评估和监控网络请求性能是优化工作的基础，没有数据支撑的优化都是盲目的。在我日常工作中，我会结合多种工具和方法来全面了解应用的性能状况，并精准定位问题。
浏览器开发者工具（Developer Tools）：这是最直接、最常用的工具，我几乎离不开它。
Network（网络）面板：这里能看到所有发起的网络请求。你可以查看每个请求的瀑布图（Waterfall chart），了解请求的生命周期（DNS查询、TCP连接、TLS握手、发送请求、等待响应、下载内容）。通过瀑布图，我能一眼看出哪些请求耗时最长，是等待时间长还是下载时间长。它还能显示请求的HTTP头、响应内容、大小、优先级等信息。Performance（性能）面板：在录制性能时，它会显示网络活动、CPU使用情况、主线程活动等。你可以看到网络请求是如何影响页面渲染和JS执行的，这对于识别因网络请求导致的UI卡顿非常有帮助。Coverage（覆盖率）面板：虽然不是直接监控网络，但它可以帮助你发现未使用的CSS和JS代码，这些代码虽然下载了，但并没有被执行，是潜在的优化点。
Web Vitals（核心Web指标）：Google推出的这套指标已经成为衡量用户体验和页面性能的黄金标准。
LCP (Largest Contentful Paint)：最大内容绘制，衡量页面的加载性能。网络请求速度直接影响LCP，特别是首屏图片、大段文本等核心内容的加载时间。FID (First Input Delay)：首次输入延迟，衡量页面的交互性。虽然主要与JS执行有关，但如果大量网络请求导致主线程长时间阻塞，也会影响FID。CLS (Cumulative Layout Shift)：累积布局偏移，衡量页面的视觉稳定性。与网络请求直接关联较小，但如果图片等资源加载导致布局跳动，也会影响CLS。我会定期关注这些指标，它们能告诉我用户实际体验到了什么。
Lighthouse：自动化审计与建议Lighthouse是Google提供的一个开源工具，它可以对网页进行自动化审计，包括性能、可访问性、最佳实践、SEO和PWA等方面。我经常用它来快速获取一份详细的性能报告。
它会给出一个性能得分，并提供一系列具体的优化建议，比如“启用文本压缩”、“预连接到所需来源”、“避免巨大的网络负载”等等。这些建议非常有针对性，能帮助我快速识别和解决常见问题。
RUM（Real User Monitoring，真实用户监控）工具：与Lighthouse等模拟测试不同，RUM工具（如Sentry、New Relic、Datadog、或者自己搭建的监控系统）能收集真实用户在不同设备、网络环境下的性能数据。
你可以看到用户在不同地区、不同运营商网络下的加载时间分布，哪些页面或功能请求最慢，哪些API接口响应延迟最高。这些数据是模拟测试无法提供的，它能帮助你了解真实世界的性能瓶颈。我曾经通过RUM发现某个地区的用户访问特定API接口时延迟特别高，后来排查发现是CDN配置问题。
Synthetic Monitoring（合成监控）工具：WebPageTest、GTmetrix等工具属于合成监控。它们在受控环境中（比如特定的地理位置、网络速度、浏览器版本）模拟用户访问，并提供非常详细的性能分析报告。
这些工具能生成详细的瀑布图、渲染过程的视频、首次字节时间（TTFB）、资源加载顺序等。它们非常适合建立性能基线，并进行回归测试，确保每次部署没有引入新的性能问题。
通过结合这些工具和方法，我能够从不同层面、不同粒度去评估和监控JavaScript网络请求的性能。无论是发现单个请求的耗时问题，还是识别整体的用户体验瓶颈，这些工具都能提供强有力的数据支持，帮助我做出明智的优化决策。
以上就是JS 网络请求性能优化 – 从并行请求到 HTTP/2 的全面提速方案的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521558.html
微信扫一扫 
支付宝扫一扫 
