自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

當(dāng)我們談?wù)撉岸诵阅軙r(shí),我們?cè)谡務(wù)撌裁?/h1>

開(kāi)發(fā) 前端
Lighthouse 是一個(gè)開(kāi)源的網(wǎng)頁(yè)性能分析工具,提供了關(guān)于頁(yè)面最佳實(shí)踐的相關(guān)建議。除了可以直接在Chrome DevTools中使用外,它還支持瀏覽器擴(kuò)展(Chrome和Firefox)或npm包(Node API或CLI)。

本文結(jié)合Google官方工具 Lighthouse 分析最新的前端頁(yè)面性能評(píng)分標(biāo)準(zhǔn),幫助大家更好地理解各種性能指標(biāo),以改進(jìn)和優(yōu)化相關(guān)前端項(xiàng)目。

前端頁(yè)面性能一直是大家持續(xù)關(guān)注的話題,因?yàn)橛脩袅舸媛逝c頁(yè)面加載性能密切相關(guān)。根據(jù)Google的數(shù)據(jù)統(tǒng)計(jì),當(dāng)頁(yè)面訪問(wèn)時(shí)長(zhǎng)從1秒增加到3秒時(shí),用戶跳出率會(huì)增加32%。

評(píng)估前端頁(yè)面性能通常有兩種形式:一是使用性能分析工具在線對(duì)各項(xiàng)指標(biāo)進(jìn)行評(píng)分和評(píng)估;二是使用性能監(jiān)控,通過(guò) Performance API 或自定義跟蹤點(diǎn)報(bào)告用戶的真實(shí)網(wǎng)絡(luò)訪問(wèn)情況,然后進(jìn)行統(tǒng)計(jì)分析。

雖然統(tǒng)計(jì)收集用戶數(shù)據(jù)更貼近實(shí)際,但為了對(duì)頁(yè)面性能評(píng)估有一個(gè)統(tǒng)一的量化標(biāo)準(zhǔn),我們通常選擇使用標(biāo)準(zhǔn)評(píng)分工具來(lái)評(píng)估頁(yè)面性能。

在性能分析的早期階段,我們會(huì)使用Chrome開(kāi)發(fā)者工具分析網(wǎng)頁(yè),包括查看 load 和DOMContentLoaded等事件觸發(fā)的時(shí)間。后來(lái)出現(xiàn)了一系列性能分析工具,如Webpage Analyzer、WebPageTest、YSlow等。

現(xiàn)在Google已經(jīng)正式將其自主開(kāi)發(fā)的Lighthouse嵌入到開(kāi)發(fā)者工具標(biāo)簽中,我們將Lighthouse視為標(biāo)準(zhǔn)評(píng)估工具。

Lighthouse 是一個(gè)開(kāi)源的網(wǎng)頁(yè)性能分析工具,提供了關(guān)于頁(yè)面最佳實(shí)踐的相關(guān)建議。除了可以直接在Chrome DevTools中使用外,它還支持瀏覽器擴(kuò)展(Chrome和Firefox)或npm包(Node API或CLI)。

像 Google 的 Web measure 和 PageSpeed Insight等工具都使用Lighthouse來(lái)分析頁(yè)面。

1.Lighthouse 的迭代和性能指標(biāo)變化

Lighthouse 的第一個(gè)開(kāi)源版本可以追溯到2016年,截至2020年10月,最新版本是6.4.1,總共經(jīng)歷了89次迭代。多年來(lái),Lighthouse一直在更新其性能指標(biāo)的選擇。

在最新的6.x版本中,與5.x版本相比,Google引入了三個(gè)新的性能指標(biāo):移除了FMP(First Meaningful Paint)、FCI(First CPU Idle)和 mpFID(Max Potential First Input Delay);

添加了TBT(Total Blocking Time)、LCP(Largest Contentful Paint)和CLS(Cumulative Layout Shift)。以下部分將對(duì)這些指標(biāo)進(jìn)行詳細(xì)解釋。

2.如何計(jì)算頁(yè)面性能得分

如下圖所示,在頁(yè)面性能部分,Lighthouse將評(píng)估6個(gè)關(guān)鍵指標(biāo)的性能,并計(jì)算頁(yè)面的性能得分。

