想必很多人都已经看到了新版的淘宝首页，它与以往不太一样，这一版页面中四处弥散着个性化的味道，由于独特的个性化需求，前端也面临各方面的技术挑战：

• 数据来源多

• 串行请求渲染一个模块

• 运营数据和个性化数据匹配和管理

• 数据兜底容灾

本次淘宝首页改版，虽已不再支持 IE6 和 IE7 等低版本的古董浏览器，但依然存在多个影响首页性能的因素：

• 依赖系统过多，数据的请求分为三块，其一是静态资源（如 js/css/image/iconfont 等）；其二是推到 CDN 的静态数据（如运营填写的数据、前端配置信息等）；其三是后端接口，不同的模块对应不同的业务，而且页面中还有不少的广告内容，粗略估计页面刚加载时首屏 发出的接口请求就有 8 个，滚到最底下，得发出 20 多个请求。

• 无法直接输出首屏数据，首屏很多数据是通过异步请求获取的，由于系统限制，这些请求不可避免，而且请求个数较多，十分影响首屏时间。

• 模块过多，为了能够在后台隔离运营之间填写数据的权限，模块必须做细粒度的拆分，如下图所示：
  
  一个简单的模块必须拆分成多个行业小模块，页面中其他位置也是如此，而且这些被拆分出来的模块还不一定会展现出来，需要让算法告诉前端展示哪些模块。

• 图片过多，翻页往下滚动，很明显看到，页面整屏整屏的图片，有些图片是运营填写，有些图片由个性化接口提供，这些图片都没有固定的尺寸。

网页性能衡量指标

网页性能衡量指标有很多，倘若能够把握关键的几个，集中优化，性能自然也就上去了。

FPS

最能反映页面性能的一个指标是 FPS（frame per second），一般系统设定屏幕的刷新率为 60fps，当页面元素动画、滚动或者渐变时绘制速率小于 60，就会不流畅，小于 24 就会卡顿，小于 12 基本认定卡爆了。

1 帧的时长约 16ms，除去系统上下文切换开销，每一帧中只留给我们 10ms 左右的程序处理时间，如果一段脚本的处理时间超过 10ms，那么这一帧就可以被认定为丢失，如果处理时间超过 26ms，可以认定连续两帧丢失，依次类推。我们不能容忍页面中多次出现连续丢失五六帧的情况，也就是说必须想办法分拆执行时间超过 80ms 的代码程序，这个工作并不轻松。

页面在刚开始载入的时候，需要初始化很多程序，也可能有大量耗时的 DOM 操作，所以前 1s 的必要操作会导致帧率很低，我们可以忽略。当然，这是对 PC 而言，Mobile 内容少，无论是 DOM 还是 JS 脚本量都远小于 PC，1s 可能就有点长了。

DOMContentLoaded 和 Load

DOM 加载并且解析完成才会触发 DOMContentLoaded 事件，倘若源码输出的内容过多，客户端解析 DOM 的时间也会响应加长，不要小看这里的解析时间，如果 DOM 数量增加 2000 个并且嵌套层级较深，解析时间也会相应增加 50-200ms，这个消耗对大多数页面来说其实是没必要的，保证首屏输出即可，后续的内容只保留钩子，利用 JS 动态渲染。

Load 时间可以用来衡量首屏加载中，客户端接受的信息总量，如果在首屏中充满了大尺寸图片或者客户端与后端建立连接次数较多，Load 时间也会相应被拖长。

流畅度

流畅度是对 FPS 的视觉反馈，FPS 值越高，视觉呈现越流畅。为了保障页面的加载速度，很多内容不会在页面打开的时候全部加载到客户端。这里提到的流畅度是等待过程中的视觉缓冲，如下方是 Google Plus 页面的一个效果图：

墙内访问 google 的速度不是很快，上面元素中的的很多内容都是通过异步方式加载，而从上图可以看出 Google 并没有让用户产生等待的焦虑感。

淘宝首页的性能优化

由于平台限制，淘宝首页面临一个先天的性能缺陷，首屏的渲染需要从 7 个不同的后端取数据，这些数据请求是难以合并的，如果用户屏幕比较大，则首屏的面积也比较大，对应的后端平台数据接口就更多。数据是个性化内容或者为广告内容，故请求也不能缓存。

关键模块优先

不论用户首屏的面积有多大，保证关键模块优先加载。下面代码片段是初始化所有模块的核心部分：