秒开率破90%！交易后台渲染性能优化 ｜ 得物技术

一、前言

一直以来，体验都是得物技术部的关键词之一，对于前端开发而言，提高用户体验更是一项至关重要的工作。本文从本次交易后台性能优化实践出发，同时介绍应用整体架构和设计，希望可以给参与网站性能建设的同学提供一定的学习和参考价值。

二、系统简介

交易后台是现有交易流程主要系统，包含商品、出价、商家、订单等二级业务域，其承载了交易的核心任务，在交易平台的整体架构中占据着非常重要的地位。业务背景：整体日均 PV 数达到 10w+，其中 SPU 场景占比超过一半，由于页面功能结构复杂的原因，运营的使用体验和交易效率有一定程度上的影响。技术背景：应用基于 qiankun 微前端架构，首屏加载资源过多，包括主子应用 JS 和样式文件，图片和其他静态资源，数十个子应用路由信息和数百个菜单项，以及接入的一些三方 SDK 等。

三、性能现状

先看优化前的首屏效果（没有开慢倍速）：

可以从动图看出页面加载速度、白屏时间都不太理想，显然和我们的目标首屏秒开还有一段距离，为了实现首屏秒开的目标，可以先从以下几个方面进行分析。

性能看板分析

Chrome Performance 火焰图在页面性能问题分析中是一项非常重要的工具。

相关阅读：https://juejin.cn/post/6844904074551230471

在打开看板后，先关注下这几个红色区域长任务，我们知道主线程一次只能处理一个任务，所以这会导致浏览器在主线程上阻塞一段时间，也是造成页面卡顿的主要原因。看下底部调用树的情况：Task1： 发生在 DCL 之前，因为浏览器解析 HTML 文件时，会在遇到<script>标签时立即执行脚本文件，所以 webpack_require 和 Compile Code 很可能是因为入口文件过大导致。

Task2： 发生在 FCP 之后，主要是源码中组件渲染相关的核心函数，componentUpdateFn 用于比较新旧 VNode 的差异，并调用 patch 函数对真实 DOM 进行更新，所以初步判断是渲染复杂组件导致。

另外可以观察以下关键性能指标，了解一下页面加载的各个阶段的耗时情况

• First Contentful Paint（FCP）：首次内容绘制时间，此时页面仅展示出一些水印组件，和白屏几乎没区别，一般应该在页面加载后的 1-2s 内完成，此时用户可以感受到页面正在加载。（当前耗时2s+）
• Largest Contentful Paint（LCP）：最大内容绘制时间，此时主应用框架渲染基本完成，子应用还未开始加载。通常应该在页面加载后的 2.5s 内完成，否则用户可能会感到页面加载缓慢。（当前耗时4s+）

根据这些具体的性能指标，之后才能更好的度量优化效果。

渲染流程分析

为了快速定位问题，我们按步骤拆分一下页面整体加载的渲染流程，这有助于我们做出针对性的优化。

我们重点关注几个标记的部分，接下来就可以根据实际情况逐一击破了。

四、方案拆解

根据对应用渲染流程的分析，我们可以将整体优化方案作进一步的拆解，并设置对应动作的开发优先级。

并通过二八法则，我们将主要精力重点投入到高优方案中，确保整体性能的提升。

五、具体动作

首屏资源优化

首屏资源加载会直接影响页面的渲染速度和体验，我们先查看下首屏资源的加载情况，由于各类资源请求过多，这里仅过滤来源于主应用的网络请求。可以直接从中发现几个可优化的点：

• 入口 JS 资源文件 Size 优化

  • 严重影响了页面整体加载性能，可以通过构建体积优化，主要思路就是代码分割拆包，静态资源上传 CDN，脚本代码压缩等方式处理

