11月12日,一年一度的Chrome Developer Summit舉行,會議主要會聚焦於前端相關的主題,例如PWA、用戶體驗、性能、安全與隱私等等。在兩天的時間裏,Chrome的內部開發人員分享了Chrome的生態系統,工具和方法的更新,用於幫助咱們構建更好,更具吸引力體驗的網站。 因爲Google以及Chrome團隊都很是重視速度,所以許多主題都是關於性能的。前端
若是你還來得及去觀看會議的視頻,這篇文章講會給你彙總全部關於前端性能的主題內容。react
咱們已經知道,加載緩慢的網站會受到搜索排名算法的懲罰,致使你的網站在搜索排名中降低。 最近,Chrome瀏覽器採起進一步措施,以突出顯示給定的網站可能會提供較差的用戶體驗。 這些通知將採用Chrome內置的界面元素和警告形式。git
能夠看到Chrome在加載不一樣速度的網站時候,會有不一樣的用戶交互體驗。github
目前還不清楚Chrome是如何界定加載緩慢的網站,可是性能加載速度必定是一個核心指標,長期而言,性能對於網站的重要性愈來愈大,應該要儘可能避免被Chrome標識成加載緩慢的網站。web
Adaptive Loading Hooks 是React生態中針對低端手機設備的工具庫。經過它咱們能夠採用特定的資源加載、數據獲取、代碼分割和能力降級。最終,經過它能夠根據不一樣的設備類型、網絡速度和數據存儲模式來自定義不一樣的用戶體驗效果。算法
目前它提供了四種獲取設備性能的hooks能力:網絡狀態、存儲狀態、CPU內核數和內存狀態。瀏覽器
import { useNetworkStatus } from 'react-adaptive-hooks/network';
import { useSaveData } from 'react-adaptive-hooks/save-data';
import { useHardwareConcurrency } from 'react-adaptive-hooks/hardware-concurrency';
import { useMemoryStatus } from 'react-adaptive-hooks/memory';
複製代碼
下面就是一個根據網絡狀態動態加載不一樣資源內容的例子:安全
import React from 'react';
import { useNetworkStatus } from 'react-adaptive-hooks/network';
const MyComponent = () => {
const { effectiveConnectionType } = useNetworkStatus();
let media;
switch(effectiveConnectionType) {
case 'slow-2g':
media = <img src='...' alt='low resolution' />;
break;
case '2g':
media = <img src='...' alt='medium resolution' />;
break;
case '3g':
media = <img src='...' alt='high resolution' />;
break;
case '4g':
media = <video muted controls>...</video>;
break;
default:
media = <video muted controls>...</video>;
break;
}
return <div>{media}</div>;
};
複製代碼
經過Adaptive Loading Hooks工具庫,能夠針對低端手機設備作更多的優化,有效的提高用戶的體驗。性能優化
最大內容渲染 (Largest Contentful Paint - LCP), 頁面阻塞總時長(Total Blocking Time - TBT) 和 累積佈局位移 (Cumulative Layout Shift - CLS) 表明了新一代的性能數據,這些指標將更加聚焦於用戶真實體驗,而不單單是初始化加載時間例如首次內容加載時間(FCP)和首次有意義內容加載(FMP)。bash
最大內容渲染 - LCP LCP - Largest Contentful Paint,表明在viewport中最大的頁面元素加載的時間。LCP的數據會經過PerformanceEntry對象記錄,每次出現更大的內容渲染,則會產生一個新的PerformanceEntry對象。
相關信息能夠查看:
頁面阻塞總時長 - TBT
TBT彙總全部加載過程當中阻塞用戶操做的時長,在FCP和TTI之間,任何long task中阻塞部分都會被彙總到TBT。如上圖所示,有三段JS執行時間(120ms、30ms、75ms),每段JS執行過程當中超過50ms的部分會被記錄成阻塞時間,所以這個例子中頁面阻塞總時長就是70+25=95ms。
累積佈局位移 - CLS
頁面元素的佈局位移會致使用戶操做的不便,所以,Chrome團隊講在頁面加載過程當中全部發生布局位移的元素進行統計,而且經過位移的距離和發生位移的內容來進行計算。
Lighthouse 6發生了比較明顯的變化,頁面性能分數的計算會根據上述性能指標發生很大變化。首次CPU空閒時間和首次有意義內容渲染時間被頁面阻塞總時長和最大內容渲染時間替代。在計算分數時候,首次加載和頁面交互相關指標會獲得調整權重,二者會更加平衡。累積佈局位移指標未來也會被加入到Lighthouse分數中。
Google在爲網站性能優化上作出了很是多的貢獻,此次的大會上也是提出了許多優化改進的內容。Chrome研發團隊增長了Chrome瀏覽器加載緩慢網站的提示,提供了一個React hooks的工具集幫助更好適配低端手機,增長了三個關於性能的指標,同時也調整了Lighthouse分數的計算規則。
『奶爸碼農』從事互聯網研發工做10+年,經歷IBM、SAP、陸金所、攜程等國內外IT公司,目前在美團負責餐飲相關大前端技術團隊,按期分享關於大前端技術、投資理財、我的成長的思考與總結