程序員web前端培訓HTMLCSS學習筆記之頁面優化

1）頁面主題優化

實事求是的寫下自己網站的名字，網站的名字要合理，最好包含網站的主要內容。

2）頁面頭部優化

<meta name="keywords" content="" />向搜索引擎說明你的網頁的關鍵詞；<meta name="description" content=""/>告訴搜索引擎你的站點的主要內容；

說明

1、“描述”部分應該用近乎描述的語言寫下一段介紹你網站的文字，在這其中，你應該適當的對你網站的特色內容加以重復以求突出；

2、“關鍵字”部分應該列出你認為合適的，能突出網站內容的關鍵字就可以了，關鍵字不要設置太多，可設置10---8個，搜索引擎只會瀏覽靠前的幾個關鍵字。

3）超鏈接優化

1、采用純文本鏈接，少用，最好是別用Flash動畫設置鏈接，因為搜索引擎無法識別Flash上的文字.

2、按規范書寫超鏈接，這個title屬性，它既可以起到提示訪客的作用，也可以讓搜索引擎知道它要去哪里.

3、最好別使用圖片熱點鏈接，理由和第一點差不多

4）圖片優化

圖片優化并不是修改圖片的大小、顏色，而是你應該為每個標簽加上alt屬性，alt屬性的作用是當圖片無法顯示時以文字作為替代顯示出來，而對于SEO來說，它可以令搜索引擎有機會索引你網站上的圖片，對于一些確實沒什么意義的圖片，最好也不要省略alt，而應該留空，即 alt=""。

5）PageRank（pr值,友情鏈接）

PR值是Google提出的一個重要參數，它標明了某個網站的重要程度，那么pr值是如何確定的呢？目前普通的解釋為：假如有ABC三個網站，彼此互作友情鏈接，那么當一個訪客通過A上的友情鏈接來到B時，Google就認為A為B投了“一票”，同理，如果有人從C訪問B，那么B又得一票，如果全世界的網站上都有B的友情鏈接，B就是世界上最重要的網站了！

可以擴展：回流(resflow) & 重繪(repaint)

· 頁面的渲染流程

什么是DOM樹

什么是樣式結構體

什么是呈現樹

?

呈現樹的特點

圖片整合（精靈圖、css sprites、css精靈、雪碧圖）

把網站里面的小圖標有規則的整合在一起，利用 background-position 改變背景圖的位置，每個圖標應用。

優點:

（1）CSS Sprites能很好地減少網頁的http請求，從而大大的提高頁面的性能，這是CSS Sprites最大的優點，也是其被廣泛傳播和應用的主要原因；

（2）CSS Sprites能減少圖片的字節；

（3）CSS Sprites解決了網頁設計師在圖片命名上的困擾，只需對一張集合的圖片命名，不需要對每一個小圖片進行命名，從而提高了網頁制作效率。

（4）CSS Sprites只需要修改一張或少張圖片的顏色或樣式來改變整個網頁的風格。

缺點:

（1）圖片合并麻煩：圖片合并時，需要把多張圖片有序的合理的合并成一張圖片，并留好足夠的空間防止版塊出現不必要的背景。

（2）圖片適應性差：在高分辨的屏幕下自適應頁面，若圖片不夠寬會出現背景斷裂。

（3）圖片定位繁瑣：開發時需要通過工具測量計算每個背景單元的精確位置。

（4）可維護性差：頁面背景需要少許改動，可能要修改部分或整張已合并的圖片，進而要改動css。在避免改動圖片的前提下，又只能（最好）往下追加圖片，但這樣增加了圖片字節。

文旨在整理常見Web前端性能優化的思路，可供前端開發參考。因為力求精簡，限于篇幅，所以并未詳述具體實施方案。

基于現代Web前端框架的應用，其原理是通過瀏覽器向服務器發送網絡請求，獲取必要的index.html和打包好的JS、CSS等資源，在瀏覽器內執行JS，動態獲取數據并渲染頁面，從而將結果呈現給用戶。

在這個過程中，有兩個步驟可能較為耗時，一個是網絡資源的加載，另一個是瀏覽器內代碼執行和DOM渲染。

而耗時的增加會導致頁面響應慢，卡頓，影響用戶體驗。

