<img
v-lazy=“‘img.400px.jpg’”
srcset=“img.400px.jpg 400w, img.800px.jpg 800w, img.1200px.jpg 1200w”
/>
<img
v-lazy=“imgUrl”
:srcset=“imgUrl’ + ‘?size=400 400w, ’ + imgUrl + ’ ?size=800 800w, ’ + imgUrl +’/1200.jpg 1200w’”
/>
（滑动可查看）
（2）图片压缩
在移动端环境下，图片加载一直是需要重点优化的关键项，所以才延伸出懒加载这种交互方案来提高用户体验。
当该方案优化到了落地后，我们下一步考虑如何在保证图片质量的前提下，尽量压缩图片体积，提升图片加载效率。
WebP 是 Google 推出的一种同时提供了有损压缩与无损压缩（可逆压缩）的图片文件格式。相比于其他相同大小不同格式的压缩图像，WebP 格式的图片拥有更小的体积以及更高的质量，所以它的优势十分明显。
WebP 是 Google 推出的一种同时提供了有损压缩与无损压缩（可逆压缩）的图片文件格式。相比于其他相同大小不同格式的压缩图像，WebP 格式的图片拥有更小的体积以及更高的质量，所以它的优势十分明显。
在使用 WebP 进行有损压缩后，我们大概可以将原本的图片大小压缩至原来的十分之一左右，而图片质量却没有大的损失。这确实是一个惊人的效率。
我们可以看下一组数据来看下 webp 有损压缩效果：
Webp 有损压缩（75%质量比）
await execFileSync(cwebp, [‘-q’, ‘75’, filePath, ‘-o’, webpPath]);
（滑动可查看）
原大小 | 压缩时间(ms) | 压缩后大小 |
999kb | 237 | 38kb |
999kb | 221 | 38kb |
999kb | 228 | 38kb |
999kb | 228 | 38kb |
999kb | 261 | 38kb |
在转换结束后，悟空会将原图片和转换后的 webp 图片都上传到 cdn 上，做一个备份的能力，实际业务场景可以根据需求去选择是否使用 Webp 图片。
下图展示 Webp 压缩前后效果，右侧展示压缩后图片，图片大小从215k减小至17k。
悟空在使用 Webp 压缩时，也遇到种种问题，如下：
-
为什么悟空选择 75% 的压缩质量？
-
什么特征的图片不适合Webp压缩？
-
部分图片压缩后资源变大
后续文章《悟空活动中台 - 基于Webp的图片高效加载方案》会详细叙述悟空如何从平台角度提供 Webp压缩方案。
（3）跨域避免 option 请求
悟空H5专题采用的是前后端分离方案，服务器域名和专题域名不一致，会受到浏览器同源策略影响。
我们发现数据主接口会发起两次，其中第一个请求为预检请求。
一般来说使用 application/json 的 post 请求是必然会带入 OPTION 请求，何为 OPTION 预检：
用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。
在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法；Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。
有趣的是专题详情为 GET 接口，为何 GET 请求也会发起 option 预检？
这个原因得从简单请求和复杂请求说起，跨域请求分为简单和复杂两种：
简单请求:
请求方式为如下之一：
HEAD
GET
POST
HTTP 请求头只能包含如下信息：
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type，但仅能是下列之一
application/x-www-form-urlencoded
multipart/form-data
text/plain
任何一个不满足上述要求的请求，即被认为是复杂请求。一个复杂请求不仅有包含通信内容的请求，同时也包含预检信息。
专题配置接口请求头中带有自定义 header，浏览器会认定为非简单请求，需要向服务器发出检查，判断该域名是否允许跨域。
经过分析发现，自定义 header 其实在此业务场景中非必传自带，发出预检请求至少会有 100ms 的耗时，无形中延长页面绘制时间。
最终解决方案：去除自定义header，修改为简单请求，避免该请求发出预检。
3、渲染执行优化
在网络层以及资源压缩优化落地后，接下来探索浏览器渲染执行优化点，涉及到浏览器，一定会联想到网页解析过程，下图清晰的展示静态资源如何通过浏览器最终显示：
当dom元素变化会导致浏览器重新执行渲染树生成、绘制，我们称之为重排重绘。
什么是重排？当 render tree 中的一部分(或全部)因为元素的规模尺寸，布局，隐藏等改变而需要重新构建。这就称为重排（回流）。每个页面至少需要一次回流，就是在页面第一次加载的时候。
（1）避免重排
浏览器结构示意图：
可以看到浏览器有负责解析、渲染请求内容的渲染引擎，哪些动作会导致浏览器重排：
（1）增加或删除 DOM 节点；
（2）display:none（重排并重绘）；
visibility:hidden（重绘）；
（3）移动页面中的元素；
（4）改变元素尺寸（宽、高、内外边距、边框等）；
（5）用户改变窗口大小，滚动页面等；
（6）页面初始渲染；
（7）改变元素内容（文本或图片等）。
offsetTop, offsetLeft，…
scrollTop, scrollLeft, …
clientTop, clientLeft, …
getComputedStyle() (currentStyle in IE)
（滑动可查看）
这些属性都需要实时回馈给用户的几何属性或者是布局属性，浏览器不得不立即执行渲染队列中的“待处理变化”，并随之触发重排返回正确的值。
document.body.style.minWidth = ‘12OOpx’
document.body.style.overflow = ‘hidden’
//获取某div的偏移量
document.querySelector(‘xxx’).offsetTop
（滑动可查看）
我们优化活动代码执行逻辑，将上述直接操作 dom 的操作修改为 class 样式操作，减少加载过程中重复的dom操作。
（2）善用 Vue 生命周期
善用 Vue 组件生命周期，在合适的 hook 去初始化数据，操作dom，能够大幅提升加载体验。
在mounted 阶段，浏览器已经完成 dom 与 css 规则树的 render，并完成 render tree布局，这时候再去发送数据请求，会拉长请求时间和渲染周期，所以建议在beforeCreate中执行，以此达到预渲染和请求的并行进行。
我们将活动初始化数据的动作放在 beforeCreate 阶段，并将对 dom 的操作和监听挂载在 mounted 中。
{
beforeCreate(){
fetch({
url: topicUrl,
params: {
//…
}
}).then(res=>{
//数据处理
//…
})
},
mounted() {
// global listener
window.addEventListener(‘xxx’);
// get dom element by refs
this.$refs.xxx
// get dom element use native api
document.querySelector
}
}
（滑动可查看）
对浏览器来说，整个渲染流程尚未开始或者说准备开始，对 vue 来说，实例尚未被初始化，data observer 和 event/watcher 也还未被调用，这个时候请求页面初始化数据时机是比较成熟的。
（3）减少白屏时间
相比 Native 页面，H5 页面体验问题主要是：打开一个 H5 页面需要做一系列处理，会有一段白屏时间，体验糟糕。
白屏时间是指浏览器从响应用户输入网址地址，到浏览器开始显示内容的时间。
本次专题优化，我们采用如下方式去减少白屏时间：
-
骨架屏，html直接渲染过渡效果
-
改造第三方 JS 引入顺序
-
使用 SplitChunksPlugin 拆分公共代码；
-
使用动态 import，切分页面代码，减小首屏 JS 体积
其中改造骨架的方式是一种成本低，效果非常卓越的方式，更进阶的方式有服务端直出等。由于悟空活动专题有快，灵的特点，配置改变需实时生效，所以前期我们权衡方案利弊，采用骨架，直接渲染过渡效果的方案。
页面加载html后直接显示加载效果，在底版本andriod手机中，webwiew初始化过程会有一个高度切换过程，加载后出现Native的titleBar，导致过渡效果会产生位置移动场景。
为了解决该问题，我们使用css3动画来实现过渡效果延迟出现，避免与webview初始化冲突。
animation: loading 1s linear 300ms infinite;
···
@keyframes loading{
from {
opacity: 1;
}
to {
opacity: 1;
}
}
（滑动可查看）
这一现象能侧面反映出，loading出现基本于webview初始化同期进行，速度很快。为了解决loaidng瞬移的问题，我们采用纯css3实现loading延迟出现，不与webview初始化冲突。
三、优化成果
1、同一专题优化前后数据对比
下述表格展示同一微组件和配置的活动在整体优化前后网站整体体验评分，评分来自PageSpeed Insights。
国内活动 | 优化前 | 优化后 |
首次绘制 | 2.8s | 1.3s |
速度指数 | 4s | 3.8s |
绘制耗时 | 12s | 2.3s |
综合得分（满分 100） | 44 | 90 |
海外活动 | 优化前 | 优化后 |
首次绘制 | 3.5s | 1.3s |
速度指数 | 5.6s | 3.3s |
绘制耗时 | 3.5s | 2.8s |
综合得分（满分 100） | 67 | 92 |
2、国内活动效果
相同配置专题：
3、海外活动效果
相同配置专题：
四、性能数据收集
1、常用指标
关于指标，业界有非常多的方案和数据：
-
页面加载时长
-
首屏加载时长
-
Dom Ready 时长
-
Dom Complete 时长
-
首页渲染时长
-
首页内容渲染时长
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：前端）
学习分享，共勉
题外话，毕竟我工作多年，深知技术改革和创新的方向，Flutter作为跨平台开发技术、Flutter以其美观、快速、高效、开放等优势迅速俘获人心
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-WkOOjjJV-1710694291373)]
[外链图片转存中…(img-jcprPosw-1710694291373)]
[外链图片转存中…(img-dzmeWrTL-1710694291374)]
[外链图片转存中…(img-fwxI8eum-1710694291375)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：前端）
[外链图片转存中…(img-dQIeaSKu-1710694291375)]
学习分享，共勉
题外话，毕竟我工作多年，深知技术改革和创新的方向，Flutter作为跨平台开发技术、Flutter以其美观、快速、高效、开放等优势迅速俘获人心
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
扫一扫
353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
