久久亚洲国产精品视频,中国AV片,最近中文字幕免费大全,国产亚洲精品久久久999功能介绍,欧美色女人

金融情報局網(wǎng)_中國金融門戶網(wǎng)站 讓金融財經(jīng)離的更近

300 毫秒分勝負(fù):維基百科的總阻塞時間優(yōu)化之道

當(dāng)前位置:金融情報局網(wǎng)_中國金融門戶網(wǎng)站 讓金融財經(jīng)離的更近>資訊 > 國際 > 正文  2023-06-28 23:54:30 來源:InfoQ

作者 | Nicholas Ray

譯者 | 核子可樂

策劃 | 丁曉昀


(相關(guān)資料圖)

大家有沒有遇到過響應(yīng)緩慢、卡頓崩潰的垃圾網(wǎng)站?遇上這類性能缺陷,脾氣火爆的朋友往往果斷選擇:

狂點鼠標(biāo); 退出走人,拉低客源轉(zhuǎn)化率; 搜索引擎排名因此下降。

三年多來,維基百科的移動版網(wǎng)站也深受一段 JavaScript 代碼的戕害。在低端手機上,這段 JS 代碼的頁面加載時間可能超過 600 毫秒,大大影響了用戶的交互體驗。

在本文中,我們將一同了解如何通過幾個簡單步驟,讓任務(wù)執(zhí)行時間有效縮短約 50%。

在 JS 執(zhí)行方面,600 毫秒似乎并不是什么無法接受的問題。但我們不妨想象這樣的場景:當(dāng)這段 600 毫秒的 JS 代碼開始執(zhí)行時,用戶恰好想在加載過程中單擊某個按鈕。因為特定時段內(nèi)瀏覽器的主線程只能處理一個任務(wù),所以用戶必須等待以下步驟完成后才能獲得操作反饋:

JS 任務(wù)花 600 毫秒執(zhí)行完畢 點擊處理任務(wù)隨后開始執(zhí)行 瀏覽器執(zhí)行必要的渲染步驟,最終更新頁面內(nèi)容

長任務(wù)可能導(dǎo)致視覺更新延遲,拖慢點擊程序的處理速度

每個步驟都需要消耗時間,而任何超過 100 毫秒的響應(yīng)速度都會給用戶帶來非常明確的延遲感受。正因為如此,谷歌將一切耗時超過 50 毫秒的任務(wù)定性為“長任務(wù)”,認(rèn)為其會影響頁面對用戶輸入的響應(yīng)。他們甚至專門為此制定了“總阻塞時間”(TBT)的指標(biāo)。

這里有兩個長任務(wù)(大于 50 毫秒)——分別耗時 80 毫秒和 100 毫秒

所謂總阻塞時間,是指瀏覽器主線程上全部長任務(wù)在首屏內(nèi)容繪制(FCP)和響應(yīng)時間(TTI)之間的阻塞部分的總和。換言之,“阻塞部分”代表著每個長任務(wù)超出 50 毫秒之外的時間消耗。

計算以下示例中的總阻塞時間:

80 毫秒任務(wù)比 50 毫秒基準(zhǔn)多出 30 毫秒,因此帶來了 30 毫秒的總阻塞時間。 30 毫秒的任務(wù)不構(gòu)成阻塞時間,因為其小于 50 毫秒且不屬于長任務(wù)。 100 毫秒的任務(wù)比 50 毫秒基準(zhǔn)多出 50 毫秒,因此帶來了 50 毫秒的總阻塞時間。

由于總阻塞時間對應(yīng)每個長任務(wù)超過 50 毫秒部分的總和,所以示例中的最終結(jié)果是 30 毫秒+50 毫秒=80 毫秒。

在常規(guī)移動硬件上進行測試時,谷歌建議站點的總阻塞時間應(yīng)小于 200 毫秒。但維基百科上一項任務(wù)的執(zhí)行就可能超過 600 毫秒——相當(dāng)于總體上限的 3 倍。

我們該如何改進性能?

要降低這項指標(biāo),我們需要:

在首屏繪制和交互時間之間,減少主線程上的工作負(fù)載; 在保證工作內(nèi)容不變的情況下,將長任務(wù)拆分成多個不超過 50 毫秒的小任務(wù)。

本文主要側(cè)重第一種解決思路。

HTML 解析、繪制和垃圾收集都需要在主線程上運行,但引發(fā)總阻塞時間過長的罪魁禍?zhǔn)兹匀皇?JS 代碼。畢竟有經(jīng)驗的前端開發(fā)者都知道,網(wǎng)站降速背后總有 JS 的身影。

在分析維基百科的移動站點時,我發(fā)現(xiàn)_enable 方法占用了大部分執(zhí)行時間。此方法負(fù)責(zé)對移動站點上的部分開展和折疊行為進行初始化。配置文件則顯示,在_enable 方法中,對 jQuery .on("click")方法的調(diào)用同樣速度很慢。

