电商网站实战：HTTP/2 服务器推送优化效果测试与监控
一、测试方法
1.1 准备工作
1.2 测试步骤
1.3 实例演示(以WebPageTest为例)
二、监控
2.1 监控指标
2.2 监控工具
2.3 监控策略
三、常见问题及优化
四、总结
HTTP/2 的服务器推送（Server Push）是个好东西，能显著提升页面加载速度，特别是对于电商网站这种图片、脚本一大堆的场景。但推送用不好，反而会拖后腿。今天咱就来聊聊，怎么通过实际测试和监控，把 HTTP/2 服务器推送的效能榨干，别让它变成“负优化”。
先说说为啥要搞服务器推送。你想啊，用户访问一个页面，浏览器得先下载 HTML，然后解析 HTML，发现里面引用了一堆 CSS、JavaScript、图片，再去一个个请求。这一来一回，时间就耽误了。服务器推送呢，就是让服务器“未卜先知”，在浏览器还没请求这些资源的时候，就主动把它们推过去。这样，浏览器解析 HTML 的时候，发现需要的资源已经躺在缓存里了，直接拿来用，速度当然快了。
但问题来了，服务器也不是真能“未卜先知”，它怎么知道该推哪些资源呢？推多了，浪费带宽；推少了，没效果；推错了，更麻烦。所以，测试和监控就显得尤为重要。
一、测试方法
1.1 准备工作
- 搭建测试环境：最好是模拟真实环境，包括网络环境（比如模拟不同的带宽、延迟）、服务器配置、CDN 等。别在本地随便跑个测试就完事了，那不准。
- 选择测试工具：有很多工具可以用来测试 HTTP/2 服务器推送的效果，比如：
- WebPageTest：老牌的性能测试工具，功能强大，可以模拟各种网络环境，查看资源加载瀑布图，分析推送效果。
- Chrome DevTools：浏览器自带的开发者工具，方便快捷，可以查看网络请求、资源加载时间线等。
- nghttp2：HTTP/2 的命令行客户端，可以用来发送 HTTP/2 请求，查看服务器推送的资源。
- h2load：HTTP/2 的压力测试工具，可以模拟大量并发请求，测试服务器在高负载下的推送性能。
- 确定测试指标：
- 页面加载时间：最重要的指标，包括 DOMContentLoaded、Load 事件触发时间等。
- 资源加载时间：单个资源的加载时间，包括 DNS 解析、TCP 连接、SSL 握手、TTFB（Time To First Byte）、内容下载等。
- 推送资源数量：服务器推送了多少资源。
- 推送资源命中率：推送的资源有多少被浏览器实际使用了。
- 带宽利用率：推送是否占用了过多的带宽。
1.2 测试步骤
- 基线测试：先不开启服务器推送，测试一下页面的加载性能，作为对比基准。
- 开启服务器推送：配置服务器，开启推送功能。不同的服务器配置方法不一样，具体参考服务器文档。
- 测试推送效果：使用测试工具，测试开启推送后的页面加载性能，记录各项指标。
- 调整推送策略：根据测试结果，调整推送策略，比如：
- 调整推送资源：增加或减少推送的资源，或者修改推送资源的优先级。
- 调整推送时机：在 HTML 解析的不同阶段推送不同的资源。
- 使用 HTTP/2 优先级：为不同的资源设置不同的优先级，让重要的资源优先推送。
- 重复测试：重复步骤 3 和 4，直到找到最佳的推送策略。
1.3 实例演示(以WebPageTest为例)
假设我们有一个电商网站的商品详情页，包含 HTML、CSS、JavaScript、多张商品图片。我们使用 WebPageTest 来测试服务器推送的效果。
- 打开 WebPageTest，输入商品详情页的 URL。
- 配置测试参数：
- 测试地点：选择离用户最近的测试地点。
- 浏览器：选择常用的浏览器，比如 Chrome。
- 网络环境：模拟不同的网络环境，比如 3G、4G、Cable。
- 连接数：选择 “HTTP/2 and SPDY”。
- 测试次数：多次测试取平均值，减少误差。
- 运行测试。
- 查看测试结果：
- 瀑布图：查看资源加载的瀑布图，分析哪些资源被推送了，推送的时机是否合适。
- 资源加载时间线：查看每个资源的加载时间，分析推送是否缩短了资源的加载时间。
- 性能指标：查看页面加载时间、TTFB 等指标，分析推送是否提升了整体性能。
通过 WebPageTest 的测试结果，我们可以看到服务器推送是否真的提升了页面加载速度，哪些资源被推送了，推送的时机是否合适，等等。根据这些信息，我们可以进一步调整推送策略，优化推送效果。
二、监控
测试只是暂时的，监控才是长久的。我们需要持续监控服务器推送的效果，及时发现问题，并进行调整。
2.1 监控指标
除了测试阶段关注的指标外，我们还需要关注以下指标：
- 推送请求数量：服务器发起了多少次推送请求。
- 推送数据量：服务器推送了多少数据。
- 推送失败率：推送请求失败的比例。
- 缓存命中率：推送的资源有多少被浏览器缓存命中。
- 用户体验指标：比如首屏渲染时间、可交互时间等，这些指标更能反映用户的真实感受。
2.2 监控工具
- 服务器日志：分析服务器日志，可以获取推送请求数量、推送数据量、推送失败率等信息。
- 网络监控工具：比如 Wireshark、tcpdump，可以抓取网络数据包，分析 HTTP/2 的流量，查看推送的资源。
- APM（Application Performance Monitoring）工具：比如 New Relic、Dynatrace、AppDynamics，可以监控应用的性能，包括 HTTP/2 的性能，查看推送的效果。
- RUM（Real User Monitoring）工具：比如 Google Analytics、百度统计，可以监控真实用户的访问情况，收集用户体验指标。
2.3 监控策略
- 定期巡检：定期查看监控数据，分析推送效果，发现潜在问题。
- 告警设置：设置合理的告警阈值，当推送指标异常时，及时发出告警。
- 持续优化：根据监控数据，持续优化推送策略，提升推送效果。
三、常见问题及优化
- 推送了太多无用资源：
- 原因：服务器推送策略过于激进，推送了太多浏览器不需要的资源。
- 优化：精细化推送策略，只推送必要的资源。可以使用 HTTP/2 优先级，为不同的资源设置不同的优先级。
- 推送时机不当：
- 原因：服务器在 HTML 解析完成之前就推送了所有资源，导致浏览器无法及时渲染页面。
- 优化：在 HTML 解析的不同阶段推送不同的资源。比如，在解析
<head>标签时推送 CSS，在解析<body>标签时推送 JavaScript 和图片。
- 推送资源优先级不合理：
- 原因：服务器没有为不同的资源设置不同的优先级，导致重要的资源没有优先推送。
- 优化：使用 HTTP/2 优先级，为不同的资源设置不同的优先级。比如，将 CSS 的优先级设置为最高，JavaScript 和图片的优先级设置为较低。
- CDN不支持服务器推送：如果你的网站使用了 CDN，需要确保 CDN 支持 HTTP/2 服务器推送。否则，即使服务器开启了推送，CDN 也不会将推送的资源转发给浏览器。
- 浏览器兼容性问题：虽然大多数现代浏览器都支持 HTTP/2，但仍有一些老旧的浏览器不支持。你需要考虑这些浏览器的兼容性问题。
四、总结
HTTP/2 服务器推送是个好东西，但用好它并不容易。通过测试和监控，我们可以了解推送的效果，发现潜在问题，并进行优化。记住，没有最好的推送策略，只有最适合的推送策略。你需要根据你的网站的特点，不断测试、监控、优化，才能找到最佳的推送策略，让你的网站飞起来！
上面说了这么多，其实就一句话：实践出真知。别光看理论，动手试试，你会发现更多有趣的东西。
最后，我想说，技术是不断发展的，HTTP/2 之后还有 HTTP/3，优化之路永无止境。保持学习，保持好奇心，才能在这个快速变化的时代立于不败之地。共勉！