• 接口缓存、调用时序治理

  • 针对用户信息、菜单信息等不常变动的接口可以采用相关缓存策略，减少首屏等待的时间
  • 部分优先级不高的接口可以延迟调用，异步加载

  // 我们采用 Cache aside 旁路缓存策略
  async function cacheRequest(params: any) {  
      const startTime = Date.now()  
      const key = params.key  
      const cache: any = JSON.parse(localStorage.getItem(key) || '{}') 
      // 当天有缓存  
      const canCache = cache.cacheTime&&moment(cache.cacheTime).isSame(moment(startTime), 'day')
      
      window.sendTrack?.({    
  event: 'main_request_cache',    
  tags: {      
   eventTitle: '主应用数据缓存',      
   eventType: canCache ? 1 : 0,    
      },  
    })
      
    const requestCache = async () => {    
      const data = await request(params)    
      localStorage.setItem(key, JSON.stringify({      
    data,      
    cacheTime: Date.now()    
  }))    
  return data  
    }  
    // 优先从缓存中读取数据 后续再更新缓存 保证数据的一致性  
    if (canCache) {    
      setTimeout(requestCache, DELAY_CACHE_TIME * 1000)    
      return cache.data  
    } else {    
      const data = await requestCache()    
      return data  
    }
  }

• 三方 SDK 集中治理

  • 尽量放在 script 标签中异步加载脚本，可以加快解析时间且保证主入口文件的加载不会被阻塞
  • 另外注意防止子应用重复加载，还有部分 SDK 需要及时下线

其实原则只有一个：减少首屏需要加载的资源数量和大小，并尽快加载必要的资源。

渲染优先级优化

最后为了减少 LCP 的等待时间，我们将页面左侧菜单栏做一个懒加载处理，初始化仅展示一级目录菜单，既考虑了首屏视觉效果，也间接将子应用加载的时间点提前。

相关阅读：当不希望因为不重要的任务导致用户感觉到卡顿的话，就应该考虑使用requestIdleCallback：https://juejin.cn/post/6844903592831238157

// 采用 requestIdleCallback 方式利用 CPU 空闲时间渐进地加载内容
try {    
    requestIdleCallback((deadline) => {        
        // 当前帧有剩余时间 可以执行任务        
        while (deadline.timeRemaining() > 0 && || deadline.didTimeout) {            
           // 加载剩余部分菜单项        
        }    
    })  
  } catch (e) {    
    // 低版本浏览器兜底处理    
    setTimeout(() => {      
     // 加载剩余部分菜单项    
    }, DELAY_LOAD_TIME) 
  }
}

最后再看下优化后的首屏效果（没有开快倍速）：

六、效果回收

主要性能指标

优化后各项指标数据均有一定提升，其中

秒开率（首次打开页面<1秒占比，以 FMP 为准）：🔝15%+

页面首次进入FMP90分位均值（秒）：🔝35%+

页面TTI%(可交互时长<1.5s占比) ：🔝30%+

TTI 90分位均值（秒）：🔝50%+

上述数据均来源于效率工程应用系统前端大盘看板。

优化前-7月

优化后-9月
其他相关数据统计（本机测试）：页面传输资源大小减少约 1M、页面资源加载时间下降超过 0.5s、FCP、LCP 也分别优化到 1s、2s 以内 ，整体结果超出预期。

七、总结展望

随着业务复杂度提升和用户规模的增加，系统的性能和效率必然会面临更多的挑战，本轮性能优化工作基本告一段落，虽然取得了一些成绩，但还有很多事项需要后续不断的完善，比如：

1. 框架层面优化。深入探究微前端框架层的性能瓶颈，降低应用间消息传递通信和模块重复资源加载损耗
2. 使用 Service Worker。执行一些计算密集型或网络请求相关的任务，实现静态资源缓存优化
3. 资源加载优化。利用发布平台事件同步能力实现应用配置文件按需加载，避免网络带宽造成过大的压力

希望能通过各项措施逐步形成后台应用性能优化最佳实践，从而避免各种性能卡点问题，进一步保证运营体验。

*文/ Johnny

本文属得物技术原创，更多精彩文章请看：得物技术官网

未经得物技术许可严禁转载，否则依法追究法律责任！