【第620期】PC与无线齐飞，Web共Native一色——天猫首页全解密

前言

现在我们来回顾一下关于淘宝首页的揭秘【第607期】聊一聊淘宝首页和它背后的一套，今天我们来看看由@带来天猫首页在前端技术上的应用与变迁的分享。本文由

正文从这开始～

从14年实习开始参与PC首页的开发，到15年正式入职同时负责无线端的首页，至今已经两年的时间。期间历经了6次改版、php到Node端的迁移、ReactNative的尝试、无线端性能优化、进入ES6时代、WeeX的尝试等等，不一而足，感触颇多，与大家分享。

也是一篇难得的长文，先放提纲。

一、天猫首页的定位
二、天猫首页的技术架构变迁史
1. 从PHP到Node的蜕变
2. 从静到动，从PC到移动端的飞跃
3. 光影融合，Web与客户端的交汇
三、疾如风——天猫首页的性能优化
四、侵略如火——大胆的Native化尝试
1. ReactNative的初登场
2. WeeX的回归
五、不动如山——天猫首页的稳定性保障
六、小结

一、天猫首页的定位

在了解天猫首页的技术架构之前，先让我们问自己一个问题：首页到底是什么？是用户关于这个网站的第一印象吗？还是所有业务的起始点？

简而言之，天猫首页有着以下三个特点：

• 面向最广大消费者的标杆与门面。

• 流量的入口与中转站。

• 轻耦合，新技术的试验田。

作为天猫的门面，往往决定了消费者对于天猫的第一印象，所以天猫首页一直在性能优化上有着孜孜不倦的追求，优化加载性能、交互体验、减少流量消耗、Native等多种方式给于消费者更好的体验。

作为流量的中转站，首页赋予了运营非常多灵活机动的能力，例如节日氛围的营造、机动区块的变化能力，并且全面铺开个性化，能够基于人群、地区推荐更加适合用户的商品，导流效率遥遥领先于其他页面。

作为新技术试验田，天猫首页一直处于开放的态度，敢打敢冲，率先尝鲜新技术并落地：2014年9月份率先从PHP迁移到Node、天猫内第一个尝试ReactNative、第一个进入ES6时代、第一个落地WeeX的重要业务。在这一过程中，天猫首页往往会克服非常多先行者的困难，并反哺新技术的优化与成熟。

二、天猫首页的技术架构变迁史

天猫首页的技术架构变迁，主要是基于两个部分：内部搭建系统&模板渲染系统的变更、业务重点的变更。

1. 从PHP到Node的蜕变

在PHP时代，主要存在以下问题：

• 老旧的服务端实时渲染架构。渲染性能差、服务集群庞大使得文件同步生效慢。

• 旧搭建系统规范使得效率低。需要手动在php文件中挖出供运营填写数据的位置，该数据位难以定义其他校验规范。

• php文件和css/js文件不属于同一套部署系统，需要手动控制顺序，先发布新版本css/js文件到cdn，再发布php文件更新引用css/js文件的版本，容易出现发布手误。

在Node时代，上述问题都得到了解决，在首页完成迁移Node的尝试后，我们拥有了新的内部搭建系统斑马和模板渲染系统Wormhole：

• 在使用『Cache集群缓存渲染好的HTML』这一架构后，性能、抗压能力、可扩展性都有了极大的提升(关于这一点详细可以看的回答)。

• 接入schema规范系统，建立数据位置的代码与前端代码解耦。

• 隔离职能。HTML模板代码专注于渲染，不再处理其他事情。

• 部署系统统一。不再出现需要关注文件发布顺序、手动升级版本的情况。

2. 从静到动，从PC到移动的转身
从2014年开始，天猫开始集体转型，迎接移动端时代的来临，直到2015年双十一，移动端成交占比已达到68%。

无线时代有甜也有苦：

• 不需要纠结坑爹的IE兼容性，但是老版本的安卓兼容起来更加痛苦

• 因为安卓的碎片化，响应式也是需要考虑的重要问题

• 高清化的处理方案

• 部分方案需要优化如iconfont，因为可能会发送多个请求，影响性能

• 糟糕的网络环境、机器性能、系统特性对于性能有着更加极致的需求

因为移动端和PC端用户的使用习惯差距较大，同时考虑后续维护的方便性，移动端的天猫首页的UI设计上并未使用传统概念上的响应式(PC和移动端一套代码)，而是与天猫客户端保持一致。

这一前提使得移动端Web首页可以和客户端共用接口，共享同一份数据来源，避免运营填写多份数据，节省运营成本，又因为移动端大量个性化推荐的需求，千人千面的展现方式，所以移动端Web首页采用了异步渲染的方案——页面进入只载入框架，再调用接口获取数据和模板，在浏览器端进行渲染。这样做也有诸多好处：客户端中访问可以使用离线包、更少的流量消耗、更细粒度的ABTest、对接其他数据源更方便等等。

同时还实现了一套可以快速满足区块调整需求的动态化布局方案，完美地支持了多次需求变更而无需前端代码发布，详细可见发表在天猫前端团队博客的这篇文章，

3. 光影融合，Web和客户端的交汇
相比起客户端业务迭代的成本、体积和发版劣势，Web的低成本、迭代快、跨平台的特性，使得绝大多数客户端的业务都会选择嵌入Web的方式。而客户端的黏性，使得这个Web页面相当大一部分的流量都来源于客户端。

那么一个新的问题来了：『客户端中的Web页面如何利用客户端的能力？是不是可以将Web和客户端进行融合，获取更好的体验？』

