1 问题定位
1.1 背景介绍
一方面通过减少页面【加载时长】,提升【用户体验】支撑部门月度【部门目标】:xxxx转换率;
努力达成上级下达的季度目标:2s(保底)、1.8s(达标)、1.2s(挑战);
| 测试地址 | 测试报告 |
|---|---|
| 你的网站链接 xxx | 在此处生成测试报告www.webpagetest.org |
1.2 关注指标
1.2.1 核心指标
我们采用 Google 核心网页指标(Web Vitals)来衡量网页的基本性能,因为网页加载时间较长会严重影响跳出率。
如果网页加载时间从 1 秒增加到 3 秒,跳出率就会提高 32%
如果网页加载时间从 1 秒增加到 6 秒,跳出率就会上升 106%
更多信息:support.google.com/webmasters/…
考虑到大多数现代网站已经不再是单纯的图文静态页面,很多功能如登录、跟踪等,都是在页面内容绘制完毕后异步引入并加载的。
鉴于完整加载全部内容(Fully Loaded),已经不再是最合理的指标,W3C 引入了 LCP 等一系列其它新的指标概念。
| 良好 | 需要改进 | 速度慢 | |
|---|---|---|---|
| LCP | <=2.5 秒 | <=4 秒 | >4 秒 |
| FID | <=100 毫秒 | <=300 毫秒 | >300 毫秒 |
| CLS | <=0.1 | <=0.25 | >0.25 |
- LCP(最大内容渲染时间/Largest Contentful Paint):从用户请求网址到在视口中渲染最大可见内容元素所需的时间。最大的元素通常是图片或视频,也可能是大型块级文本元素。此指标很重要,因为它可以告诉浏览者网址会真正加载。
- FID(首次输入延迟/First Input Delay):从用户首次与您的网页互动(点击链接、点按按钮,等等)到浏览器响应此次互动之间的用时。这种衡量方案的对象是被用户首次点击的任何互动式元素。此指标在用户需要执行操作的网页上非常重要,因为可据此判断网页进入互动状态的时间。
- CLS(积累布局偏移/Cumulative Layout Shift):CLS 会衡量在网页的整个生命周期内发生的所有意外布局偏移的得分总和。得分是零到任意正数,其中 0 表示无偏移,且数字越大,网页的布局偏移越大。此指标很重要,因为当用户尝试与网页元素互动时,如果网页元素出现偏移,这会导致糟糕的用户体验。如果您似乎找不出得分很高的原因,请尝试与该网页互动,看看这对得分有何影响。
这三个指标对应等级达标率都是 75% ,比如:网址在其 75% 的访问事件中达到 LCP 状态所用的时间。
LCP、FID、CLS 这三个指标分别代表“加载速度”(Loading/LCP)、“可交互性”(Interactivity/FID)和“视觉稳定性”(Visual Stability/CLS)三方面的用户体验。
在这三个指标中,对用户影响最大、最直观,也是我们最应优先关注的是 LCP(最大内容渲染时间) 。
1.2.2 参考指标
在已优化核心指标的基础上,可以拓展优化参考指标,以进一步提升用户体验。
- FCP(首次内容渲染时间/First Contentful Paint),浏览器首次绘制来自 DOM 的内容时间,这个内容可以是文字、图片(也包括背景图片)、非空白的 canvas 和 svg。
- TTI(可交互时间/Time to Interactive),指网页在视觉上都已渲染出了,浏览器可以响应用户的操作。
- TBT(总阻塞时间/Total Blocking Time),指阻塞用户响应(比如键盘输入、鼠标点击)的所有时间。
更多信息:zhuanlan.zhihu.com/p/332396992
1.2.3 废弃指标
已经不再被 Google 推崇的原指标,不应再作为页面性能优化的参考。
- FMP(First Meaningful Paint)
- SI(Speed Index)
1.3 实地测试
测试详情:webpagetest生成的数据地址
测试工具:WebPageTest
测试地址:你的url地址
测试区域:California, USA - EC2First Input Delay
测试带宽:光纤(下行 5M/上行 1M)
测试屏幕:1366 x 768
测试次数:9
测试时间:2021/4/26下午2:25:28
测试标签:xxx
测试说明:第四次测试的 LCP(2351ms)最接近平均值(2380.111ms),将把这次测试作为典型测试结果进行分析。
1.4 数据分析
1.4.1 页面总体评价
- 安全指标:E
- 数据应答:A
- 状态保持:A
- 文本压缩:A
- 图片压缩:A
- 静态缓存:F
- CDN:未启用
1.4.2 核心指标达成
FCP:2.002s,低于 2.5s,良好
FID:无测试数据返回
CLS:0.094, <=0.1, 良好
1.4.3 详细数据解读
第四次测试的 LCP(2351ms)最接近平均值(2380.111ms),将把这次测试作为典型测试结果进行分析。
数据地址:webpagetest生成的数据地址
1.4.3.1 全局 LCP
分析结果:
- 全局均值 2380.11ms,测试中位数2308s,置信度 95% 的偏差值为 0.111s。
- 2.0s保底
- 向 1.8s 的达标值靠近。
数据地址:xxx
1.4.3.2 瀑布图视角(Waterfall)
**数据地址:webpagetest生成的数据地址
分析结果:
一、纵向观察:- 需要进行第三方js加载优化,同时保持低请求计数和小传输大小;
- 总的资源加载量达到了168(对比WSID仅有29);
- 1000ms以上的有18个,其中埋点上报相关的js有14个,谷歌字体加载耗时2163ms,苹果支付的js文件、alicdn2个;
- 500ms—1000ms的有30个;
- 300ms以上的合计达到82个;
二、横向观察:- 考虑优化代码分割、静态资源内嵌;
- 0-2s内:两个主要 js 下载与运行时间较长(299-570ms);
- 静态资源并发请求较多;
连接视角(Connection)
分析结果:
- 5个主要域名的解析在200ms-709ms之间,包括字体、googletagmanager(埋点相关)、store域名、facebook(埋点相关)、静态资源加载网站等 -- 考虑梳理合并埋点需求,减少相关js引入、字体加载优化、优化store域名下的接口速度
- dc-static.wondershare.com 解析时间很长,超过 200ms,远高于其它域名,需要关注。
- 它同时也是主要引入资源的所在地(数量、大小),文件传输速度提升亦可改进整体加载。
- 包含多个 Google 相关域名,可考虑 dns-prefetch(除 fonts 外已异步,影响不大)。
数据地址:xxx网站数据分析地址
1.4.3.4 请求详情(Request)
(太长了,还是参考数据地址吧)
数据地址:xxx网站数据分析地址
分析结果:
- 总体请求数为 168,除第三方服务必要,其它可考虑精简,降低请求数。
- 内部请求主要来自 store(主页面与接口)、 dc-static(静态资源)。
- 外部请求以 Google 相关服务为主,(GA/GTM)基本已后置;Google Accounts 为特例,位于前置,可考虑进一步延迟。
数据地址:xxx网站数据分析地址
1.4.3.5 文件优化
First Byte Time (back-end processing): 100/100
318 ms First Byte Time
475 ms Target First Byte Time
Use persistent connections (keep alive): 100/100
Use gzip compression for transferring compressable responses: 98/100Learn More
2,788.6 KB total in compressible text, target size = 2,713.8 KB - potential savings = 74.8 KB
FAILED - (49.3 KB, compressed = 17.4 KB - savings of 32.0 KB) - analytics.webgains.io/clk.min.js
Compress Images: 100/100 Learn More
233.5 KB total in images, target size = 233.5 KB - potential savings = 0.0 KB
Use Progressive JPEGs: N/A Learn More
Leverage browser caching of static assets: 49/100
Use a CDN for all static assets: 69/100
分析结果:
- 总体文件传输优化很不错,未启用 CDN 或缓存的基本为外部资源。
- 有少量遗漏,本次可补足:主页面未启用 CDN。
- 后续可考虑将 GA/GTM 等外部资源固化到内部加 CDN 与缓存。
数据地址:www.webpagetest.org/result/2201…
1.4.3.6 文件类型
分析结果:
- 文件主体为 js,包括组件模板,相比纯 html 会带来更多运算与渲染的阻塞时间,后续有资源可考虑上 SSR。
- css占比也比较大,需要考虑优化。
数据地址:www.webpagetest.org/result/2201…
1.4.3.7
数据分析:
- 整体评分为B
- 俩张评分为C的图片可考虑压缩或 转为svg
数据地址:webspeedtest.cloudinary.com/results/220…
2 提升计划
FID 暂无数据,根据上述指标反馈CART在 CLS 、 LCP 指标均有提升空间。
2.1 LCP
2.1.1 考虑范围
根据目前 W3C 的定义(Draft Community Group Report, 26 November 2020),影响 LCP 的页面元素包含以下五种类型:
- 基本图像元素:
<img> - 内嵌在
<SVG>中的图片:<picture> - 包含使用海报的视频标签:
<video poster="#"> - 通过地址方法获取背景图片的元素:
url() - 直接包含文字节点,或包含行内(inline)文字元素子级的块级(block)元素
这些图片、文字元素的基于其实际内容的原始尺寸(intrincis size)很重要,而通过 CSS 应用的 margin、padding、border 不作为 LCP 的考量。
2.1.2 影响因素 + 优化方案
影响 LCP 的常见因素与应对指标与优化方案有以下四种:
-
服务器响应时长,指标:TTFB(Time to First Byte),方案:
- 优化服务器
- 使用 CDN
- 缓存资源
- 优先缓存(cache-first)
- 尽早进行第三方连接(
<link rel="pre-connect">、<link rel="dns-prefetch">)
-
阻塞渲染的 CSS 与 JavaScript,方案:
- CSS:整体精简与压缩、重要的行内(
<style>)、不重要的延迟加载(Coverage + Critters) - JavaScript:整体精简与压缩、延迟加载不直接使用的 js、精简不直接使用的 polyfill
- CSS:整体精简与压缩、重要的行内(
-
资源加载时间,方案:
- 优化并压缩图片
- 预加载重要资源(
<link rel="preload">) - 压缩文本文件
- 根据用户网络及设备差异传递不同资源(Adptive Serving)
- 使用
service worker缓存资源
-
客户端渲染,方案:
- 精简重要的 js
- 使用服务端渲染(SSR)
- 使用预渲染(pre-rendering)
2.1.3 方案选择
具体方案的选择需要考虑当前后端/服务器的支持、人力资源的投入与阶段性工作重心,不同事项间尽量做到解耦。
2.1.3.1 第一期(传输优化)
-
【小幅】DNS 解析:
-
确认并优化 dc-static 解析速度
-
提前解析资源引入站点(pre-connect/dns-prefetch)
-
【小幅】Service Worker 优化浏览器缓存机制(或对 first view 无效,待测)
-
【微弱】Gzip 压缩:补全遗漏的 favicon -
【微弱】CDN 缓存:store.wondershare.cn上的静态资源
-
【微弱】图片压缩:大图替换为 svg logo(可考虑通过 fill 进行颜色复用,或 base64)
-
【微弱】CSS 预加载:主要 css(preload)
-
【大幅】梳理第三方js文件,减少请求、减小传输量大小;
-
【大幅】字体加载优化
2.1.3.2 第二期(代码质量)
- 优化主要 js 代码切割,部分资源转为内嵌。
- 减少 vue 实例初始化期间的阻塞,提早渲染。
(待一期效果评估后更新)
2.2 FID
(本次不做考量)
2.3 CLS
(本次不做考量)
3 方案推进
3.1 一期方案]
3.1.1 测试部署方案(临时)
临时使用多语言德语站点部署,部署域名
前端打包生成测试用的de文件目录,
服务端通过修改nginx指向de目录下的index.html文件完成测试部署
3.1.2 事项分工
- 测试数据分析
- 提升方案确认
- 主要文档撰写
- 测试代码部署
- Service Worker 引入
- Gzip 补漏
- 主页面加入 CDN
- dc-static DNS 解析优化
- 图片压缩
- pre-connect/dns-prefetch
- preload