Google+

摘要

Google+ 将全面响应客户需求。

采用自适应格式

从“僵尸猫”到“老式计算器” Google+ 可让人们聚集在一起，共同探讨共同的兴趣爱好。不久之前，Google+ 网站有两个不同版本：一个是桌面版，另一个是专为旧版浏览器设计的移动网站。

挑战

维护两个网站为其带来了一组独特的挑战。拥有单独的网站版本意味着每项功能都必须实现两次。这导致需要编写大量重复代码，并投入更多精力针对桌面版网站和移动网站优化两种体验。随着设备之间的界限日趋模糊（有支持触摸的桌面设备以及屏幕越来越大的强大移动设备），针对桌面设备和移动设备采用不同的设计变得越来越没有意义。

随着我们不断添加功能，旧版桌面版网站也变得越来越慢，越来越膨胀。今年早些时候，我们的首页大小约为 5MB，并生成了大约 250 个 HTTP 请求。只是表现不理想。网站上的图片过于繁重且未经优化，这会进一步拖慢网页速度。因此，在速度缓慢且不稳定的网络上，我们的视频流几乎无法访问，这些用户的体验通常很令人失望。此外，由于我们需要在移动网站上支持旧版浏览器，因此我们在整个网站上都不能依赖 JavaScript，这也阻碍了我们实现高度互动功能。我们不能依赖移动网络浏览器的进步。

解决方案

我们最初将重点放在自适应设计上，这是一种可在移动设备、平板电脑、桌面设备等设备上实施的实现方式。我们深入探讨了每一个功能、网页、JavaScript 库和 CSS 类我们希望构建一个系统，确保网站只会下载正常运行所必需的（除非用户要求更多）。我们面临的挑战在于，要想打造一个能够在具有移动网络连接、速度较慢的手机上正常运行的网站，同时又能在速度较快的浏览器和大屏设备上提供出色的沉浸式体验。

这组限制条件意味着我们必须仔细检查以后的每一次代码更改。为了实现这一点，我们制定了一条 6^5 的规则，确保在初始网页加载时下载不超过 6 万的 HTML、6 万的 JavaScript、6 万的 CSS，动画的帧速率始终为 60fps，平均延迟时间为 0.6 秒。

为了实现这一点，我们选择了从一开始就构建了模块化和延迟加载的 JavaScript 和 CSS 框架。因此，我们可确保用户仅在实际使用需要 JavaScript 和 CSS 的功能时才下载它们。这是通过与构建和模块系统相结合的模板驱动方法完成的，开发者几乎无需花费精力即可实现这些功能。

利用以下新框架，我们开始为网页版 Google+ 的重新实现进行原型设计。我们开始禁止“不良”行为，并为开发设定严格的规则。我们的主要规则之一是，我们的所有网页都需要同时在服务器端和客户端呈现。通过服务器端呈现，我们可以确保用户可在 HTML 加载后立即开始阅读，而不需要运行 JavaScript 来更新网页内容。一旦页面加载完毕且用户点击某个链接，我们不希望执行一整个往返来再次呈现所有内容。这时客户端渲染就变得非常重要 - 我们只需提取数据和模板，然后在客户端上渲染新页面。这需要权衡很多因素；因此我们使用了一种框架，能够使服务器端和客户端渲染变得简单，而无需在服务器上和客户端上重复实现所有内容。

其他规则包括禁止使用高度和宽度动画，因为此类动画会导致浏览器重新布局并对性能产生负面影响。对于 DOM 操作和动画，我们安排了与浏览器的渲染刷新频率同步的任务。我们还将所有测量任务组合在一起，以避免开销很高的重复样式计算。我们还主要依赖于 Chrome 性能分析器工具来确保一切按预期运行。此外，我们还创建了一些工具，用于计算代码更改对 JS 足迹的影响，以确保不会大幅增加网页大小。

这需要一些时间，但如果没有在构建过程中识别和消除问题的能力，难度会更大。

我们于 2015 年 2 月发布了此自适应实现的移动网络版本。这让我们能够对新设计和新流程进行审核。我们利用此次发布的相关数据验证了哪些做法有效，哪些无效。我们对设计进行了迭代，并开始扩展以支持更多设备。2015 年 11 月，我们面向所有设备推出了这一新实现。

成果

Google+ 得以在不牺牲性能的情况下构建具有丰富界面的复杂 Web 应用。与以往相比，网站现在更快速、更精简。

	之前	之后
首页总大小，GZip 压缩（含图片）	22,600 KB	327 KB
请求数	251	45
HTML（未经过 gzip 压缩）	1,100 KB	362 KB
JavaScript 和 CSS（GZip 压缩）	2768 KB	111KB
平均完整网页加载时间（延迟时间）	12 秒 0.7 秒到第一个字节	3 秒 0.1 秒到第一个字节