最初尝试了几个方案：

• Hybrid API。

• 跳转部分高频页面根据Url规则拦截到Native页（如商品详情页）。

• 复用客户端建立的网络链路

• 离线包等等

都取得了一定的效果，但是还需要一套更加完整彻底的方案。所以在2015年7月React Native如火如荼的时候，天猫首页立刻开启了尝试的项目，相关内容后文详述。

三、疾如风——天猫首页性能优化

性能一直是首页所需要关注的要点，希望能给用户更好的体验。

首先明确一点，有很多优化不是单纯的前端团队能够完成的，有CDN团队和服务端团队的支持，让前端同学感觉像生活在极乐天国。《高性能网站建设指南》这本书里提到的方法都比较基础了，在此略过。

除此之外，我们还做了以下对于性能有着显著影响的事情：

• css/js文件combo。我们的CDN和前端Loader支持实时url的combo，可以实现按需加载。如果CDN没这个条件，也可以使用webpack等前端工具进行合并打包。

• 懒加载。优先渲染首屏内容，其余模块资源延后或者用户有交互的时候加载。

• Webp图片格式。对比这两张图，可以发现Webp格式的图小得多，WebP格式的图：；jpg格式的图：。感谢（图片存储系统的同学）。

• 裁剪合适尺寸的图片。如果某一张图片运营投放的尺寸过大，可以根据实际的尺寸，加上后缀截取，如『』。

• 拍扁所有请求。每个模块渲染所需要的请求不能是两个请求串行。

• 数据请求支持自由合并。（感谢服务端同学）

• 前端首屏只请求后端一个请求，由后端做对接其他系统的并行请求。

• 利用动态化布局保证模块之间的高复用。

• 图片域名收敛。因为CDN支持SPDY协议，所以收敛域名可以有效节省DNS解析时间。

• 天猫前端组件规范整体升级，移动端去KISSY，变得更加轻量，减少流量消耗。

• 离线包。如果页面是纯异步渲染，可以考虑在客户端中设置离线包。只有当用户处于wifi且网络空闲时，客户端才会去下载离线包，二次访问效果拔群。

再让我用一张图说明页面渲染各个阶段可以做的优化。

除了加载性能外，还需要考虑交互性能，例如页面滚动时的帧率。

除了用requestAnimationFrame来将模块渲染切片，避免UI线程阻塞。如果页面的hover和mouseenter效果过多，还可以在用户滚动时，设置全局的pointer-event:none，避免在滚动的时候触发大量hover效果，实测效果拔群。

四、侵略如火——大胆的Native化尝试

相比起Web而言，APP有着更好的体验；但相比APP，Web的开发效率和发版优势毋庸置疑，如何融合两者，一直是前端的重要探索方向之一。

1. ReactNative的初登场
2015年7月，天猫首页立刻进行了ReactNative的尝试。

但在尝试过程中遇到了非常多的问题，满满的坑和血泪：

• 一方面是ReactNative彼时并不完善，调试体验非常糟糕，莫名其妙红屏不知原因，还有升级0.8.0后会顺手升级iojs为3.x,和2.x的iojs并不兼容。

• 另一方面是当时考虑并不完备。工程化落地一个技术需要考虑的因素非常多：多版本降级&兼容方案、开发调试工具、环境一致性、埋点、测试、监控、后续维护成本等等，需要考虑一系列的方案。

因为没有拿到数据和结果，并且没有足够的人力维护多一个版本的页面时，RN版的首页选择了停止维护。

2. WeeX的回归
正如灰太狼被打飞时常说的一句话——『我还会回来的』，在手淘团队推出了一套新的Native化方案WeeX以后，天猫首页又死性不改蠢蠢欲动地进行了尝试。

这一次考虑较为全面，上述RN落地时没考虑的方案都有一定的考虑和解决，例如：

• 自动构建Web版本以降低维护成本

• 多Weex版本的降级方案

• Cache集群部署Detector自动识别请求是否支持WeeX并返回对应内容。

实际体验优于Web，从业务数据上来看也取得了较好的结果。

感兴趣的同学可以使用iOS手机淘宝客户端5.7.0以上版本扫码下述图片体验。


Weex页面非常精简，gzip后首页JSBundle的大小大概是13K，是Web的十五分之一。

WeeX即将开源，敬请期待。

五、不动如山——天猫首页的稳定性与保障

大概是心有灵犀吧，天猫首页和淘宝首页也采用了非常类似的容灾和监控机制，有小胡子哥的详述，我在此就一笔带过。

1.在容灾方面：

• 如果接口请求失败，会依次加载本地缓存、访问CDN的备份文件等。

• 对于运营填写的数据内容质量，投放系统配置了详细的校验，如最大字数等等。

2. 在监控方面：

• 有全量监控的埋点方案。能够全网统计到各个模块的运行状况和接口调用的健康情况。

• 有客户端层面的监控方案。能够拿到更多Web运行时无法自己拿到的信息，如当前页面某一链接404。

• 有业务监控的方案。能够保障页面的业务内容一定是符合预期的。因为首页的数据来源相当多，一个页面对应几十个运营，对于数据内容的质量是一定要保障的。

六、小结

接下来天猫首页还会做的事情大概有：

• 赋能运营。接入个性化合图系统，免去了运营找设计师做图的成本等等；

• 国际化。为了方便弱网地区用户的访问，对于性能有更高的要求，对于设计、素材也有更高的要求。

关于本文

作者：@

原文连接：https://zhuanlan.zhihu.com/p/21294873