使用 PageSpeed Insights 进行移动版分析

我们对于如何让网页于 1 秒内在移动网络上呈现完毕提出了一些建议,而 PageSpeed Insights 可通过分析网页来了解相应网页是否遵循了此类建议。研究显示,任何超过 1 秒的延迟都会打断用户的思路,因而会有损用户体验。我们的目标是:无论用户使用什么设备或哪类网络,我们都要确保用户能够一直与网页互动,并为其提供最佳体验。

不超出 1 秒的时间预算目标并非易事。幸运的是,我们并不需要在这一时间预算内呈现整个网页,而是要在 1 秒内提供并呈现首屏 (ATF) 内容,让用户尽快开始与网页互动。 然后,当用户查看首屏内容时,系统可在后台逐步加载网页的剩余部分。

适应高延迟的移动网络

若想在移动设备上践行“首屏秒开”标准,我们就需要面对在其他网络中从未遇到过的独特挑战。用户可能正通过 2G、3G 或 4G 等各种各样的网络来访问您的网站。移动网络的延迟明显高于有线连接,并且会耗用我们的 1000 毫秒预算中的很大一部分时间:

  • 对于 3G 网络,往返时间会占用其中的 200-300 毫秒
  • 对于 4G 网络,往返时间会占用其中的 50-100 毫秒

目前,4G 在全球移动网络中处于主导地位,所以您应当抱有以下预期:您的大部分用户都是在通过 4G 网络访问您的网页。因此,我们必须假设每项网络请求的平均耗时将会是 100 毫秒。

基于这项假设,我们现在不妨逆向思考一下。如果我们仔细分析浏览器与服务器之间的典型通信过程,就会发现网络本身已经消耗掉了 300 毫秒的时间:一次 DNS 查找(用于将主机名(比如 google.com)解析为 IP 地址)、一次网络往返(用于执行 TCP 握手)以及一次可选的 TLS 连接。所以,留给我们的时间就只有 700 毫秒了。

在不到 1 秒的剩余预算内将内容呈现出来

在除去网络延迟之后,我们的预算就只剩下 700 毫秒了,但我们仍有大量的工作要做:服务器必须呈现响应内容,客户端应用代码必须得到执行,而且浏览器必须完成内容的布局和呈现。有鉴于此,以下标准应该能帮助我们在预算范围内搞定一切:

(1) 服务器必须在 200 毫秒内呈现响应内容
服务器响应时间就是在除去网络传输时间之后,服务器返回初始 HTML 所花费的时间。因为我们剩下的时间实在太少了,所以这个时间应该控制在最低限度:理想情况下应该保持在 200 毫秒以内,而且越少越好!
(2) 应尽可能减少重定向次数
额外的 HTTP 重定向可能会增加一次或两次额外的网络往返(如果需要再次查找 DNS 的话就是两次),这在 4G 网络上将会导致数百毫秒的额外延迟。因此,我们强烈建议网站站长尽可能减少重定向次数,而且最好完全消除重定向。这对 HTML 文档来说尤其重要(尽可能避免重定向到“m.”网址)。
(3) 应尽可能减少首次呈现内容所需的网络往返次数

鉴于 TCP 评估连接状况的方式(即 TCP 慢启动),新的 TCP 连接无法立即使用客户端和服务器之间的全部有效带宽。因此,在通过新连接进行首次往返的过程中,服务器最多只能发送 10 个 TCP 数据包(约 14KB),然后必须等待客户端确认已收到这些数据,才能增大拥塞窗口并继续发送更多数据。

另外还需注意的是,10 个数据包 (IW10) 这一限值源自 TCP 标准的最近一次更新:您应确保自己的服务器已升级到最新版本,以便能够充分利用这次更新。否则,这一限值可能会降低到 3-4 个数据包!

考虑到 TCP 的这种行为,请务必优化您的内容,以尽可能减少为传输必要数据(以完成网页的首次呈现)而需进行的网络往返的次数。理想情况下,ATF 内容应小于 98KB,这样浏览器才能在 3 次网络往返之后即可显示网页内容,以便为服务器响应延迟和客户端呈现留出充足的时间预算。

(4) 避免在首屏内容中包含会阻止内容呈现的外部 JavaScript 和 CSS