根據(jù)最新的6.x計(jì)算方法,每個(gè)性能指標(biāo)對(duì)應(yīng)一個(gè)分?jǐn)?shù)。例如,在上圖中,F(xiàn)CP、SI、LCP、TTI、TBT和CLS的值分別對(duì)應(yīng)78、62、37、5、99和92的單項(xiàng)得分。通常來(lái)說(shuō),指標(biāo)值越小,其對(duì)應(yīng)的得分越高。

這六個(gè)指標(biāo)分別被賦予15%、15%、25%、15%、25%和5%的權(quán)重??傮w性能得分的計(jì)算如圖所示 — 通過(guò)加權(quán)平均得到總分60分。

每個(gè)指標(biāo)值如何對(duì)應(yīng)其各自的得分計(jì)算方法的具體細(xì)節(jié)可以在文章末尾的參考文獻(xiàn)5和6中找到。

在Lighthouse v6.0版本中, 移除了三個(gè)關(guān)鍵性能指標(biāo): FMP(First Meaningful Paint)、FCI(First CPU Idle) 和 mpFID(Maximum Potential First Input Delay)。

我們將首先examine這三個(gè)已棄用指標(biāo)的定義,以better理解當(dāng)前版本如何選擇其指標(biāo)。

1. 什么是FMP,它與FCP有什么區(qū)別?

談到FMP,我們必須首先介紹First Contentful Paint (FCP):第一次內(nèi)容渲染的時(shí)間。

顧名思義,只要瀏覽器第一次觸發(fā)The First Page Paint事件,這一刻就是FCP。然而,此時(shí)渲染的內(nèi)容不一定是重要的頁(yè)面信息,比如只繪制了一個(gè)頭部操作欄或甚至可見(jiàn)元素。雖然它在Lighthouse 6.0中被保留,但其在性能得分中的權(quán)重從23%降至15%。

因此,從用戶的角度來(lái)看,FCP不能作為頁(yè)面性能的準(zhǔn)確指標(biāo)。

在這種背景下,FMP(First Meaningful Paint)應(yīng)運(yùn)而生。根據(jù)官方定義,FMP指的是自頁(yè)面加載開(kāi)始以來(lái),初始屏幕上大部分或主要內(nèi)容已被渲染的時(shí)間點(diǎn)。

那么FMP的計(jì)時(shí)如何確認(rèn)?讓我們先看最基本的計(jì)算方法:

我們首先計(jì)算布局對(duì)象的數(shù)量(使用LayoutAnalyzer進(jìn)行測(cè)試計(jì)算;參見(jiàn)參考文獻(xiàn)17)。

如下圖所示,可以看到頁(yè)面加載過(guò)程是布局對(duì)象逐步進(jìn)入布局樹(shù)并渲染的過(guò)程。

layoutAnalyzer 收集布局對(duì)象的數(shù)量,有一個(gè)計(jì)數(shù)器叫 LayoutObjectsThatHadNeverHadLayout,代表新增加的布局對(duì)象的數(shù)量。

通過(guò)測(cè)試發(fā)現(xiàn),與其他計(jì)數(shù)器相比,它變化最大的時(shí)刻往往是頁(yè)面上最重要的元素被渲染的時(shí)候。

因此,FMP指標(biāo)的計(jì)算方法是LayoutObjectsThatHadNeverHadLayout(新增布局對(duì)象)經(jīng)歷最大變化后的下一刻(跟隨最大布局變化的繪制)。

當(dāng)然,也有一些情況下上述情況不適用:

a) 如果頁(yè)面很長(zhǎng),可能在第一屏內(nèi)添加的不可見(jiàn)布局對(duì)象比可見(jiàn)的多。在這種情況下,FMP變得不準(zhǔn)確。

b) 在加載網(wǎng)絡(luò)字體的情況下,文本使用fallback字體進(jìn)行布局但默認(rèn)在loadstart后3秒內(nèi)不繪制;這也會(huì)影響FMP的計(jì)算。

對(duì)于場(chǎng)景1,FMP引入了"布局重要性"的概念來(lái)解決這個(gè)問(wèn)題;對(duì)于場(chǎng)景2,FMP延遲統(tǒng)計(jì)以使指標(biāo)更準(zhǔn)確地反映頁(yè)面狀況。更詳細(xì)的解決方案請(qǐng)參考參考文獻(xiàn)18。

