浏览器原理 38 # 加载阶段性能:使用 Audits(Lighthouse) 来优化 Web 性能2

简介: 浏览器原理 38 # 加载阶段性能:使用 Audits(Lighthouse) 来优化 Web 性能

根据性能报告优化 Web 性能


部分参考:如何使用Lighthouse性能检测工具

页面加载过程:

20210625185702174.png


FP、FCP、LCP

在渲染进程确认要渲染当前的请求后,渲染进程会创建一个空白页面,我们把创建空白页面的这个时间点称为 First Paint,简称 FP


上图中,bundle.js 是关键资源,因此需要完成加载之后,渲染进程才能执行该脚本,然后脚本会修改 DOM,引发重绘和重排等一系列操作,当页面中绘制了第一个像素时,我们把这个时间点称为 First Content Paint,简称 FCP。


接下来继续执行 JavaScript 脚本,当首屏内容完全绘制完成时,我们把这个时间点称为 Largest Content Paint,简称 LCP。


在 FCP 和 LCP 中间,还有一个 FMP(First Meaningfull Paint),这个是首次有效绘制,由于 FMP 计算复杂,而且容易出错,现在不推荐使用该指标。


接下来 JavaScript 脚本执行结束,渲染进程判断该页面的 DOM 生成完毕,于是触发 DOMContentLoad 事件。


等所有资源都加载结束之后,再触发 onload 事件。



First Paint

如果 FP 时间过久,那么直接说明了一个问题,那就是页面的 HTML 文件可能由于网络原因导致加载时间过久。


1.首次内容绘制(First Contentful Paint)

第一次内容丰富的绘画(FCP)指标衡量了从页面开始加载到页面内容的任何部分呈现在屏幕上的时间。对于该指标,"内容"指的是文本、图像(包括背景图像)、svg元素或非白色canvas元素。


20210625193401292.png


在上面的负载时间线中,FCP发生在第二帧中,就像呈现给屏幕的第一文本和图像元素时一样。

虽然部分内容已经呈现,但并非所有内容都已呈现。


这是 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP) 之间的一个重要区别:LCP的目的是衡量页面的主要内容何时完成加载。



2.首屏时间 (Speed Index)


速度指数衡量的是内容在页面加载过程中的视觉显示速度。

利用Lighthouse报告中的 "Opportunities "部分来确定哪些改进对你的页面最有价值。机会越重要,对性能评分的影响就越大。



3.最大内容绘制(Largest Contentful Paint)

最大内容画(LCP)指标报告了在视口中可见的最大图像或文本块的渲染时间,相对于页面首次开始加载的时间。


20210625194111601.png

从图上也能看出来,为了提供良好的用户体验,网站应该努力使最大内容画幅达到2.5秒或更少。

简单理解就是:


CLS测量的是整个页面生命周期内发生的每一次意外布局转变的所有单个布局转变得分的总和。

布局偏移发生在可见元素从一个渲染帧到下一个渲染帧改变其位置的任何时候。关于如何计算单个布局偏移分数,请参见下文)。



4.完全可交互时间 (Time to Interactive)

完全可交互时间 (Time to Interactive),简称 TTI,它表示页面中所有元素都达到了可交互的时长。

简单理解就这时候页面的内容已经完全显示出来了,所有的 JavaScript 事件已经注册完成,页面能够对用户的交互做出快速响应,通常满足响应速度在 50 毫秒以内。如果要解决 TTI 时间过久的问题,可以推迟执行一些和生成页面无关的 JavaScript 工作。



5.总阻塞时间(Total Blocking Time)

总阻塞时间(Total Blocking Time,TBT)量化了负载响应能力,测量了主线程被阻塞的时间长到足以阻止输入响应的总时间。TBT衡量的是第一次有内容的绘画(FCP)和交互时间(TTI)之间的总时间。它是TTI的配套指标,它为量化主线程活动带来了更多的细微差别,这些活动阻碍了用户与页面进行交互的能力。

此外,TBT与核心网络生命力的现场指标First Input Delay(FID)有很好的相关性。

需要更多的了解,可以参考链接:https://web.dev/tbt/



6.累积布局偏移 (Cumulative Layout Shift)

