切圖崽的自我修養－提升項目加載速度

前言

個人項目沒問題，是用戶的網絡環境不夠好

前端做爲一個最貼近用戶的技術工種，毫無疑問應該把戶體驗放在第一位. 而用戶體驗，基本正比於頁面的打開速度，特別是作移動端的同窗，因此如何優化本身的項目，提升頁面的加載速度成爲重中之重.

---

資源的下載及解析

對前端同窗來講，弄清楚頁面上資源的下載和解析順序是及其重要的，知道了它們的加載順序，就知道對於特定的場景，應該如何去優化. 通常來講，頁面上的資源無非這麼幾種:

• Html

• Css

• Js

• Img

---

資源加載的特性

• Html: 邊下載邊解析，最終造成DOM樹

• Css: 邊下載邊解析，解析成css樹，而且每加載一個新的css文件，都會從新整合以前下載的css生成新Css樹，最終構建完的css樹會和DOM樹結合成Render樹，並被瀏覽器渲染

• JS: 下載完再當即逐行解析執行

• Img: 當HTML解析到<img>等標籤的時候會像服務器發起下載對應img的請求，下載是並行的

---

資源加載的相互影響

那麼各資源的下載和解析對其餘的資源的下載和解析是否存在影響呢？

• Html: Html不論是下載仍是解析都不會影響後續資源的下載和解析，當自身解析到link標籤時，會並行下載css資源. 解析到img標籤時，會並行下載img資源

• Css: Css的下載不會影響後續資源的下載和解析，Css的解析雖然不會影響到後續資源的下載，但會影響到後續資源的解析

• Js: Js不管是下載仍是解析都會阻塞後續資源的下載及解析

• Img: Img的下載和呈現對後續資源的下載和解析無影響

( 特別注意，是"後續資源" )

---

罪魁禍首

從上咱們能夠知道，資源的相互阻塞主要來自於css和js

• 首先是js, 只要html解析到了script標籤，就開始下載js，這個標籤後的全部資源的下載和解析所有停滯. js下載完成以後，會馬上執行，執行的時候，一樣會堵塞後續資源的下載和執行.直到該js執行完成 (緣由在於js可能會改變dom結構和css屬性致使重繪，因此在js下載和執行的時候對對後續的dom的創建顯得很不必)

• 而後是css, css解析的時候，會阻礙後續全部資源的解析.特別是js, js雖然是下載完就馬上執行，但其實它必需要等到它以前的css所有解析完畢以後才能解析.

因此咱們能夠看出來，Css和Js都會影響到後續文件的下載和解析

---

優化目標

當用戶可以在1-2秒內打開頁面，看到信息的展現，或者可以開始進行下一步的操做，用戶會感受速度還好，能夠接受. 而頁面若是在2-5秒後才進入可用的狀態，用戶的耐心會逐漸喪失. 而若是一個界面超過5秒甚至更久才能顯示出來，這對用戶來講基本是沒法忍受的，也許有一部分用戶會退出從新進入，但更多的用戶會直接放棄使用。

對於頁面呈現來講，不論是pc端仍是移動端，最最重要一點是能讓用戶儘量快的看到儘量多的樣式和內容. 因此業界有了所謂1秒鐘法則:

2g網絡：1秒內完成dns查詢、和後臺服務器創建鏈接
3g網絡：1秒內完成首字顯示（首字時間）
wifi網絡：1秒內完成首屏顯示（首屏時間）

---

優化措施

咱們想讓用戶儘快地看到儘量多的內容和樣式，除了保證各加載資源在知足需求的狀況下體積儘量的小，還要保證各資源正確的加載順序，防止資源的相互阻塞:

1. 減小html中沒必要要的標籤(好比div, 加快dom樹的生成)

2. 把css放在頭部(以便可以更快的生成css樹，從而儘快地dom樹結合成render樹，從而可以以最快的速度被瀏覽器渲染出來)

3. js放在尾部(或者用 window.onload 等到頁面徹底加載完成以後再執行)

4. 減小資源文件大小(壓縮img,css,js)

5. 將大img切成多份小img加快加載速度(因爲img是並行加載)

同時，因爲在http請求的發送和迴應上會消耗很大一部分時間，因此如何儘可能減小 http請求也是優化的大頭:

1. 合併css文件

2. 打包合併js文件

3. 採用sprite合成img

---

結語

總之，優化是一個很好的習慣. 可是，從工程的角度來說，過分優化有時會形成很高昂的代價. 因此，一個好的工程師，不只僅知道該怎麼優化，更重要的是知道這裏該不應優化.

以上是從一些很通用且淺顯的角度來分析如何優化本身的項目.後續會慢慢講到更多的優化技巧，好比js的延遲加載，按需加載等等，敬請期待