然而,FMP最終在6.0版本中被棄用,主要是由于以下兩個(gè)原因:

  • 在生產(chǎn)環(huán)境中,FMP對(duì)頁(yè)面上的微小變化過(guò)于敏感,容易導(dǎo)致結(jié)果不一致。
  • 這個(gè)指標(biāo)的定義過(guò)于依賴瀏覽器的具體實(shí)現(xiàn)細(xì)節(jié),缺乏標(biāo)準(zhǔn)化的參考。

2.LCP的到來(lái)取代了FMP

前一節(jié)提到了FCP和FMP的缺點(diǎn),所以W3C的性能組一直在思考找到一個(gè)合適的指標(biāo),更準(zhǔn)確地反映用戶看到頁(yè)面主要內(nèi)容的時(shí)間。

有時(shí)候更簡(jiǎn)單更好?;诟鞣矫骊P(guān)于頁(yè)面性能的討論,終于找到了一個(gè)更準(zhǔn)確的方法來(lái)衡量頁(yè)面的主要內(nèi)容是否已加載,這就是 LCP(Largest Contentful Paint)。

LCP指的是視口內(nèi)最大內(nèi)容元素渲染的時(shí)間。這個(gè)指標(biāo)在Lighthouse 6.0中正式引入,在最終性能得分中占據(jù)高達(dá)25%的權(quán)重。

LCP 應(yīng)該是除FCP之外最容易定義的指標(biāo)之一。從其定義來(lái)看,有兩個(gè)關(guān)鍵點(diǎn):選擇哪些元素進(jìn)行比較,以及如何確定它們的大小。

根據(jù)官方文檔,以下元素將被視為 Largest Contentful Element 的一部分:

  • <img>
  • <svg>中的<image>
  • <video>
  • 通過(guò)url()函數(shù)加載背景圖片的元素
  • 包含文本節(jié)點(diǎn)或內(nèi)聯(lián)文本子元素的塊級(jí)元素

我們?nèi)绾未_定一個(gè)元素的大小?主要基于這四條規(guī)則:

  • 視口內(nèi)可見(jiàn)元素的大小;如果它們超出或被裁剪或被遮擋,則不計(jì)入元素大小。
  • 對(duì)于圖像元素,大小由Min(實(shí)際大小,原始大小)決定。
  • 對(duì)于文本元素,只考慮覆蓋所有文本的最小矩形區(qū)域。
  • 對(duì)于所有元素,不包括margin、padding、border等在計(jì)算中。

Google對(duì)這個(gè)指標(biāo)的評(píng)價(jià)如下:LCP是一個(gè)非常重要的以用戶為中心的指標(biāo);它反映了用戶層面感知的加載速度;它標(biāo)志著主要內(nèi)容中最大內(nèi)容元素的加載完成;LCP時(shí)間越短,用戶感知頁(yè)面可用的速度越快。

3.被放棄的FCI是什么,為什么它與TTI如此密切相關(guān)?

FCI(First CPU Idle:首次CPU空閑),這個(gè)指標(biāo)用來(lái)衡量一個(gè)頁(yè)面達(dá)到最小可交互標(biāo)準(zhǔn)需要多長(zhǎng)時(shí)間。

最小可交互性的確認(rèn)需要同時(shí)滿足以下兩個(gè)條件:

a) 屏幕上的大多數(shù)UI元素是可交互的

b) 頁(yè)面對(duì)用戶輸入的響應(yīng)平均在合理范圍內(nèi)

TTI(Time To Interactive:頁(yè)面可交互時(shí)間),指頁(yè)面達(dá)到完全可交互狀態(tài)所需的時(shí)間。

完全可交互意味著同時(shí)滿足以下三個(gè)條件:

a) FCP之后,頁(yè)面上已經(jīng)渲染了有用的內(nèi)容

b) 為最可見(jiàn)的頁(yè)面元素注冊(cè)了事件回調(diào)

c) 頁(yè)面對(duì)用戶交互的響應(yīng)在50ms以內(nèi)

2017年,First Interactive 指標(biāo)被分為兩個(gè)指標(biāo): First Interactive 和 Consistently Interactive; 次年7月, First Interactive被重命名為 FCI,而Consistently Interactive 被重命名為TTI??梢钥闯?FCI和TTI是兩個(gè)反映用戶交互響應(yīng)的指標(biāo)。

那么,最小可交互性和完全可交互性是如何計(jì)算的?在介紹具體計(jì)算方法之前,我們需要知道,這兩個(gè)指標(biāo)都是模糊的,可以在不同情況下不斷優(yōu)化和改進(jìn)。

