HTTP/2 服务器推送与懒加载：鱼与熊掌如何兼得？

HTTP/2 的服务器推送（Server Push）和我们常说的懒加载（Lazy Loading）听起来似乎是“死对头”：一个主动“推”，一个被动“拉”，它们真的水火不容吗？别急，今天咱们就来好好聊聊这俩技术，看看它们各自的本事、脾气，以及在什么场景下能发挥出最大威力。

先说，这俩技术可都是为了提升网页性能而生的，只是“路子”不太一样。理解它们的区别和联系，能帮你更好地优化你的网站，让用户体验“嗖嗖”地提升。

一、HTTP/2 服务器推送：先下手为强

想象一下，你去餐厅吃饭，还没点菜呢，服务员就把招牌菜、小吃、饮料一股脑儿全给你端上来了。你可能会觉得有点懵，但如果这些菜正好都是你想吃的，那是不是省了你不少事？

HTTP/2 服务器推送差不多就是这个意思。在传统的 HTTP/1.1 协议下，浏览器要先请求 HTML 文件，然后解析 HTML，发现里面引用了 CSS、JavaScript、图片等资源，再一个个去请求这些资源。这就像你点一道菜，服务员上一道菜，来来回回好几次，效率自然就低了。

而有了 HTTP/2 服务器推送，服务器可以在浏览器请求 HTML 之前，就“预判”到浏览器可能需要哪些资源，然后主动把这些资源“推”给浏览器。这样，浏览器解析 HTML 的时候，发现需要的资源已经躺在缓存里了，直接拿来用就行，省去了多次请求的开销，页面加载速度自然就快了。

1.1 服务器推送的“超能力”

• 减少请求往返次数（RTT）： 这是服务器推送最大的优势。在高延迟网络环境下，效果尤为明显。你想啊，每次请求都要经过“漂洋过海”才能到达服务器，一来一回得多耽误工夫？服务器推送直接把资源“打包”送过来，省去了多次“漂洋过海”的时间。
• 并行加载资源： HTTP/2 本身就支持多路复用，多个请求可以在同一个连接上并行发送。服务器推送更是把这个能力发挥到了极致，可以在浏览器还没“开口”要的时候，就并行推送多个资源。
• 缓存优化： 服务器推送的资源会被浏览器缓存起来。如果用户访问其他页面时需要相同的资源，直接从缓存里拿就行，不用再向服务器请求了。

1.2 服务器推送的“脾气”

服务器推送虽好，但也不是万能的。如果用不好，反而会适得其反。

• 推送了不需要的资源： 如果服务器“猜”错了，推送了一些浏览器根本不需要的资源，那就浪费了带宽和浏览器的资源。
• 推送时机不当： 如果服务器推送资源的时机太晚，浏览器已经发起了请求，那就失去了推送的意义，甚至可能导致资源重复加载。
• 缺乏优先级控制： 服务器推送的资源可能会和浏览器主动请求的资源“抢”带宽，如果不能合理控制优先级，可能会导致关键资源加载延迟。

1.3 怎么用好服务器推送？

• 精准预测： 服务器要尽可能准确地预测浏览器需要的资源。这可以通过分析用户行为、网站结构等方式来实现。
• 合理配置： 可以通过 HTTP/2 的 Link 头来告诉服务器要推送哪些资源，也可以通过一些服务器配置来实现。
• 优先级控制： 利用 HTTP/2 的优先级机制，给推送的资源设置合适的优先级，确保关键资源优先加载。
• 利用preload: 使用<link rel="preload">标签可以更精细地控制资源的加载时机和优先级，它告诉浏览器预先加载某个资源，但不立即执行（比如JavaScript）,和服务器推送一起使用，效果更佳。

二、懒加载：按需加载，精打细算

懒加载就比较“抠门”了，它奉行“用时再取”的原则。在页面初始加载时，只加载首屏可见区域的内容，其他部分的内容（比如图片、视频等）先用占位符代替，等用户滚动到相应位置时，再去加载实际内容。