Cumulative Layout Shift (CLS) 是一种视觉稳定性的测量方法,它量化了页面内容在视觉上的移动程度。它量化了一个页面的内容在视觉上移动的程度。

简单理解就是:CLS测量的是整个页面生命周期内发生的每一次意外布局转变的所有单个布局转变得分的总和。


布局偏移发生在可见元素从一个渲染帧到下一个渲染帧改变其位置的任何时候。

关于如何计算单个布局偏移分数,请参见下文:https://web.dev/cls/


20210625194937957.png



从上面的图来看,CLS得分低是给开发者的一个信号,表明他们的用户没有经历不必要的内容移动;CLS得分低于0.10被认为是 “好”。



相关名词解释、资料


   TTFB:time for First Byte 首字节时间

   FP:First Paint 首次绘制

   FCP:First Contentful Paint 首次有内容的渲染

   FMP:First Meaningful Paint 首次有意义的绘制

   TTI:Time To interactive 可交互时间

   Long tasks:超过50ms的任务

   SSR && CSR:服务端渲染和客户端渲染

   Isomorphic JS:同构化


[1] Lighthouse performance scoring: https://web.dev/performance-scoring/

[2] GoogleChrome-lighthouse: https://github.com/GoogleChrome/lighthouse

[3] What’s New in Lighthouse 6.0: https://web.dev/lighthouse-whats-new-6.0/

[4] Measure: https://web.dev/measure/

[5] How does Lighthouse work?:https://github.com/GoogleChrome/lighthouse/blob/master/docs/architecture.md

[6] Largest Contentful Paint (LCP): https://web.dev/lcp/

[7] Total Blocking Time (TBT): https://web.dev/tbt/

[8] Cumulative Layout Shift (CLS): https://web.dev/cls/

[9] First Contentful Paint (FCP): https://web.dev/fcp/

[10] Speed Index: https://web.dev/speed-index/




拓展:灯塔性能评分

参考文章:Lighthouse performance scoring


20210625172644833.png


绩效分数如何加权

性能分数是加权平均的的指标分数。自然,权重越重的指标对您的整体绩效得分影响越大。指标分数在报告中不可见,但在幕后计算。


20210625172739535.png


20210625172750520.png


如何确定指标分数

一旦 Lighthouse 完成收集性能指标(主要以毫秒为单位报告),它会通过查看指标值落在其 Lighthouse 评分分布的哪个位置,将每个原始指标值转换为从 0 到 100 的指标分数。评分分布是从HTTP Archive上真实网站性能数据的性能指标得出的对数正态分布。



例如,最大内容绘制 (LCP) 测量用户何时认为页面的最大内容可见。LCP 的度量值表示用户启动页面加载和页面呈现其主要内容之间的持续时间。基于真实的网站数据,表现最好的网站在大约 1,220 毫秒内呈现 LCP,因此指标值映射到 99 分。


再深入一点,Lighthouse 评分曲线模型使用 HTTPArchive 数据来确定两个控制点,然后设置对数正态曲线的形状。HTTPArchive 数据的第 25 个百分点变为 50(中值控制点),第 8 个百分点变为 90(良好/绿色控制点)。在探索下面的评分曲线图时,请注意在 0.50 和 0.92 之间,度量值和分数之间存在近乎线性的关系。大约 0.96 的分数是“收益递减点”,在它上面,曲线拉开,需要越来越多的指标改进来提高已经很高的分数。


https://www.desmos.com/calculator/o98tbeyt1t?lang=zh-CN


20210625173238796.png


















