某官网前端项目优化与执行方案
一、项目介绍
| 此文档规划以季度、年度为时间维度的中长期项目 |
|---|
项目背景
成员列表与项目群组
| 核心成员 | 负责事项 |
|---|---|
| @R | 问题梳理、整理方案 |
| @Sky | 协调实施、组织协作 |
背景资料
| 线上浏览官网始终存在严重的性能问题，且测试报告中多次提出因性能造成的体验问题，故开启持续的项目优化计划。 |
|---|
二、项目目标
| 计划通过运行时和加载时两个层面进行处理，通过指明各部分策略来围绕这两层面进行提升。 |
|---|
| 目标一：提升前端体验及响应速度基于官网项目类型着重优化图片资源的处理通过合理分发策略提升CDN作用逐步达到"0"前端本地图片资源的目标提升按需加载和代码分割的效果错误捕获，避免运行时错误提升SSR能力合理使用规则，避免过度优化 | 目标二：提升开发效率持续完善前端开发规范引用资源有源头可维护增加样式隔离方案提升webpack构建速度Global项目的多语言开发方案替换 |
|---|
三、月度里程碑
💡 里程碑在项目管理过程中的定义为一个状态点，代表在此时间点能够达到此状态。计划将项目关键节点需要完成的事项设为里程碑，并在此看板中追踪完成状态
点击图片可查看完整表格
四、项目例会
例会 1：2022/10/19
会议记录
Icon类小尺寸图标优化
大尺寸图片资源优化
Html中脚本内容阻塞问题
缩减 JavaScript
冗余代码及资源剔除
梳理统一开发规范
TODO
行动方案
| Icon类小尺寸图标优化 |
|---|
描述：目前存在同一图标，在项目中重复导入的问题，增加了体积与消耗。
方案：将项目中小于10kb资源编译为base64格式的内联资源，并且使用coDesign上传图标集合，图标有来源有备份，更便于开发在项目中的管理，后期考虑引用coDesign提供的图标字体CDN链接，以减少请求本地图片资源的消耗。
图标整理上传；@李英章
inline内联图片编译；@R
| 大尺寸图片资源优化 |
|---|
描述：首页存在部分较大尺寸的静态图片，在访问时会增大网络负载，并且延长页面加载用时。项目编译时，会将引用的图片导出到对应文件夹中，所以部署产物时，图片资源存在相同的两份，对开发效率也是大的消耗。
方案：期望利用oss提供高效的缓存策略来进行大尺寸图片资源的访问，并计划在流程上也进行一定调整。在UI交付时，将导出好的内容上传到oss指定目录中，并在Figma中标注对应url供开发使用。前端项目中集中管理图片的使用，预备出服务商替换的处理，并且根据客户端支持的最优格式提供图片展示。以此在流程上，解放出开发人员处理图片的工作，并且能够通过oss重名覆盖，达到快速响应业务中图片变化的解决效率，落地页等开始实施将会有更显著的效果。
oss部分的启动；@Sky
配合UI推动并整理一定的规则；@R
实施操作，集中管理交付物料；@L
| Html中脚本内容阻塞问题 |
|---|
描述：Html中引用了较多的js脚本，会造成加载阻塞，并且存在部分应舍弃的脚本。
方案：移除非必要且阻塞渲染的资源，对脚本的加载时机进行调整，以提升首屏加载速度。
入口Html内容优化；@R
| 缩减 JavaScript |
|---|
描述：如题
方案：减少未使用的 JavaScript，并按需加载脚本，以减少网络活动耗用的字节数。并且缩减 JavaScript 文件大小，则既能缩减负载规模，又能缩短脚本解析用时。
编译处理；@R
| 冗余代码及资源剔除 |
|---|
描述：历史原因存在大量不再使用的内容与资源。
方案：本次会议中已完成初步的筛选和调整，待完整剔除。
项目整理；@R
| 梳理统一开发规范 |
|---|
描述：缺少团队的开发规范。
方案：已在会议中同步，后续补充Readme。
Readme梳理；@R
| TODO |
|---|
项目中增加代码检查和类型检查，不允许忽略；
多语言方案更改，逐步替换旧方案；
五、项目物料汇总
点击图片可查看完整电子表格
六、协同解决问题及方案
1.首页弹窗交互
首页三个弹窗影响TTI数值，在灰度关闭弹窗测试结果如下，分数稳定在60分左右：
方案：将弹窗移除，通过页面展示增加关闭按钮，不将动态内容作为首屏最大内容，分数增幅在5～10分左右。
2.运营图片尺寸
提示： 请不要通过 height 和 width 属性来缩放图像。如果通过 height 和 width 属性来缩小图像，那么用户就必须下载大容量的图像（即使图像在页面上看上去很小）。正确的做法是，在网页上使用图像之前，应该通过软件把图像处理为合适的尺寸。
方案：针对上述提示，建议采取a.运营控制上传内容，b.TOS上传时，根据UI图比例，增加裁剪等功能，不造成图片资源请求浪费。
七、速度计分提升
关于PageSpeed
模拟 Moto G4 with Lighthouse 9.6.6
CPU/内存能力: 937
CPU 节流: 4x slowdown (Simulated)
Axe 版本: 4.4.1
网络低速 4G 节流: 150 ms TCP RTT, 1,638.4 Kbps throughput (Simulated)
浏览器位置：亚洲
用户代理（网络）: "Mozilla/5.0 (Linux; Android 7.0; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4695.0 Mobile Safari/537.36 Chrome-Lighthouse"
单次网页加载：此数据是取自单次网页加载，现场数据则是汇总了许多次网页加载。
记分板记录
完整情况得分：18
去除[客服/弹窗/GTA]得分：27
优化后分数：42
优化后去除[客服]分数：55
结果对比
FCP [ 6720ms -> 3136ms ] -3584毫秒 +4分
优化范围
调整广告弹窗，在touch事件触发且图片加载完成后弹出
调整客服加载方式
调整多个JS文件的主线程阻塞问题
SI [ 8995ms -> 3595ms ] -5400毫秒 +6分
LCP [ 13353ms -> 3136ms ] -10217毫秒 +10分
最大内容绘画（LCP）度量标准报告视口内可见的最大图像或文本块的渲染时间。
网站应努力在页面开始加载的前2.5秒钟内出现"LCP"，其考虑的元素为：
| XML元素 元素内的元素 元素（使用海报图像） // 通过url（）函数加载背景图片的元素，包含文本节点或其他内联级文本元素子级的块级元素。 |
|---|
优化范围
头图预加载，尺寸调整375 × 236 px，压缩至26.5 kB（可对比fazwaz的实现方式）
TTI [ 15288ms -> 7581ms ] -7707毫秒 +8分
关键图片资源内联
优化范围
vr动态图内联加载，减少SSL验证时间
menu中图片内联
首屏及next屏以外的图片延迟加载
TBT [ 2979ms -> 801ms ] -2178毫秒 +10分
webpack对 lodash antdMobile 两个大型依赖进行按需编译。
增加LazyComponent懒加载公共组件。
commonJS体积「202kB -> 47.7kB」，main体积「83kB -> 71kB」，vendors体积「206kB -> 89kB」
优化范围
首页搜索弹窗分割
菜单弹窗分割，涉及全部H5页
编译产出.gz文件，涉及全部H5页
Common OSS摘除，涉及全部图片操作（预览，上传，下载等）
CLS[ 保持满分 ] +0分
优化范围
移动设备自适应方案，涉及全部H5页
首页增加骨架屏以减少动态展示内容的布局偏移
其他说明
在使用Chrome浏览器中Lighthouse检测时，能取得较高分数。
Lighthouse 应用网络节流来模拟 ~85% 的移动连接速度，即使在更快的光纤连接上运行也是如此。
Lighthouse默认使用的 模拟节流基于在初始未节流加载中观察到的数据，使用页面加载模拟。
移动节流的标准：
延迟：150 毫秒
吞吐量：下行 1.6Mbps/上行 750Kbps
丢包：无
iPhone SE
MOTO G4 & Low 4G