針對上述兩種耗時的情況，常見的優化方向有：

1. 縮短請求耗時；
2. 減少重排重繪；
3. 改善JS性能。

1 縮短請求耗時

網絡資源是Web應用運行的基礎，改善網絡資源加載速度會顯著改善前端性能。

1.1 優化打包資源

總體原則： 減少或延遲模塊引用，以減少網絡負荷。

常用工具：

• webpack
• webpack-bundle-analyzer可視化分析工具

常用方法：

• 減小體積：減少非必要的import；壓縮JS代碼；配置服務器gzip等；使用WebP圖片；
• 按需加載：可根據“路由”、“是否可見”按需加載JS代碼，減少初次加載JS體積。比如可以使用import()進行代碼分割，按需加載；
• 分開打包：利用瀏覽器緩存機制，依據模塊更新頻率分層打包。

其他方法：

• 雪碧圖：每個HTTP/1.1請求都是獨立的TCP連接，最大6個并發，所以合并圖片資源可以優化加載速度。HTTP/2已經不需要這么做了。

1.2 CDN加速

總體原則： 通過分布式的邊緣網絡節點，縮短資源到終端用戶的訪問延遲。
常用工具：

• Cloudflare
• AWS CloudFront
• Aliyun CDN

常用方法：

• 加速圖片、視頻等大體積文件

1.3 瀏覽器緩存

總體原則：避免重復傳輸相同的數據，節省網絡帶寬，加速資源獲取。

常用方法：
可以通過設置HTTP Header來控制緩存策略，一般有如下幾種。

• 強緩存
• Expires：HTTP/1.0
• Cache-Control：HTTP/1.1

• 協商緩存
• ETag + If-None-Match
• Last-Modified + If-Modified-Since

拿ETag舉例，如果瀏覽器給的If-None-Match值與服務端給的ETag值相等，服務器就直接返回304，從而避免重復傳輸數據。

ETag示例：

如果幾個配置同時存在，則優先級為：Cache-Control > Expires > ETag > Last-Modified。

1.4 更高版本的HTTP

總體原則：使用高版本HTTP提升性能。

常用工具：

• HTTP/2

HTTP/2較HTTP/1.1最大的改進在于：

• 多路復用：單一TCP連接，多HTTP請求，有Demo；
• 頭部壓縮：減少HTTP頭體積；
• 請求優先級：優先獲取重要的數據；
• 服務端推送：主動推送CSS等靜態資源。

其他方法：

• HTTP/3

HTTP/3基于UDP，有很多方面的性能改進，如多路復用無隊頭阻塞，響應更快。感興趣的同學可參考Wiki。

1.5 Web Socket

總體原則：解決HTTP協議無法實時通信的問題。

Web Socket是一條有狀態的TCP長連接，用于實現實時通信、實時響應。

1.6 服務器端渲染（SSR）

總體原則：第一次訪問時，服務器端直接返回渲染好的頁面。

一般流程：

• 瀏覽器向 URL 發送請求；
• 服務器端返回“空白”index.html；
• 瀏覽器不能呈現頁面，需要繼續下載依賴；
• 加載所有腳本后，組件才能被渲染。

SSR流程：

• 瀏覽器向 URL 發送請求；
• 服務器端執行JS完成首屏渲染并返回；
• 瀏覽器直接呈現頁面，然后繼續下載其他依賴；
• 加載所有腳本后，組件將再次在客戶端呈現。它將對現有View進行合并。

常用工具：

• Node.js，用于服務器端執行代碼，輸出HTML給瀏覽器，支持所有主流前端框架
• Next.js，用于服務器端渲染React的框架
• gatsby，用React生成靜態網站的工具

除了可以提升頁面用戶體驗，還能應用于SEO。

2 減少重排重繪

除了網絡資源以外，另一個影響前端性能的因素就是前端頁面的渲染繪制效率。

雖然不同的前端框架有一些差異，但整體的優化思路是一致的，這里將以React舉例。

2.1 減少渲染量

總體原則：不渲染未展示的部分。

常用工具：

• react-window
• react-loadable
• JS原生，如IntersectionObserver
• 框架提供，如React.lazy、react-intersection-observer

