我閱讀了有關呈現樹的內容，以及它是如何由 CSSOM 和 DOM 樹組成的，我希望在我的網站上實作最佳的 UI 性能。
我想知道 - 我可以為外部 CSS 檔案提供哪些最佳實踐，從而使 CSSOM 的速度最快，從而使呈現樹的構造最快？
uj5u.com熱心網友回復：
首先，用gulp或其他工具或在線工具將你的style.css最小化，例如Cssminifier，將你的style.css轉換成style.min.css，然后將其添加到網站的標題中，如下所示。.
< link rel="styleheet" href="style。 min.css">
uj5u.com熱心網友回復：
如何在網頁瀏覽器中最大化網頁的渲染效果
我必須警告你，當涉及到緩慢的網站渲染時，CSS根本不是一個問題。小型CSS文本檔案的下載速度極快。今天，你在CSS設計中所能改變的東西很少，這對你的影響很小，因為大多數外部CSS檔案與其他下載資源相比都很小。影響性能的主要因素是巨大的JavaScript API庫，緩慢的網路服務器，以及用戶端的不良連接速度。但是你可以使用下面列出的一些技巧，盡管我不建議你為了獲得幾個100毫秒的時間而劫持你的用戶的瀏覽器：
創建一個單一外部樣式表，其中包含渲染你的主頁，或你網站中的首次訪問頁面所需的確切數量的樣式。將所有二級CSS移到一個單獨的頁面（見下文）。這是你的 "同步 "CSS，將在HTML下載、決議和渲染DOM之前加載。使用一個簡單的<link>標簽鏈接到這個檔案。如果這個檔案占用的空間較小，并且你已經洗掉了所有其他的CSS，那么它可以減少HTML下載、決議、渲染和繪制DOM樹的等待時間。 由于HTTP/2、瀏覽器連接的增加、CSS的并行下載以及更快的網路，今天這幾乎不是一個問題。
將所有不必要的JavaScript外部檔案設定為下載時使用"defer"。這意味著它們將按順序加載，但通過共享連接與其他檔案并行，并且不干擾網頁、CSS下載和HTML決議。它們將不會運行，直到所有的HTML和DOM被渲染和繪制，以及：
。
< script src="myscript.js" type="text/javascript" defer="defer" >< /script >/strong>
作為一種選擇，可以考慮設定所有影響您網站所有頁面的外部或全域 JavaScript 檔案，但這些檔案需要繪制 DOM，從而使它們以 "異步 "方式下載。像 "延遲 "一樣，這些檔案不會阻止HTML的渲染，但是一旦這些異步檔案出現，它們就會阻礙頁面的渲染。避免這種代碼，除非這些腳本檔案對DOM的渲染是必須的，而且非常小。在過去，我們把這些外部腳本鏈接放在網頁底部的body元素內最后一個HTML之后。這樣，它們只有在HTML被下載后才開始下載。但這個異步功能支持時，可能會稍微加快這個程序。請確保在運行你的異步腳本之前進行Windows.load或其他技巧來驗證頁面是否被渲染。
< script type="text/javascript" src="{your path}/MyJavaScript.js?v=1.0.0.0" async="async" >< /script >
- 所有其他你不需要在主頁上渲染，但可以在DOM之后加載的CSS，將它們設定為 "預加載"。然而，
<link>標簽中的preload屬性在現代瀏覽器中還沒有100%的支持，在舊的瀏覽器中也沒有（HTML5之前）。因此，使用下面這個 "列印 "技巧，讓瀏覽器通過 "佇列 "下載這些CSS外部檔案，這通常意味著它們在資源的順序中最后下載，而且是在DOM已經渲染之后。這種 "列印 "媒體型別的技巧有非常廣泛的瀏覽器支持。瀏覽器已經用media=print鏈接的樣式表自然地做了20多年，所以這只是一個 "黑客"，強迫常規樣式表使用這種模式。
< link rel="styleheet" href="style.css" media="print" type="text/css" onl oad="this.media='screen';this.onload=null;" / >
確保你的服務器使用HTTP/2，它帶有multiplexing。它只是一個愚蠢的術語，意味著從瀏覽器下載的檔案現在可以通過一個連接進行連接和下載，如果需要的話，而且是并行的。但是，在當今快速網路連接的現代瀏覽器中，很少需要這樣做，除非你的頁面中有很多需要下載的腳本和媒體檔案。如果你這樣做，我會質疑你網站的設計。
有一些prefetch、prerender、preconnect和其他
<link>技巧，你可以添加，盡管在大多數情況下，它們不會給你帶來巨大的速度提升，因為大多數服務器和瀏覽器協商所有這些連接的速度相當快。許多這些連接已經被主機供應商等快取了。這些可能會影響到貧窮國家的手機用戶，他們的設備必須通過遙遠的西方服務器協商未快取的DNS。但是，這里有一些 "技巧"：
在外部 URL 或您的頁面需要快速訪問內容的網站下方添加 DNS 預取呼叫。這些將啟動對未快取的DNS路由的呼叫，并為瀏覽器使用這些連接做準備。
< link rel="dns-prefetch" href="//somewebsite.com"。/ >
將下面的預連接呼叫添加到您的頁面需要快速訪問內容的外部URL或網站。
< link rel="preconnect" href="/somewebsite.com" / >
將下面的資源預取呼叫添加到您希望用戶在訪問您的主頁之后訪問的其他頁面的資產中。這些檔案將被快取，但對瀏覽器來說，呼叫的實施是可選的。這就假設你的用戶會在點擊網站后訪問這些資源，但這往往不是真的。所以我會避免這樣做。注意：瀏覽器對該功能的支持是有限的。
< link rel="prefetch" href="someresource.jpg" / >/strong>
在網頁和所有你希望用戶在瀏覽完當前網頁后訪問的相關資源上添加下面的資源預渲染呼叫。這些檔案將被快取，但對瀏覽器來說，執行該呼叫是可選的。如上所述，你需要假設用戶會導航到這些快取的網頁。另外，"預渲染 "不僅要下載頁面和資源，還要建立DOM，運行JavaScript，然后在用戶點擊鏈接時切換出頁面。這意味著你要求瀏覽器使用更多的CPU，對于用戶可能永遠不會訪問的頁面來說，這是一種浪費。我相信，這只在現代的Chrome瀏覽器中有效。注意：瀏覽器對這一功能的支持是非常有限的。
< link rel="prerender" href="somewebpage.html" / >
給你所有的圖片、iframe、視頻和其他HTML媒體元素一個
width和height屬性，這樣瀏覽器就可以在下載這些專案的時候，為這些圖片保留畫布空間。這主要是為了防止布局的轉變，但如果瀏覽器進行了幾次繪制，則可以給你帶來速度。給你所有的
。<img>元素一個loading="lazy"屬性，這意味著它們在用戶向下滾動網頁時才會加載。這只在現代的HTML 5瀏覽器中起作用。給您的所有
<video>、<audio>等一個preload="metadata"屬性，這意味著它們在用戶向下滾動網頁之前不會加載和播放。這只在現代HTML 5瀏覽器中起作用。
請記住，這些針對 CSS 和其他東西的大多數黑客和技巧很少是導致網站緩慢的罪魁禍首。當涉及到瀏覽器的渲染速度時，CSS最近才得到了一個不好的評價，而它根本就是100%不真實的。CSS預加載和最小化是沒有問題的解決方案，一些搜索引擎（即谷歌）已經要求開發者實施，但這對整個頁面渲染和繪畫性能的影響很小，與這些新的巨大的JavaScript API的下載相比，頁面排名更差。改變CSS設計就像從蘿卜上擠血一樣。今天沒有證據表明改變CSS架構或下載策略對頁面渲染有任何重大影響。這些科技公司現在已經開始擺脫這種神話了。此外，近 25 年來，CSS 在瀏覽器中的下載速度一直快如閃電，沒有任何額外的幫助。
那么，隨著 5G 和光纖互聯網的發展，為什么在下載 20 千位元組的 CSS 時會突然出現延遲？
事實是，不存在延遲。這幾乎是零。例如，如果你的 CSS 只有幾十 KB，那么對 CSS 和 HTML 進行最小化處理就毫無意義。與1-5兆位元組的JavaScript、影像、視頻或其他資源相比，一個典型的CSS檔案是非常小的，今天下載到一個典型的網路瀏覽器。很多CSS檔案小于100Kb，但在今天的典型網站中，即使在最小化之后，大多數CSS檔案可能也小于30Kb。如果你在你的網站中使用外部腳本和樣式，它們將在用戶的瀏覽器中被長期快取。用戶對網站的重訪將在數天、數周甚至數月內重復使用這些相同的樣式表，并在從瀏覽器快取中提取時保持您的頁面呈現速度快如閃電，相比之下，使用嵌入式樣式（許多 JavaScript API 使用這種樣式）將強制重新加載相同的 CSS。
此外，如今的 Web 瀏覽器在協商 DNS 呼叫和服務器連接方面非常聰明，盡管過去的瀏覽器默認只有兩個連接（如今許多瀏覽器默認使用 6 個連接）。這意味著在HTML決議和渲染開始之前，外部CSS和腳本往往會并行下載，而且速度非常快。因為你永遠不希望看到沒有風格的HTML，這種設計非常好，可以防止沒有風格的HTML的flash。現在有些孩子利用上面提到的技巧劫持了這個自然的瀏覽器程序，這可能會造成巨大的混亂，布局會發生變化，單執行緒腳本會占用手機的CPU來操作DOM，腳本渲染的HTML布局會跳動，或者一半的網頁無法加載文本內容。未經壓縮的影像、點播視頻、大型下載檔案和巨大的JavaScript庫造成了網頁中最主要的延遲。因此，請相信我......CSS不是問題所在！ 巨大的Megority檔案是一個很好的例子。
巨大的百萬位元組的阻塞性 JavaScript 往往是罪魁禍首！ 許多客戶端應用程式都是由一個或多個 JavaScript 庫組成。
今天，許多客戶端的JavaScript API只能通過試圖劫持瀏覽器并在主頁上預裝非常小的檔案來解決其巨大的有效載荷問題，但在幕后對大量的腳本庫、HTML 頁面和資源進行巨大的呼叫，并假設用戶可能訪問網站中的其他頁面。這可能是一場賭博，如果用戶沒有點擊他們所期望的地方，這將是非常浪費和不必要的。它在一個典型的網路瀏覽器中加載了數兆位元組的快取但不必要的腳本和資源。如果你問我，這些腳本馬戲團的把戲顯然是一個考慮不周的模型。
保持重度的服務器端，而不是重度的客戶端，你的頁面將快如閃電！ 由于這些原因以及更多的原因，你的頁面將變得越來越快。
由于這些原因以及其他原因，如前所述，我將避免使用 CSS 和 HTML 的 "速度 "技巧，而專注于所有其他瓶頸問題。
標籤：