我们对于如何让网页于 1 秒内在移动网络上呈现完毕提出了一些建议，而 PageSpeed Insights 可通过分析网页来了解相应网页是否遵循了此类建议。研究显示，任何超过 1 秒的延迟都会打断用户的思路，因而会有损用户体验。我们的目标是：无论用户使用什么设备或哪类网络，我们都要确保用户能够一直与网页互动，并为其提供最佳体验。
不超出 1 秒的时间预算目标并非易事。幸运的是，我们并不需要在这一时间预算内呈现整个网页，而是要在 1 秒内提供并呈现首屏 (ATF) 内容，让用户尽快开始与网页互动。 然后，当用户查看首屏内容时，系统可在后台逐步加载网页的剩余部分。
适应高延迟的移动网络
若想在移动设备上践行“首屏秒开”标准，我们就需要面对在其他网络中从未遇到过的独特挑战。用户可能正通过 2G、3G 或 4G 等各种各样的网络来访问您的网站。移动网络的延迟明显高于有线连接，并且会耗用我们的 1000 毫秒预算（用于呈现 ATF 内容）中的很大一部分时间。
目前，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 元素（例如< p style=...>）中使用内嵌 CSS 属性，因为它们经常会导致不必要的代码重复，而且默认情况下会被 CSP 拦截（对“style-src”字段使用“unsafe-inline”指令可以停用此类拦截）。默认情况下，CSP 会拦截所有内嵌脚本代码（如果您启用了 CSP）。如果您有内嵌 JavaScript，则需要将 CSP 政策更新为使用脚本哈希值或随机数或使用“unsafe-inline”，以便能够执行所有内嵌脚本。如果您有内嵌样式，则需要将 CSP 政策更新为使用样式哈希值或随机数或使用“unsafe-inline”，以便所有内嵌样式块都能得到处理。
还有其他疑问？欢迎随时在我们的 pagespeed-insights-discuss 论坛中提出问题和提供反馈。