常用方法：

• 虛擬列表：只渲染可見區；
• 惰性加載：無限滾動；
• 按需加載：頁面只在切換過去時才加載。

以虛擬列表舉例，以下是使用react-window庫，僅僅渲染了可見區的數據：

2.2 減少渲染次數

總體思路：避免重復的渲染。

常用工具：

• lodash
• JS或框架自帶

常用方法：

• 防抖與節流；
• 對于React函數組件來說，合理使用副作用，拆分無關聯的副作用；
• 對于React類組件來說，可以使用shouldComponentUpdate或使用PureComponent來優化渲染；
• 利用緩存，如React.memo；
• 使用requestAnimationFrame替代setInterval執行動畫。

3 改善JS性能

因為瀏覽器是單線程異步模型，長時間的運算會阻塞渲染過程，所以改善復雜運算有助于改善前端的整體性能。

3.1 緩存復雜計算

總體思路：避免重復計算。

常用方法：

• 對于React函數組件來說，可以使用useMemo緩存復雜計算值。

舉例如下，memoizedValue需要經過復雜計算才能得到，此時就可以使用useMemo緩存，僅僅在輸入參數發生變化時才重新計算，避免計算阻塞頁面渲染，從而避免頁面卡頓。

1const MyFunctionalComponent=()=> {
2 const memoizedValue=useMemo(()=> {
3   computeExpensiveValue(a, b);
4 }, [a, b]);
5
6 return <AComponent value={memoizedValue}/>;
7}

但useMemo自身也有性能消耗，需要視情況使用，某些場景可以利用React的渲染機制避免性能問題，可以參考《Before You memo()》。

3.2 Web Worker

總體原則：多線程思想。

常用方法：

• Dedicated Workers，處理與UI無關的密集型數學計算：大數據集合排序、數據壓縮、音視頻處理；
• Service Worker，服務端推送，或者PWA中配合CacheStorage在前端控制緩存資源；
• Shared Worker，Tab間通信。

JS語言在設計之初就是單線程異步模型，好處是可以高效處理I/O操作，但壞處是無法利用多核CPU。

Web Worker會啟動系統級別的線程，可進行多線程編程，發揮多核的性能。

3.3 Web Assembly

總體原則：將復雜的計算邏輯編譯為Web Assembly，避免JS類型推斷過程中的性能開銷，可用于性能的極限優化。

適用范圍有限：

曾在網上看到，有人使用自頂向下非優化的斐波那契數列算法來舉例，說Web Assembly比原生JS快一倍，實測之后似乎也沒有。

在同一臺機器測試，其中求第48個值的耗時如下：

• C（Ubuntu+GCC）：18s
• JS（V8）：32s
• Web Assembly（V8+EMCC）：39s

一種可能的猜想是，斐波那契計算中沒有大量的類型推斷，而且V8內部有一些優化機制，使得此處JS執行速度快于Web Assembly。

簡而言之，并非所有場景都適用于Web Assembly。

另一種運用場景是，把不同語言編寫的代碼（C/C++/Java等）編譯為Web Assembly，能以接近原生的速度在Web中運行，并且與JS共存。

總結

導致前端性能問題的因素是多方面的。

如果是前端資源加載慢，導致頁面慢，則應該考慮如何縮短請求耗時。而如果是前端頁面邏輯笨重，UI數據量太大，則可以試著從減少重排重繪的角度去優化。對于耗時長的復雜計算，緩存計算結果往往是見效較快的優化方式。

最后需要注意的是，在實際應用開發過程中，因為受限于開發成本，所以需要平衡優化所花的代價與其對應產生的成效。可以有針對性地對性能瓶頸進行分析和處理，同時也需要避免引入不必要的優化措施，以確保最終優化效果。

文/Thoughtworks嚴文

原文鏈接：https://insights.thoughtworks.cn/web-frontend-performance-tuning/

更多精彩洞見，請關注微信公眾號Thoughtworks洞見。

.translate3d{
 -webkit-transform: translate3d(0, 0, 0);
 -moz-transform: translate3d(0, 0, 0);
 -ms-transform: translate3d(0, 0, 0);
 transform: translate3d(0, 0, 0);
}