这就好比你去超市买东西，不会把所有商品都塞进购物车，而是先看看自己需要什么，再一样一样地拿。这样既减轻了购物车的负担，也避免了浪费。

2.1 懒加载的“好处”

• 减少初始加载时间： 只加载首屏内容，大大减少了需要传输的数据量，页面加载速度自然就快了。
• 节省带宽： 对于那些用户可能不会看到的内容，懒加载可以避免不必要的加载，节省了用户和服务器的带宽。
• 提升用户体验： 页面加载快了，用户等待时间减少，体验自然就更好了。尤其是在移动端，网络环境不稳定，懒加载的效果更明显。

2.2 懒加载的“注意事项”

• 占位符处理： 占位符的设计要合理，既要能提示用户这里有内容，又不能影响页面布局。
• 加载时机： 要把握好加载时机，不能让用户等太久。通常是在用户滚动到占位符附近时就开始加载。
• SEO 影响： 传统的懒加载可能会对搜索引擎爬虫不友好，因为爬虫可能看不到懒加载的内容。不过，现在主流搜索引擎已经能够很好地处理懒加载了。

2.3 懒加载的实现方式

• 使用 JavaScript 监听滚动事件： 这是最常见的实现方式。通过监听 scroll 事件，判断元素是否进入视口，然后动态加载内容。
• 使用 Intersection Observer API： 这是浏览器提供的原生 API，可以更高效地检测元素是否可见。它的性能更好，也更易于使用。
• 使用 loading="lazy" 属性： 这是 HTML5 新增的属性，可以直接给 <img> 或 <iframe> 标签添加 loading="lazy"，浏览器会自动实现懒加载。这是最简单的方式，但兼容性还不太好。

三、服务器推送 vs. 懒加载：谁更胜一筹？

说了这么多，你可能还是有点晕：到底该用服务器推送还是懒加载呢？

其实，这俩技术并不是“二选一”的关系，它们各有各的适用场景，甚至可以结合起来使用。

• 服务器推送更适合：
  • 关键资源： 比如首屏渲染所需的 CSS、JavaScript 等。这些资源对页面加载速度影响很大，适合用服务器推送来加速。
  • 高确定性资源： 比如网站的 logo、通用的 JavaScript 库等。这些资源几乎每个页面都会用到，可以放心地推送。
  • 高延迟网络环境： 服务器推送可以减少 RTT，在高延迟环境下效果更明显。
• 懒加载更适合：
  • 非关键资源： 比如图片、视频、非首屏的 JavaScript 等。这些资源可以延迟加载，不影响首屏渲染。
  • 不确定性资源： 比如用户评论、相关文章等。这些资源不一定每个用户都会看到，适合用懒加载来避免浪费。
  • 低带宽网络环境： 懒加载可以减少初始加载的数据量，在低带宽环境下效果更明显。

组合拳：

想象一下这个场景：

1. 网站首页有一个很大的背景图，但不是首屏渲染必需的。
2. 用户首次访问。

我们可以：

• 服务器推送： 推送首屏渲染必需的 CSS 和 JavaScript。
• 懒加载： 对于大背景图，使用懒加载，等用户滚动到相应位置时再加载。
• preload: 使用<link rel="preload">预加载首屏下面一点点的内容，提供更好的滚动体验。

这样，既保证了首屏加载速度，又避免了浪费带宽，还兼顾了用户体验。完美！

四、总结

HTTP/2 服务器推送和懒加载都是优化网页性能的利器。服务器推送“主动出击”，懒加载“精打细算”，它们各有千秋，也各有局限。在实际应用中，我们要根据具体场景，选择合适的技术，甚至可以把它们结合起来使用，发挥出 1+1>2 的效果。

记住，没有最好的技术，只有最适合的技术。理解了这些技术的原理和特性，你就能在网页性能优化的道路上走得更远，为用户打造更流畅、更愉悦的体验。别再纠结“鱼”和“熊掌”了，咱们完全可以“我全都要”！