Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537 Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537
述:瀏覽器渲染一共有五步
具體如下圖過程如下圖所示
二、瀏覽器渲染五個階段
2.1 第一步:解析HTML標簽,構建DOM樹
在這個階段,引擎開始解析 html ,解析出來的結果會成為一棵 dom 樹
dom 的目的至少有 2 個
getElementById
當解析器到達script標簽的時候,發生下面四件事情
由此可以得到第一個結論1
2.2 第二步:解析CSS標簽,構建CSSOM樹
通過以下手段可以減輕cssom帶來的影響
2.3 第三步:把DOM和CSSOM組合成渲染樹(render tree)
2.4 第四步:在渲染樹的基礎上進行布局,計算每個節點的幾何結構
布局( layout ):定位坐標和大小,是否換行,各種 position , overflow , z-index 屬性
2.5 調用 GPU 繪制,合成圖層,顯示在屏幕上
將渲染樹的各個節點繪制到屏幕上,這一步被稱為繪制 painting
三、渲染優化相關
3.1 Load 和 DOMContentLoaded 區別
3.2 圖層
一般來說,可以把普通文檔流看成一個圖層。特定的屬性可以生成一個新的圖層。不同的圖層渲染互不影響,所以對于某些頻繁需要渲染的建議單獨生成一個新圖層,提高性能。但也不能生成過多的圖層,會引起反作用。
通過以下幾個常用屬性可以生成新圖層
3.3 重繪(Repaint)和回流(Reflow)
重繪和回流是渲染步驟中的一小節,但是這兩個步驟對于性能影響很大
color
回流必定會發生重繪,重繪不一定會引發回流。回流所需的成本比重繪高的多,改變深層次的節點很可能導致父節點的一系列回流
以下幾個動作可能會導致性能問題
window
很多人不知道的是,重繪和回流其實和 Event loop 有關
3.4 減少重繪和回流
使用 translate 替代 top
for(let i = 0; i < 1000; i++) { // 獲取 offsetTop 會導致回流,因為需要去獲取正確的值 console.log(document.querySelector('.test').style.offsetTop) }
要:在本文中,將重點關注網頁的初始渲染,即它從解析 HTML 開始。 我將探索可能導致高渲染時間的問題,以及如何解決它們。
本文分享自華為云社區《頁面首屏渲染性能指南-云社區-華為云》,作者:Ocean2022。
我們知道渲染頁面是一個將服務器的響應內容翻譯成圖片的過程。但是,如果你頁面的渲染性能比較糟糕的話,可能會帶來相對較高的跳出率。
在本文中,我將重點關注網頁的初始渲染,即它從解析 HTML 開始。 我將探索可能導致高渲染時間的問題,以及如何解決它們。
關鍵渲染路徑 (CRP) 是瀏覽器將代碼轉換為屏幕上可顯示像素的過程。 它有幾個階段,其中一些可以并行執行以節省時間,但有些部分必須依次完成。 如下圖所示:
首先,一旦瀏覽器得到響應,它就會開始解析它。 當它遇到依賴項時,它會嘗試下載它。 如果它是一個樣式表文件,瀏覽器必須在渲染頁面之前完全解析它,這就是為什么 CSS 會阻塞渲染的原因。
如果是腳本,瀏覽器必須:停止解析,下載腳本,然后運行。 只有在那之后它才能繼續解析,因為 JavaScript 程序可以改變網頁的內容(尤其是 HTML)。 這就是為什么 JS 會阻塞解析的原因。
完成所有解析后,瀏覽器將構建文檔對象模型 (DOM) 和級聯樣式表對象模型 (CSSOM)。 將它們組合在一起得到渲染樹。 頁面的不顯示部分不會進入渲染樹,因為它只包含繪制頁面所需的數據。
倒數第二步是將渲染樹進行布局, 這個階段也稱為回流:就是計算每個渲染樹節點的每個位置及其大小的地方。
最后一步是繪制。 它會根據瀏覽器在前一階段計算得到的數據對像素進行著色。
因此,根據這一過程,我們在優化性能方面,得出了一些結論。如果你要提升頁面初始化渲染的性能,你需要:
同時,我們會根據下面 3 個指標來衡量優化的效率:
除了渲染時間之外,還有其他一些因素也需要考慮。例如,你的頁面使用了多少阻塞資源以及下載它們需要多長時間。
鑒于我們在上面得出的結論,我們得出網站性能優化有三種主要策略:
首先,移除所有未使用的部分,例如 JavaScript 中無法訪問的函數、帶有從不匹配任何元素的選擇器的樣式以及被 CSS 永遠隱藏的 HTML 標簽。 其次,刪除所有重復項。
然后,我建議建立一個自動壓縮過程。 例如,它應該從你的后端服務中刪除所有注釋(但不是源代碼)以及每個不包含附加信息的字符(例如 JS 中的空白字符)。
完成后,我們剩下的可以是文本字符串。 這意味著我們可以安全地應用諸如 GZIP(大多數瀏覽器都理解)之類的壓縮算法。
最后,還有緩存。 瀏覽器第一次呈現頁面時它不會有幫助,但它會在以后的訪問中節省很多。 但是,記住兩點至關重要:
當然,應該為每個資源定義緩存策略。 有些可能很少改變或根本不會改變,有的則是變化的很快,還有些文件包含敏感的信息(可以使用 “private” 防止 CDN 緩存私有數據)。
“關鍵”僅指網頁正確呈現所需的資源。 因此,我們可以直接跳過所有流程中沒有涉及的樣式以及腳本文件。
為了告訴瀏覽器不需要特定的 CSS 文件,我們應該為所有引用樣式表的鏈接設置媒體屬性。 使用這種方法,瀏覽器將只根據需要處理與當前媒體(設備類型、屏幕尺寸)匹配的資源,同時降低所有其他樣式表的優先級。 例如,如果你將 media=“print” 屬性添加到引用樣式以打印頁面的樣式標記,則這些樣式不會在不打印媒體時干擾你的關鍵渲染路徑。
為了進一步改進該過程,你還可以將一些樣式內聯,這可以為我們節省了至少一次到服務器的往返行程。
如上所述,腳本會阻塞解析,因為它們可以改變 DOM 和 CSSOM。 為了避免這一點,所有腳本標簽都必須用屬性標記——異步或延遲。
標有 async 的腳本不會阻塞 DOM 構建或 CSSOM,因為它們可以在 CSSOM 構建之前執行。 但請記住,內聯腳本無論如何都會阻止 CSSOM,除非你將它們放在 CSS 之上。
相比之下,標有 defer 的腳本將在頁面加載結束時進行執行。
換句話說,使用 defer,腳本直到頁面加載事件被觸發后才會執行,而 async 讓腳本在文檔被解析時就會在后臺運行。
最后,應將 CRP 長度縮短到可能的最小值。
作為樣式標簽屬性的媒體查詢將減少必須下載的資源總數。 script 標簽屬性 defer 和 async 將防止相應的腳本阻塞解析。
使用 GZIP 壓縮、壓縮和歸檔資源將減少傳輸數據的大小(從而也減少數據傳輸時間)。
內聯一些樣式和腳本也可以減少瀏覽器和服務器之間的往返次數。
按照最新的最佳性能實踐理念,一個網站應該做的最快的第一件事就是展示 ATF 內容。 ATF 代表首屏。 這是立即可見的區域,無需滾動。 因此,最好以首先加載所需樣式和腳本的方式重新排列與渲染相關的所有內容,而其他所有內容都停止(既不解析也不渲染)。
總而言之,網站性能優化包含了網站響應的各個方面,例如緩存、設置 CDN、重構、資源優化等,但是所有這些都可以逐步完成。 作為 Web 開發人員,你可以將本文作為參考,并始終記住在實驗之前和之后測量性能。
瀏覽器開發人員盡最大努力優化你訪問的每個頁面的網站性能,這就是瀏覽器通常實現所謂的“預加載器”的原因。 這部分程序會在你以 HTML 格式請求的資源之前進行掃描,以便一次發出多個請求并讓它們并行運行。 這就是為什么在 HTML(逐行)以及腳本標簽中保持樣式標簽彼此靠近的原因。
此外,嘗試批量更新 HTML 以避免多個布局事件,這些事件不僅由 DOM 或 CSSOM 中的更改觸發,而且在設備方向更改和窗口大小調整時也會觸發。
點擊下方,第一時間了解華為云新鮮技術~
華為云博客_大數據博客_AI博客_云計算博客_開發者中心-華為云
覽器解析HTML文件的過程是網頁呈現的關鍵步驟之一。具體介紹如下:
HTML文檔的接收和預處理
解析為DOM樹
CSS解析與CSSOM樹構建
JavaScript加載與執行
渲染樹的構建
布局計算(Layout)
繪制(Paint)
因此,我們開發中要注意以下幾點:
綜上所述,瀏覽器解析HTML文件是一個復雜而高度優化的過程,涉及從網絡獲取HTML文檔到最終將其渲染到屏幕上的多個步驟。開發者需要深入理解這些步驟,以優化網頁性能和用戶體驗。通過合理組織HTML結構、優化資源加載順序、減少不必要的DOM操作和合理安排CSS和JavaScript的加載與執行,可以顯著提升頁面加載速度和運行效率。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。