目录
相关文章
|
7月前
|
存储 缓存 监控
|
2月前
|
移动开发 前端开发 API
鸿蒙web加载本地网页资源异常
在鸿蒙NEXT Api 12中,为解决Web组件加载本地资源(如图片、CSS等)失败的问题,我们采用拦截机制。具体步骤如下: 1. **替换路径**:通过正则表达式将HTML和CSS中的资源路径替换为带有标记的URL(如`http://local`),以便后续识别。 2. **拦截与返回**:在资源加载时,拦截带有标记的URL,读取对应的本地文件并返回给Web组件。此过程确保了本地资源能正确加载和显示。 代码实现包括路径替换、资源拦截及响应构建,确保Web页面能够顺利加载本地资源。
146 7
|
4月前
|
Web App开发 编解码 vr&ar
使用Web浏览器访问UE应用的最佳实践
在3D/XR应用开发中,尤其是基于UE(虚幻引擎)开发的高精度场景,传统终端因硬件局限难以流畅运行高帧率、复杂效果的三维应用。实时云渲染技术,将渲染任务转移至云端服务器,降低终端硬件要求,确保用户获得流畅体验。具备弹性扩展、优化传输协议、跨平台支持和安全性等优势,适用于多种终端和场景,特别集成像素流送技术,帮助UE开发者实现低代码上云操作,简化部署流程,保留UE引擎的强大开发能力,确保画面精美且终端轻量化。
248 17
使用Web浏览器访问UE应用的最佳实践
|
2月前
|
数据采集 消息中间件 JavaScript
浏览器渲染揭秘:从加载到显示的全过程;浏览器工作原理与详细流程
了解浏览器工作原理与流程,能有效帮助前端开发与性能优化。 博客不应该只有代码和解决方案,重点应该在于给出解决方案的同时分享思维模式,只有思维才能可持续地解决问题,只有思维才是真正值得学习和分享的核心要素。如果这篇博客能给您带来一点帮助,麻烦您点个赞支持一下,还可以收藏起来以备不时之需,有疑问和错误欢迎在评论区指出~
|
6月前
|
JavaScript 前端开发 数据处理
模板字符串和普通字符串在浏览器和 Node.js 中的性能表现是否一致?
综上所述,模板字符串和普通字符串在浏览器和 Node.js 中的性能表现既有相似之处,也有不同之处。在实际应用中,需要根据具体的场景和性能需求来选择使用哪种字符串处理方式,以达到最佳的性能和开发效率。
146 63
|
6月前
|
缓存 监控 前端开发
在资源加载优化中,如何利用浏览器缓存提升性能?
通过以上这些方法,可以有效地利用浏览器缓存来提升资源加载的性能,减少网络请求次数,提高用户体验和应用的响应速度。同时,需要根据具体的应用场景和资源特点进行灵活调整和优化,以达到最佳的效果。此外,随着技术的不断发展和变化,还需要持续关注和学习新的缓存优化方法和策略。
153 53
|
6月前
|
缓存 监控 测试技术
如何利用浏览器的缓存来优化网站性能?
【10月更文挑战第23天】通过以上多种方法合理利用浏览器缓存,可以显著提高网站的性能,减少网络请求,加快资源加载速度,提升用户的访问体验。同时,要根据网站的具体情况和资源的特点,不断优化和调整缓存策略,以适应不断变化的业务需求和用户访问模式。
344 63
|
6月前
|
人工智能 前端开发 计算机视觉
Inpaint-Web:纯浏览器端实现的开源图像处理工具
在刷短视频时,常看到情侣在景区拍照被路人“抢镜”,男朋友用手机将路人“P”掉,既贴心又有趣。最近我发现了一个纯前端实现的开源项目——inpaint-web,可在浏览器端删除照片中的部分内容,非常酷。该项目基于 WebGPU 和 WASM 技术,支持图像修复与放大,已在 GitHub 上获得 5.1k Star。项目地址:[GitHub](https://github.com/lxfater/inpaint-web)。
223 3
 Inpaint-Web:纯浏览器端实现的开源图像处理工具
|
6月前
|
存储 缓存 前端开发
Web端IM聊天消息该不该用浏览器本地存储?一文即懂!
鉴于目前浏览器技术的进步(主要是HTML5的普及),在Web网页端IM聊天应用的技术选型阶段,很多开发者都会纠结到底该不该像原生移动端IM那样将聊天记录缓存在浏览器的本地,还是像传统Web端即时通讯那样继续存储在服务端?本文将为你简洁明了地讲清楚浏览器本地存储技术(Web Storage),然后你就知道到底该怎么选择了。
125 1
|
6月前
|
Java Maven Spring
Java Web 应用中,资源文件的位置和加载方式
在Java Web应用中,资源文件如配置文件、静态文件等通常放置在特定目录下,如WEB-INF或classes。通过类加载器或Servlet上下文路径可实现资源的加载与访问。正确管理资源位置与加载方式对应用的稳定性和可维护性至关重要。
147 7