浏览器原理 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


















目录
相关文章
|
3月前
|
存储 缓存 监控
|
3月前
|
Web App开发 前端开发 JavaScript
探索Python科学计算的边界:利用Selenium进行Web应用性能测试与优化
【10月更文挑战第6天】随着互联网技术的发展,Web应用程序已经成为人们日常生活和工作中不可或缺的一部分。这些应用不仅需要提供丰富的功能,还必须具备良好的性能表现以保证用户体验。性能测试是确保Web应用能够快速响应用户请求并处理大量并发访问的关键步骤之一。本文将探讨如何使用Python结合Selenium来进行Web应用的性能测试,并通过实际代码示例展示如何识别瓶颈及优化应用。
158 5
|
2月前
|
缓存 监控 前端开发
在资源加载优化中,如何利用浏览器缓存提升性能?
通过以上这些方法,可以有效地利用浏览器缓存来提升资源加载的性能,减少网络请求次数,提高用户体验和应用的响应速度。同时,需要根据具体的应用场景和资源特点进行灵活调整和优化,以达到最佳的效果。此外,随着技术的不断发展和变化,还需要持续关注和学习新的缓存优化方法和策略。
100 53
|
2月前
|
人工智能 前端开发 计算机视觉
Inpaint-Web:纯浏览器端实现的开源图像处理工具
在刷短视频时,常看到情侣在景区拍照被路人“抢镜”,男朋友用手机将路人“P”掉,既贴心又有趣。最近我发现了一个纯前端实现的开源项目——inpaint-web,可在浏览器端删除照片中的部分内容,非常酷。该项目基于 WebGPU 和 WASM 技术,支持图像修复与放大,已在 GitHub 上获得 5.1k Star。项目地址:[GitHub](https://github.com/lxfater/inpaint-web)。
73 3
 Inpaint-Web:纯浏览器端实现的开源图像处理工具
|
2月前
|
存储 缓存 前端开发
Web端IM聊天消息该不该用浏览器本地存储?一文即懂!
鉴于目前浏览器技术的进步(主要是HTML5的普及),在Web网页端IM聊天应用的技术选型阶段,很多开发者都会纠结到底该不该像原生移动端IM那样将聊天记录缓存在浏览器的本地,还是像传统Web端即时通讯那样继续存储在服务端?本文将为你简洁明了地讲清楚浏览器本地存储技术(Web Storage),然后你就知道到底该怎么选择了。
36 1
|
2月前
|
Java Maven Spring
Java Web 应用中,资源文件的位置和加载方式
在Java Web应用中,资源文件如配置文件、静态文件等通常放置在特定目录下,如WEB-INF或classes。通过类加载器或Servlet上下文路径可实现资源的加载与访问。正确管理资源位置与加载方式对应用的稳定性和可维护性至关重要。
63 6
|
2月前
|
缓存 监控 测试技术
如何利用浏览器的缓存来优化网站性能?
【10月更文挑战第23天】通过以上多种方法合理利用浏览器缓存,可以显著提高网站的性能,减少网络请求,加快资源加载速度,提升用户的访问体验。同时,要根据网站的具体情况和资源的特点,不断优化和调整缓存策略,以适应不断变化的业务需求和用户访问模式。
110 7
|
3月前
|
机器学习/深度学习 缓存 监控
利用机器学习优化Web性能和用户体验
【10月更文挑战第16天】本文探讨了如何利用机器学习技术优化Web性能和用户体验。通过分析用户行为和性能数据,机器学习可以实现动态资源优化、预测性缓存、性能瓶颈检测和自适应用户体验。文章还介绍了实施步骤和实战技巧,帮助开发者更有效地提升Web应用的速度和用户满意度。
|
3月前
|
SQL 关系型数据库 数据库
优化Web开发流程:Python ORM的优势与实现细节
【10月更文挑战第4天】在Web开发中,数据库操作至关重要,但直接编写SQL语句既繁琐又易错。对象关系映射(ORM)技术应运而生,让开发者以面向对象的方式操作数据库,显著提升了开发效率和代码可维护性。本文探讨Python ORM的优势及其实现细节,并通过Django ORM的示例展示其应用。ORM提供高级抽象层,简化数据库操作,提高代码可读性,并支持多种数据库后端,防止SQL注入。Django内置强大的ORM系统,通过定义模型、生成数据库表、插入和查询数据等步骤,展示了如何利用ORM简化复杂的数据库操作。
80 6
|
3月前
|
缓存 前端开发 JavaScript
探索现代Web开发中的前端性能优化策略
【10月更文挑战第5天】探索现代Web开发中的前端性能优化策略