通天塔前端性能优化实践

目标提升前端和Node中间层性能

通天塔是京东内部的一个快速搭建活动页面的平台，用户可以通过在可视化平台上选择需要的模板及配置对应数据，来生成对应的原生、H5及PC活动页面。模板样式丰富，操作灵活，在京东被大量使用，用户流量也呈现出了非常迅猛的增长。但随着项目的迭代，功能越来越复杂，模板越来越多，前端和Node中间层性能问题也逐渐暴露出来，其中，前端首屏加载时间TP75性能要大于2秒，而Node中间层单核QPS相较其他应用也较低。为了提升用户体验，同时提高系统的吞吐率，在2019年下半年我们通过对现有通天塔H5项目进行一次全盘分析，做了一次全方位的性能优化。

综合性能提升超过30%

通天塔H5是以React SSR为基础进行架构的，首屏页面在Node中间层进行数据请求及渲染，分页和其他异步请求在客户端请求网关接口并渲染，静态资源托管在CDN，如图1所示。

图1：通天塔H5请求流程

基于以上架构，经过2019年下半年的优化，通天塔H5前端首屏加载性能和Node中间层渲染性能都得到了极大提升。

1

首屏加载性能

首屏加载耗时，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)。

2

服务器性能

通过对服务器进行压测，在相同QPS维度下，CPU从原来的29.52%降低至20.5%，CPU使用率相比之前降低了30.5%

图3：同QPS下CPU利用率

线上性能分析

在进行优化前，需要先采集当前线上数据，了解服务目前的性能情况，我们主要通过以下方式对项目的性能进行分析及监控。

1

Performance API

Performance API是ECMAScript5才引入的，精度可达到1毫秒的千分之一，目前主流浏览器基本都已经支持performance对象。通过performance.timing对象，可以拿到浏览器处理网页各个阶段的耗时。通过performance.getEntries方法，可以获取js, css, 图片及ajax在内的所有请求的耗时信息。

我们基于Performance API，封装了一个前端测速模块，该模块在页面加载完成后将所需性能数据上报至服务器，之后可以在可视化平台上进行数据的展示及分析。

2

Chrome Devtools

Chrome Devtools是前端调试及性能分析常用的工具，通过该工具，可以查看页面资源加载情况，所加载CSS、JS及图片的大小，还可以通过Performance面板，查看页面渲染绘制和Script执行情况。

3

v8-profiler

通天塔H5是基于React SSR架构的，页面首屏在Node中间层请求数据并渲染，所以除纯前端的监控及分析，还需对Node层进行性能分析及优化。在Node层性能分析中，我们主要通过v8-profiler模块进行性能分析。

在本地或测试环境下新增两个路由:

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 http://localhost:7001/mall/active/xxx/index.html

在压测过程中，可以通过http://localhost:7001/profiler/start开始性能统计，通过http://localhost:7001/profiler/end结束性能统计，并将结果保存为 ***.cpuprofile文件，通过Chrome Devtools中的JavaScript Profiler工具进行分析。

图4：Node服务端代码执行情况

常规优化+业务特性优化

我们主要从两个方面进行性能优化，一方面是基于较为通用的前端常规性能优化方案，另一方面基于通天塔业务特点进行的偏业务方面的优化。

1

前端常规优化

在优化之初，根据《高性能网站建设指南》提及的常规优化方案，我们检查了项目中需要改进或深度优化的地方，主要涉及以下方面：

• 尽可能的减少HTTP的请求数，减小HTTP请求大小

• 将静态资源放在CDN，最大化利用CDN缓存能力

• 减少CSS和JS请求个数，减小CSS和JS包大小

• 启用gzip压缩

1 ）减少图片请求大小

在通天塔页面中，图片请求一般占比最大，在前期开发过程中，针对图片请求我们已做过懒加载优化，图片请求数很难更进一步减少，但针对图片大小，我们可以进行优化。

图5：图片展示尺寸及实际尺寸

