一个新的C端项目的前置思考

前言

c端项目通常页面花样比较多，PM同学可能想要一些在我们实现起来比较不同常规思路的功能，如果我们急于上线功能，后面很有可能我们自己或者PM同学会对性能的关注点越来越高，如果我们可以前置考虑到一些点就会让后面的工作更高效便捷

话不多说进入正题

数据看板

试想这样一个场景，当页面上线后，当你有了想法想要去优化某个指标例如TTI，这个时候如果直接上手去做优化，即便是后面你说自己优化了却无数据支持是不是很尴尬，那在项目初期就可以考虑建一个数据看板，为后期的优化提供数据支持；一般比较通用的指标pv、uv、FCP、FMP、TTI，通常我们可以从以下几个方面去思考：

• 优先考虑公司的基建是否可以提供这些能力
• 如果这些都不能实现，自定义去上报一些可能用到的数据，通过写sql自己去计算得到也是个不错的选择呢

包体积

试想这样一个场景，当页面上线之后突然观察到现在初始化的时间比较长，但是后期又发现是引入的某个依赖包比如说sdk包体积很大，依赖方可能会说升级按道理没问题但是还是要测一下，这个时候我们就需要再去协调qa同学回归功能，所以前期依赖包引入调研可以充足一些。我们可以从以下这些方面入手：

• 观察一下目前引入的包最新的版本是多少，包内部是否有使用tree-shaking
• 观察一下哪些是包是可以进行替换的，比如在时间转化上使用了moment但又没有使用其它复杂的功能，这个我们可以考虑用自己写一个方法替代或者dayjs这种较小体积的包替换

这件事情一般我们会通过工具去辅助查看

• 本地开发 - vscode插件import-cost
• 如果是webpack脚手架相关，可以用webpack的包分析
• 如果是端内的一些框架通常会有对应的工具来使用

图片是否过大

从过往的C端项目的失效效果来看，图片对加载的影响比较大，往往图片较多的页面优化一波图片肯定可以得到不错的效果，那这样我们可以在前期就可以考虑这件事情：

• 前端本地的图片可以提前进行压缩 - 压缩工具
• 可以调研公司是否有对应的图片压缩服务，这样我们还可以针对接口返回的图片在渲染之前加一层压缩

是否需要用到动态降级

C段页面经常会想要通过一下动态的视频来实现一些比较酷炫的效果，尤其是移动端在使用这些视频或者lottie的时候，可能在不同的机型带来的效果不一致，那么我们可以提前考虑是不是可以做一下动态降级

• 如果规则变动不会频繁，按照一个规则在前端代码定义中高端机型
• 变动比较多，可以和服务端一起维护一个规则
• 如果端内调用一下端上是否可以通过现成的接口调用得到

接口常规的优化手段提前和服务端同学沟通

当我们的初始化请求比较多的时候，我们需要多关注一下是否包含串行接口导致渲染的影响，那么这个时候我们可以有两个思路去将它进行优化避免后面因为渲染问题二次开发

• 首屏接口过多且需要串行 - 这个时候我们就可以和服务端同学一起想个优化的方案，比如服务端同学可以新增一个包装型接口将两个串行封装为一个接口，相比于前端的串行，首屏时间就可以优化不少
• 接口预请求 - 这个方面属于前端本身可以进行完成的，调研一下是否可以让接口更早的发出请求

接口耗时埋点

首屏的接口耗时在后期优化的过程中也是一个关键的时间节点，通常这个数据是由我们前端代码内写入方法完成；如果项目内无法拿到准确的页面耗时，这个时候接口耗时也是一个很好的时间参考点

最后

希望自己的经验可以给大家带来帮助，如果有哪些需要补充的，欢迎交流。