這里的.on("click")調(diào)用負(fù)責(zé)向內(nèi)容中的幾乎所有鏈接附加點擊事件偵聽器,這樣如果點擊的鏈接包含哈希片段,相應(yīng)的部分就會被展開。對于鏈接較少的短文章,這部分性能影響幾乎可以忽略不計。但對于像“美國”這類的長詞條,其內(nèi)容可能包含超過 4000 個鏈接,因此在低端設(shè)備上的執(zhí)行時間會超過 200 毫秒。

更糟糕的是,這種設(shè)計完全沒有必要。偵聽 haschange 事件的下游代碼已經(jīng)調(diào)用了與點擊事件偵聽器相同的方法。除非窗口位置已經(jīng)指向鏈接目的地,否則點擊鏈接會對 checkHash 方法調(diào)用兩次——一次用于鏈接點擊事件處理程序,另一次用于 hashchange 處理程序。

這種情況下,最好的方法當(dāng)然是直接刪除這個 JS 代碼塊,在幾乎不影響主線程功能的前提下直接省下近 200 毫秒。

在分析過程中,請始終檢查最耗時的部分,之后看看有沒有能夠優(yōu)化或者刪掉的代碼。

經(jīng)驗之談:加快網(wǎng)站速度的首選方法,永遠(yuǎn)是刪除 JS 代碼。

另一項性能審查顯示,initMediaViewer 方法需要約 100 毫秒的執(zhí)行時間。此方法負(fù)責(zé)將點擊事件偵聽器附加到內(nèi)容中的各個縮略圖處,這樣點擊縮略圖即可打開媒體查看器:

與步驟 1 中的鏈接示例類似,這種向頁面上各個縮略圖附加事件偵聽器的方法不利于性能擴展。

維基百科中的詞條可能包含數(shù)千張相關(guān)圖片。在這些多圖頁面上運行這段代碼時,其執(zhí)行時間可能超過 100 毫秒,必然增加頁面的總阻塞時間。下面來看替代方法。

答案就是 事件委托 。

事件委托是一種強大的技術(shù),允許我們將單個事件偵聽器附加到單一元素,而該元素可以是大量其他元素的共同祖先。對于可以添加任意數(shù)量元素的用戶生成內(nèi)容,我們往往可以通過事件委托提高其執(zhí)行效率。整個過程會用到事件冒泡,具體如下:

將事件偵聽器附加至容器元素。 在事件處理程序中使用 event 參數(shù),檢查 屬性以查看事件源??梢赃x擇使用 (selector) API 來檢查祖先元素。 如果該事件源就是我們所關(guān)注的元素或者其子元素,則進行處理。

更新后的代碼如下所示:

我們修改了 initMediaViewer 方法,將一個點擊事件偵聽器附加到了包含所有圖像的單一容器元素上。 在 onClickImage 方法中,我使用 (selector) API 來檢查點擊是否來自縮略圖元素或者其子元素。如果都不是,代碼會提前返回,因為這里只需要關(guān)注對縮略圖的點擊。如果是,則代碼將處理該事件。

我們分別通過兩輪部署,將步驟 1 和步驟 2 中的優(yōu)化發(fā)布到了生產(chǎn)環(huán)境。

根據(jù)維基百科的綜合性能測試數(shù)據(jù),在 Moto G(5)實機測試當(dāng)中,首輪部署將總阻塞時間縮短了約 200 毫秒,第二輪部署進一步縮短了約 80 毫秒。總體而言,這兩個步驟讓 Moto G(5)等移動設(shè)備訪問長文章時的總阻塞時間縮短了約 300 毫秒。

維基百科通過 Moto G(5)在綜合性能測試中訪問“瑞典”詞條

雖然仍有進一步改進空間,且查詢?nèi)蝿?wù)仍高于建議的低端設(shè)備延遲上限,但此次優(yōu)化還是取得了顯著成果。為了更大程度縮短總阻塞時間,后續(xù)可能有必要將任務(wù)拆分成更多小任務(wù)。

此次試驗表明,有針對性的小規(guī)模優(yōu)化有望實現(xiàn)顯著的性能改進。通過刪除或優(yōu)化特定代碼片段,看似微小的更改也會對網(wǎng)站的整體性能產(chǎn)生重大影響。換言之,要想在所有設(shè)備上改善響應(yīng)速度和瀏覽體驗,并不一定要對代碼庫開展復(fù)雜且廣泛的修改。有時候,小小一點調(diào)整就足以引發(fā)性能質(zhì)變。

原文鏈接:

/blog/300ms-faster-reducing-wikipedias-total-blocking-time/

本文轉(zhuǎn)載來源:

/article/rEoBohpb2NMs8Qe0lwuT

關(guān)鍵詞:

相關(guān)內(nèi)容