如图5，在页面中图片实际所展示坑位大小为115x115，即使在3倍屏上，所需图片尺寸也只是345x345，但实际请求中，图片的原始尺寸却是800x800，这对用户流量是一种浪费，同时也增加了图片加载耗时，而通天塔活动页中，这种类似的图片还有很多，而同时，京东图片服务器正好支持图片的裁剪，原来一张800x800的图片，可以按比例缩小到所需的高度，如一张800x800的原图 https://m.360buyimg.com/babel/jfs/t1/85209/24/15512/218570/5e7179d8E957c16c1/5fbcc42fad37fe94.jpg!q70.dpg ，通过修改URL，可以改成下发230x230尺寸的图 https://m.360buyimg.com/babel/s230x230_jfs/t1/85209/24/15512/218570/5e7179d8E957c16c1/5fbcc42fad37fe94.jpg!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 缓存

在做性能优化前，通天塔静态资源的打包，是开发者在上线前，在自己电脑上进行的，且文件名会依据文件内容重新生成，格式为[filename].[contenthash:8].js。

按这种方式在个人电脑上打包，即使有package-lock.json锁定包版本，但由于个人电脑操作系统及使用的npm包管理 工具 的不同(有的包管理工具不读package-lock.json)，node_module下的文件可能会不一致，导致文件的contenthash不同。

针对这个问题，我们基于Jenkins搭建了一个前端CI打包系统，后继所有上线前的前端静态资源打包，都迁移到CI上进行，通过这种方式，确保了文件名的一致性，以最大程度的利用CDN缓存。

3 ）调整 webpack 打包策略，按需加载 CSS 和 JS

在性能优化前，通天塔的CSS和JS资源是按以下策略打包的:

• vendor.[contenthash:8].js: 包含node_module下的代码

• common.[contenthash:8].js: 包含非node_modules下的代码

• [channel].[contenthash:8].js: 通天塔有很多渠道，每个渠道的专属代码打包到这个JS中

• template.[contenthash:8].css: 包含所有渠道通用CSS

• [channel].[contenthash:8].css: 包含渠道专有CSS

按这种方式来进行打包，有以下两个问题，

1. 每个活动会加载所有模板对应的CSS和JS，造成不必要的加载。

2. 所有的系统模板代码都打包到common包，导致common包非常庞大，而其中有任何一个模板代码有改动，都会影响到common包的文件名，从而导致CDN缓存失效，客户端必须重新请求CDN。

针对两个问题，我们改进了打包策略，最终方案改为:

• vendor.[contenthash:8].js: 包含node_module下的JS文件

• lowUsedTemp.[contenthash:8].js: 包含使用频率低的系统模板代码，页面会按照活动是否使用到低频模板按需请求

• mute.[contenthash:8].js: 包含剔除低频使用模板后，较为稳定，很少改动的系统模板

• template.[contenthash:8].js: 包含剩余非node_modules下的代码

• [channel].[contenthash:8].js: 包含渠道专属代码

• lowUsedTemp.[contenthash:8].css: 包含使用频率低的系统模板代码的CSS，页面会按照活动是否使用到低频模板按需请求

• template.[contenthash:8].css: 包含所有渠道通用CSS

• [channel].[contenthash:8].css: 包含渠道专有CSS

按照这种方式打包，只有使用到低频使用模板的活动，才会加载lowUsedTemp.[contenthash:8].css和lowUsedTemp.[contenthash:8].js，其中按需加载的CSS占总CSS大小的25%，按需加载的JS占总大小的17%。而单独打包出的mute.[contenthash:8].js这个JS资源，由于里面包含的模板很少被改动，所以在打包上线时，其文件名也很少会变，这就可以利用CDN缓存，不会每次上线后，用户都重新请求这部分代码。

2

业务优化

在常规的前端性能优化达到瓶颈后，我们开始尝试基于业务进行性能优化。

1 ）首屏精准化优化

通天塔页面是运营在可视化配置平台中，通过选择模板，配置数据来动态生成的，而其中类似商品楼层这种素材楼层，配置的素材数量也由运营自己决定，少的可能只有几个，多的几十上百个，这便导致通天塔首屏页面有以下特点

1. 页面灵活多变，页面结构难以预测。

2. 在请求首屏楼层数据时，服务端难以计算需要下发几个楼层刚好满首屏，故按照素材楼层数来进行分页，如果首页素材楼层配置的素材较多，节点数会非常庞大。

