通天塔是京东内部的一个快速搭建活动页面的平台，用户可以通过在可视化平台上选择需要的模板及配置对应数据，来生成对应的原生、H5及PC活动页面。模板样式丰富，操作灵活，在京东被大量使用，用户流量也呈现出了非常迅猛的增长。但随着项目的迭代，功能越来越复杂，模板越来越多，前端和Node中间层性能问题也逐渐暴露出来，其中，前端首屏加载时间TP75性能要大于2秒，而Node中间层单核QPS相较其他应用也较低。为了提升用户体验，同时提高系统的吞吐率，在2019年下半年我们通过对现有通天塔H5项目进行一次全盘分析，做了一次全方位的性能优化。
综合性能提升超过30%
通天塔H5是以React SSR为基础进行架构的，首屏页面在Node中间层进行数据请求及渲染，分页和其他异步请求在客户端请求网关接口并渲染，静态资源托管在CDN，如图1所示。
图1：通天塔H5请求流程
基于以上架构，经过2019年下半年的优化，通天塔H5前端首屏加载性能和Node中间层渲染性能都得到了极大提升。
首屏加载性能
首屏加载耗时，TP75从原来的2.47秒减小到了1.58秒，性能提升约36.03%。图2所示为优化前后以周为维度的首屏TP75加载时长。
图2：首屏TP75加载时间
此处首屏加载时长，指用户打开页面到首屏第一张图片请求完成所经历的时间。横坐标代表第几周，01代表今年第一周(2020/01/06 ~ 2020/01/12)，52代表去年最后一周(2019/12/23 ~ 2019/12/29)。
服务器性能
通过对服务器进行压测，在相同QPS维度下，CPU从原来的29.52%降低至20.5%，CPU使用率相比之前降低了30.5%
图3：同QPS下CPU利用率
线上性能分析
在进行优化前，需要先采集当前线上数据，了解服务目前的性能情况，我们主要通过以下方式对项目的性能进行分析及监控。
API
API是才引入的，精度可达到1毫秒的千分之一，目前主流浏览器基本都已经支持对象。通过.对象，可以拿到浏览器处理网页各个阶段的耗时。通过.方法，可以获取js, css, 图片及ajax在内的所有请求的耗时信息。
我们基于 API，封装了一个前端测速模块，该模块在页面加载完成后将所需性能数据上报至服务器，之后可以在可视化平台上进行数据的展示及分析。
是前端调试及性能分析常用的工具，通过该工具，可以查看页面资源加载情况，所加载CSS、JS及图片的大小，还可以通过面板，查看页面渲染绘制和执行情况。
v8-
通天塔H5是基于React SSR架构的，页面首屏在Node中间层请求数据并渲染，所以除纯前端的监控及分析，还需对Node层进行性能分析及优化。在Node层性能分析中，我们主要通过v8-模块进行性能分析。
在本地或测试环境下新增两个路由:
const profiler = require('v8-profiler');
router.get('/profiler/start', (req, res) => {
//Start Profiling
profiler.startProfiling('CPU profile');
res.end('profile start');
});
router.get('profiler/end', (req, res) => {
const profile = profiler.stopProfiling()
profile.export()
.pipe(res)
.on('finish', () => {
profile.delete();
res.end();
});
});通过ab压测工具，对服务器发起请求
ab -c 10 -n 1000 :7001/mall//xxx/index.html
在压测过程中，可以通过:7001//start开始性能统计，通过:7001//end结束性能统计，并将结果保存为 ***.文件，通过 中的 工具进行分析。
图4：Node服务端代码执行情况
常规优化+业务特性优化
我们主要从两个方面进行性能优化，一方面是基于较为通用的前端常规性能优化方案，另一方面基于通天塔业务特点进行的偏业务方面的优化。
前端常规优化
在优化之初，根据《高性能网站建设指南》提及的常规优化方案，我们检查了项目中需要改进或深度优化的地方，主要涉及以下方面：
1）减少图片请求大小
在通天塔页面中，图片请求一般占比最大，在前期开发过程中，针对图片请求我们已做过懒加载优化，图片请求数很难更进一步减少，但针对图片大小，我们可以进行优化。
图5：图片展示尺寸及实际尺寸
如图5，在页面中图片实际所展示坑位大小为，即使在3倍屏上，所需图片尺寸也只是，但实际请求中，图片的原始尺寸却是，这对用户流量是一种浪费，同时也增加了图片加载耗时，而通天塔活动页中，这种类似的图片还有很多，而同时，京东图片服务器正好支持图片的裁剪，原来一张的图片，可以按比例缩小到所需的高度，如一张的原图 !q70.dpg ，通过修改URL，可以改成下发尺寸的图 !q70.dpg
鉴于此，针对图片大小，可以做按实际展示大小请求对应尺寸的图片的优化，以减小HTTP的大小。
const isJfsRegex = /360buyimg.com/.*/((s([d^_]+)x([d^_]+)_)?jfs)/i;
export function resizeImg(url, rect) {
const dpr = window.devicePixelRatio;
if (!isJpegRegExp.test(url)) {
return url;
}
const result = url.match(isJfsRegex);
if (!result) {
return url;
}
if (result[3] && result[4]) {
if (!rect || (!rect.width && !rect.height)) {
return url;
}
if (rect.width && !rect.height) {
rect.height = rect.width / result[3] * result[4];
}
if (rect.height && !rect.width) {
rect.width = rect.height / result[4] * result[3];
}
const t = 's' + Math.ceil(rect.width* dpr) + 'x' + Math.ceil(rect.height* dpr) + '_jfs';
return url.replace(result[1], t);
} else {
if (rect && rect.width && rect.height) {
return url.replace('/jfs/', `/s${Math.ceil(rect.width * dpr)}x${Math.ceil(rect.height * dpr)}_jfs/`);
}
}
return url;
}2）最大化利用CDN缓存
在做性能优化前，通天塔静态资源的打包，是开发者在上线前，在自己电脑上进行的，且文件名会依据文件内容重新生成，格式为[].[:8].js。
按这种方式在个人电脑上打包，即使有-lock.json锁定包版本，但由于个人电脑操作系统及使用的npm包管理工具的不同(有的包管理工具不读-lock.json)，下的文件可能会不一致，导致文件的不同。
针对这个问题，我们基于搭建了一个前端CI打包系统，后继所有上线前的前端静态资源打包，都迁移到CI上进行，通过这种方式，确保了文件名的一致性，以最大程度的利用CDN缓存。
3）调整打包策略，按需加载CSS和JS
在性能优化前，通天塔的CSS和JS资源是按以下策略打包的:
按这种方式来进行打包，有以下两个问题，
1. 每个活动会加载所有模板对应的CSS和JS，造成不必要的加载。
2. 所有的系统模板代码都打包到包，导致包非常庞大，而其中有任何一个模板代码有改动，都会影响到包的文件名，从而导致CDN缓存失效，客户端必须重新请求CDN。
针对两个问题，我们改进了打包策略，最终方案改为:
按照这种方式打包，只有使用到低频使用模板的活动，才会加载.[:8].css和.[:8].jsab压测，其中按需加载的CSS占总CSS大小的25%，按需加载的JS占总大小的17%。而单独打包出的mute.[:8].js这个JS资源，由于里面包含的模板很少被改动，所以在打包上线时，其文件名也很少会变，这就可以利用CDN缓存，不会每次上线后，用户都重新请求这部分代码。
业务优化
在常规的前端性能优化达到瓶颈后，我们开始尝试基于业务进行性能优化。
1）首屏精准化优化
通天塔页面是运营在可视化配置平台中，通过选择模板，配置数据来动态生成的，而其中类似商品楼层这种素材楼层，配置的素材数量也由运营自己决定，少的可能只有几个，多的几十上百个，这便导致通天塔首屏页面有以下特点
1. 页面灵活多变，页面结构难以预测。
2. 在请求首屏楼层数据时，服务端难以计算需要下发几个楼层刚好满首屏，故按照素材楼层数来进行分页，如果首页素材楼层配置的素材较多，节点数会非常庞大。
由于以上两个特点，导致很多活动页首屏的内容，远大于客户端首屏实际所需展示的长度，这既加大了首屏的渲染耗时，同时也浪费了Node服务器的CPU资源(渲染了不必要的楼层)。
另外，在通过v8-测试Node服务器性能时，我们发现Node服务器端开销最大的地方有三处
综合考虑各种优化方式，最终决定采用在Node层计算每个楼层高度，按首屏高度渲染楼层数的方案。
图6：首屏精准渲染流程
1. 用户向Node中间层发起请求的时候，客户端会向中埋入设备宽高信息。
2. Node中间层从中获取设备宽高信息，若获取失败，则使用默认值。
3. 循环计算每个楼层的高度，如果楼层累计高度超过2倍设备高度，丢弃后面的楼层数据，并重置分页信息。
4. Node中间层根据计算过后的数据ab压测，渲染首页楼层，并将数据序列化后随HTNL下发到客户端。
5. 前端检测页面是否满两屏，若没满两屏，立即请求下一页数据。
在楼层维度的分页优化完毕后，还可以精益求精，针对素材楼层进行楼层内素材的优化，如果首页最后一个素材楼层中有素材超过两屏，还可以将超过两屏的素材降级到客户端来渲染。
上面结论中所提到的服务端性能优化，主要就是通过首屏精准化优化实现的。
2）首屏图片预加载
由于通天塔页面的灵活性，开发者并不知道哪些楼层元素会出现在首屏，所以页面中所有的图片资源，统一设置为懒加载模式。而基于通天塔H5 SSR的架构，首页在服务端渲染完成后下发给前端，前端只有在加载完JS后判断图片是否在首屏，在首屏的才开始加载图片，这就会造成图片必须要在JS加载执行完成后才进行加载，图片坑位的白屏时间较长。
基于以上图片加载滞后的问题，前期我们做了第一个优化是，在第一屏楼层之后插入一段内联JS，获取页面已加载的图片元素，如果在首屏则先将首屏图片的data-src置为src进行加载，但发现以下问题，下面是一个测试Demo。
Document
我是测试代码
(function() {
var start = Date.now();
console.log('start', start)
var img = document.getElementById('test');
img.onload = function() {
console.log('end', Date.now(), Date.now() - start); // end - start > 2000ms
}
img.src = img.getAttribute('data-src');
})();
我是测试代码22222
其中test.js中很简单
console.log('start');
var start = Date.now();
for(;;) {
if (Date.now() - start > 2000) {
break;
}
}
console.log('end');图7：Demo页加载执行
从图中可以看出这个图片依然在JS执行完毕后才加载。但我们发现-cpu.jpg这张图片，由于浏览器对图片资源预加载的缘故，没被JS阻塞，基于浏览器对图片的预加载，及上面做的首屏精准化渲染，我们又进行了一个优化：在计算首屏楼层高度时，给处于首屏的部分图片元素打标，根据这个标识在渲染时，对打标的图片不进行懒加载处理，而直接用src，通过这个优化，图片将不被JS阻塞，提前了首屏图片开始加载的时机，减少了图片坑位的白屏时间。
3）交互优化
在通天塔活动中，有许多包含多Tab的模板，如商品类模板，在之前的开发中，每次切换Tab我们都是销毁之前Tab下的内容，重新渲染新Tab下的内容，这样在重新切换回去的时候，还是需要重新渲染，造成页面的卡顿。基于此，我们将Tab渲染改成了增量渲染，这样在切回上一个Tab的时候，白屏及渲染时间会大大减少。
优化是持续性工作
在通天塔H5前端性能优化的过程中，很大一部分是站在巨人的肩膀上进行的，但光这些远远不够，当纯技术优化到一定程度后，更需要根据自己的业务特点，从业务层面进行优化，这个优化的效果可能更好。
通天塔前端的优化在此告一段落，但优化之路还远未结束，后续我们还会更进一步，基于自身的业务以及一些新技术，继续深入优化，同时也希望本文能给前端及后台开发人员带来一些新的想法。