FCI的最小可交互時(shí)間

在主線程的時(shí)間線上,從FMP開(kāi)始直到某個(gè)任務(wù)結(jié)束之后,找到一個(gè)長(zhǎng)度為f(t)的時(shí)間窗口W。如果W滿足在其持續(xù)時(shí)間內(nèi)任何時(shí)刻都沒(méi)有連續(xù)超過(guò)250ms的任務(wù)集,并且在其結(jié)束前后1秒內(nèi)沒(méi)有長(zhǎng)任務(wù)(JS執(zhí)行時(shí)間超過(guò)50ms的任務(wù))。那個(gè)任務(wù)結(jié)束的時(shí)刻就是我們定義的FCI。其中f(t)=4e^(-0.045t)+1。

下圖中紅框指示的時(shí)間點(diǎn)就是FCI。

TTI完全可交互時(shí)間

從網(wǎng)絡(luò)和主線程的時(shí)間線上,找到第一個(gè)5s窗口期 W。在 W 期間,應(yīng)滿足以下條件:任何時(shí)刻并發(fā)網(wǎng)絡(luò)請(qǐng)求不超過(guò)兩個(gè),且沒(méi)有超過(guò)50ms的長(zhǎng)任務(wù)。W 之前最后一個(gè)長(zhǎng)任務(wù)結(jié)束的時(shí)間就是我們所說(shuō)的TTI。

下圖中紅框指示的時(shí)間點(diǎn)就是TTI:

盡管有人指出FCI在某些時(shí)候比TTI更有意義,但它們之間的區(qū)別仍然不足以證明 Lighthouse 保留兩個(gè)相似的指標(biāo)。

因此,在Lighthouse 6.0中,最終決定使用TTI代替FCI。

4.mpFID和新增的TBT指標(biāo)

mpFID(max potential First Input Delay)指的是頁(yè)面上從用戶輸入到實(shí)際開(kāi)始處理事件回調(diào)的潛在最大延遲時(shí)間。

mpFID的具體計(jì)算方法是選擇從FCP到TTI之間JavaScript執(zhí)行時(shí)間最長(zhǎng)的任務(wù),然后從該任務(wù)消耗的時(shí)間中減去50ms。

然而,mpFID只代表一個(gè)最大延遲時(shí)間,可能與用戶實(shí)際體驗(yàn)到的延遲時(shí)間不同。用戶在不同時(shí)間獲得的FID也會(huì)有所不同。因此,mpFID并不能真實(shí)反映頁(yè)面對(duì)用戶輸入的響應(yīng)時(shí)間。

在5.x版本計(jì)算性能得分時(shí),mpFID權(quán)重為0,不參與打分。雖然這個(gè)指標(biāo)不再出現(xiàn)在報(bào)告中,但它仍然保留在JSON數(shù)據(jù)中,仍然是官方認(rèn)可的關(guān)鍵用戶體驗(yàn)指標(biāo)。

那么,TBT(Total Blocking Time)到底是什么,為什么在性能報(bào)告中選擇它而不是FID呢?

我們先來(lái)看看它的定義:TBT指的是頁(yè)面在響應(yīng)用戶輸入時(shí)被阻塞的總累計(jì)時(shí)間。

具體計(jì)算方法相當(dāng)清晰 — 將FCP和TTI之間的所有長(zhǎng)任務(wù)加起來(lái),并將它們的阻塞部分的時(shí)間相加,就得到了TBT。阻塞部分的時(shí)間指的是長(zhǎng)任務(wù)執(zhí)行超過(guò)50ms的任何部分;例如,如果一個(gè)長(zhǎng)任務(wù)總共花費(fèi)70ms,那么阻塞時(shí)間就是20ms。

可以看出,與mpFID相比,TBT是一個(gè)更穩(wěn)定的指標(biāo),能更準(zhǔn)確地反映頁(yè)面對(duì)用戶輸入的平均延遲響應(yīng)。

5. 新增的CLS

CLS(Cumulative Layout Shift),是用來(lái)衡量視覺(jué)界面穩(wěn)定性的指標(biāo)。

數(shù)據(jù)來(lái)源于Layout Instability API(參見(jiàn)參考文獻(xiàn)14),計(jì)算方法如下:

layout shift score = impact fraction * distance fraction