由于以上两个特点，导致很多活动页首屏的内容，远大于客户端首屏实际所需展示的长度，这既加大了首屏的渲染耗时，同时也浪费了Node服务器的CPU资源(渲染了不必要的楼层)。

另外，在通过v8-profiler测试Node服务器性能时，我们发现Node服务器端开销最大的地方有三处

• 通过JSON.parse解析后端下发的活动数据

• React.renderToString 进行首屏渲染

• JSON.stringify将首屏数据序列化后跟随HTML下发给客户端

综合考虑各种优化方式，最终决定采用在Node层计算每个楼层高度，按首屏高度渲染楼层数的方案。

图6：首屏精准渲染流程

1. 用户向Node中间层发起请求的时候，客户端会向cookie中埋入设备宽高信息。

2. Node中间层从cookie中获取设备宽高信息，若获取失败，则使用默认值。

3. 循环计算每个楼层的高度，如果楼层累计高度超过2倍设备高度，丢弃后面的楼层数据，并重置分页信息。

4. Node中间层根据计算过后的数据，渲染首页楼层，并将数据序列化后随HTNL下发到客户端。

5. 前端检测页面是否满两屏，若没满两屏，立即请求下一页数据。

在楼层维度的分页优化完毕后，还可以精益求精，针对素材楼层进行楼层内素材的优化，如果首页最后一个素材楼层中有素材超过两屏，还可以将超过两屏的素材降级到客户端来渲染。

上面结论中所提到的服务端性能优化，主要就是通过首屏精准化优化实现的。

2 ）首屏图片预加载

由于通天塔页面的灵活性，开发者并不知道哪些楼层元素会出现在首屏，所以页面中所有的图片资源，统一设置为懒加载模式。而基于通天塔H5 SSR的架构，首页在服务端渲染完成后下发给前端，前端只有在加载完JS后判断图片是否在首屏，在首屏的才开始加载图片，这就会造成图片必须要在JS加载执行完成后才进行加载，图片坑位的白屏时间较长。

基于以上图片加载滞后的问题，前期我们做了第一个优化是，在第一屏楼层之后插入一段内联JS，获取页面已加载的图片元素，如果在首屏则先将首屏图片的data-src置为src进行加载，但发现以下问题，下面是一个测试Demo。

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
  <img data-src="/img-size.png" id="test" />
  <h1>我是测试代码</h1>
  <script>
    (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');
    })();
</script>
  <h1>我是测试代码22222</h1>
  <img src="/performance-cpu.jpg" />
  <script src="/test.js"></script>
</body>
</html>

其中test.js中很简单

console.log('start');
var start = Date.now();
for(;;) {
    if (Date.now() - start > 2000) {
        break;
    }
}
console.log('end');

图7：Demo页加载执行

从图中可以看出这个图片依然在JS执行完毕后才加载。但我们发现performance-cpu.jpg这张图片，由于浏览器对图片资源预加载的缘故，没被JS阻塞，基于浏览器对图片的预加载，及上面做的首屏精准化渲染，我们又进行了一个优化：在计算首屏楼层高度时，给处于首屏的部分图片元素打标，根据这个标识在render渲染时，对打标的图片不进行懒加载处理，而直接用src，通过这个优化，图片将不被JS阻塞，提前了首屏图片开始加载的时机，减少了图片坑位的白屏时间。

3 ）交互优化

在通天塔活动中，有许多包含多Tab的模板，如商品类模板，在之前的开发中，每次切换Tab我们都是销毁之前Tab下的内容，重新渲染新Tab下的内容，这样在重新切换回去的时候，还是需要重新渲染，造成页面的卡顿。基于此，我们将Tab渲染改成了增量渲染，这样在切回上一个Tab的时候，白屏及渲染时间会大大减少。

优化是持续性工作

在通天塔H5前端性能优化的过程中，很大一部分是站在巨人的肩膀上进行的，但光这些远远不够，当纯技术优化到一定程度后，更需要根据自己的业务特点，从业务层面进行优化，这个优化的效果可能更好。

通天塔前端的优化在此告一段落，但优化之路还远未结束，后续我们还会更进一步，基于自身的业务以及一些新技术，继续深入优化，同时也希望本文能给前端及后台开发人员带来一些新的想法。