浏览器必须先解析网页,然后才能将其呈现给用户。如果浏览器在解析过程中遇到非异步或阻止呈现的外部脚本,则必须停止解析并且下载相应资源。每当发生这种情况时,都会增加一次网络往返过程,这势必会导致网页的首次呈现时间被延迟。

因此,用于呈现首屏内容的 JavaScript 和 CSS 应内嵌到网页中,而用于为网页增添附加功能的 JavaScript 或 CSS 应在 ATF 内容呈现完毕后再开始加载。

(5) 为浏览器布局和呈现预留时间(200 毫秒)
解析 HTML 和 CSS 以及执行 JavaScript 的过程同样需要消耗时间和客户端资源!这个过程可能需要耗用几百毫秒的时间,具体取决于移动设备的运行速度和网页的复杂程度。我们建议您为浏览器的开销预留 200 毫秒的时间。
(6) 优化 JavaScript 的执行及呈现用时
执行复杂的脚本和低效的代码可能会耗费数十甚至数百毫秒的时间 - 因此,我们建议您使用浏览器中内置的开发者工具来分析和优化代码。若想了解详细信息,请参阅我们的 Chrome 开发者工具互动课程

常见问题解答

我使用的是 JavaScript 库(例如 jQuery),有什么建议吗?
很多 JavaScript 库(例如 jQuery)都可用来增强网页,从而为网页增添额外的互动性、动画和其他效果。不过,这些行为大多可在 ATF 内容呈现后再添加,这样可确保无虞。我们建议您考虑将此类 JavaScript 的执行和加载延迟到网页加载完毕后。
我要使用 JavaScript 框架来构造网页,有什么建议吗?
如果网页内容是由客户端 JavaScript 构建的,那么我们建议您考虑嵌入相关的 JavaScript 模块以避免产生额外的网络往返过程。同样,利用服务器端呈现可显著提升网页的首次加载速度,具体方法如下:在服务器上呈现 JS 模板,并将结果内嵌到 HTML 中,然后在应用加载完毕后使用客户端模板。
如何识别网页中的关键 CSS?
在 Chrome 开发者工具中,打开“审计”面板并运行“网页性能”报告,然后在生成的报告中寻找“移除未使用的 CSS 规则”。您也可以使用其他任何第三方工具或脚本,以此来识别各个网页分别应用了哪些 CSS 选择器。
可以自动应用这些最佳做法吗?
当然可以。很多开放源代码的商业性网页性能优化 (WPO) 产品都可以帮助您满足上述部分或全部标准。要了解开放源代码的解决方案,请参阅 PageSpeed 优化工具
如何调整服务器以满足这些标准?
首先,请确保您的服务器运行的是最新版操作系统。若想充分利用增大后的 TCP 初始拥塞窗口大小 (IW10),您需要使用 Linux kernel 2.6.39 或更高版本。对于其他操作系统,请查阅相关文档。
若想优化服务器响应用时,请编写相应代码,或使用一种应用监控解决方案来找出性能瓶颈(例如脚本运行时、数据库调用、RPC 请求、内容呈现,等等)。这样做的目的是,力求在 200 毫秒内呈现 HTML 响应内容。
应该如何处理“内容安全政策”(CSP)?
如果您使用的是 CSP,则可能需要更新您的默认政策。
首先,应尽可能避免在 HTML 元素(例如 &lt p style=...&gt)中使用内嵌 CSS 属性,因为它们经常会导致不必要的代码重复,而且默认情况下会被 CSP 拦截(对“style-src”字段使用“unsafe-inline”指令可以停用此类拦截)。默认情况下,CSP 会拦截所有内嵌脚本代码(如果您启用了 CSP)。如果您有内嵌 JavaScript,则需要将 CSP 政策更新为使用脚本哈希值或随机数或使用“unsafe-inline”,以便能够执行所有内嵌脚本。如果您有内嵌样式,则需要将 CSP 政策更新为使用样式哈希值或随机数或使用“unsafe-inline”,以便所有内嵌样式块都能得到处理。

还有其他疑问?欢迎随时在我们的 pagespeed-insights-discuss 论坛中提出问题和提供反馈。