布局移動(dòng)分?jǐn)?shù) = 影響分?jǐn)?shù) * 距離分?jǐn)?shù)

其中impact fraction指的是對(duì)整個(gè)視口的影響程度。例如,在下圖中,如果文本占整個(gè)視口的50%,在下一幀中相對(duì)于上一幀向下移動(dòng)了25%,那么它影響了整個(gè)頁(yè)面的75%。因此,impact fraction為0.75。

distance fraction相對(duì)容易理解,它指的是改變的距離占整個(gè)視口的比例。例如,在上述案例中,移動(dòng)25%意味 著distance fraction 為 0.25。

因此,圖示demo的CLS值計(jì)算為0.75 * 0.25 = 0.1875。更詳細(xì)的計(jì)算方法可以參考參考文獻(xiàn)13和14。

一個(gè)說(shuō)明CLS如何影響用戶體驗(yàn)的例子:如下圖所示,當(dāng)用戶試圖點(diǎn)擊取消按鈕時(shí),突然頁(yè)面發(fā)生布局偏移,確認(rèn)按鈕出現(xiàn)在之前取消按鈕的位置...

可以看出,CLS是一個(gè)更加以用戶為中心的新性能評(píng)估指標(biāo)。

目前,CLS作為一個(gè)新增指標(biāo)權(quán)重較小,只有5%,但Lighthouse已經(jīng)在考慮在下一個(gè)主要版本中增加其權(quán)重。

6. 一直存在的Speed Index

Speed Index(SI)用于衡量可見(jiàn)內(nèi)容填充頁(yè)面的速度,計(jì)算過(guò)程使用開(kāi)源工具Speedline(參考文獻(xiàn)16)。

Speedline記錄頁(yè)面的視頻,并通過(guò)測(cè)量第一幀和最后一幀之間的時(shí)間差來(lái)計(jì)算Speed Index的值。

值得一提的是,SI的最終得分將通過(guò)與數(shù)據(jù)庫(kù)中真實(shí)網(wǎng)站的SI值進(jìn)行比較來(lái)計(jì)算。目前,SI得分和評(píng)分標(biāo)準(zhǔn)如下表所示:

回顧上述指標(biāo)替換的過(guò)程,我們可以看到,無(wú)論是從FMP到LCP,FCI到TTI,還是FID到TBT,目前在性能指標(biāo)的選擇上,都在向更穩(wěn)定的方向發(fā)展:指標(biāo)的定義越來(lái)越簡(jiǎn)潔明了,計(jì)算方法也趨向標(biāo)準(zhǔn)化。

然而,我們也應(yīng)該知道,這里沒(méi)有銀彈;每個(gè)指標(biāo)都會(huì)有其局限性。在許多場(chǎng)景下,低分并不一定意味著頁(yè)面體驗(yàn)差。只有理解這些指標(biāo)背后的原理,我們才能基于性能得分更科學(xué)地評(píng)估頁(yè)面。

責(zé)任編輯:姜華 來(lái)源: 大遷世界
相關(guān)推薦

2022-11-11 09:28:57

軟件設(shè)計(jì)DDD

2016-08-12 10:11:22

2020-11-16 15:47:05

SaaS軟件轉(zhuǎn)型

2022-07-05 09:31:46

基礎(chǔ)設(shè)施容器Docker

2019-02-19 10:22:07

5G5G手機(jī)5G技術(shù)

2017-04-05 17:59:29

思科CTO下午茶

2024-03-28 14:16:43

容災(zāi)云計(jì)算

2022-04-28 13:02:32

cpu指令編程

2019-03-18 10:08:18

RSACRSA大會(huì) 網(wǎng)絡(luò)安全

2019-06-04 14:36:04

高并發(fā)Java架構(gòu)

2014-02-06 12:21:35

軟件集成

2022-03-11 21:28:31

部署開(kāi)發(fā)服務(wù)器

2023-08-28 10:33:09

敏捷Scrum理念

2019-07-30 13:12:22

2019-12-24 11:19:44

容器DockerLinux

2016-11-22 23:44:56

2017-10-11 08:40:29

VR服務(wù)器移動(dòng)端

2017-03-07 15:43:28

編程語(yǔ)言函數(shù)數(shù)據(jù)結(jié)構(gòu)

2021-11-18 21:09:50

流批場(chǎng)景引擎

2017-10-11 13:25:00

前端
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)