開發人員所需要知道的HTML5效能分析面面觀_html5教學技巧

     從效能角度來說，HTML5首先是縮減了HTML文檔，使這件事情變得更簡單。
第一，從用戶可讀性上說，原先一大堆東西，像初學者第一次看到這些東 西是看不懂的，而HTML5的聲明方式對用戶來說顯然更友好一些。
第二，文件編碼的聲明，用HTML5方式的話，就很簡單。很多人問HTML5是什麼?我們說可以先用HTML5的方式就是把DOCTYPE先改了，因為目 前很多頁面都還是用傳統的方式。 HTML5的方式，本身是相容於IE瀏覽器的，從IE6到IE10都可以，包含進階瀏覽器都支援。所以說擁抱HTML5最簡 單的方式就是把DOCTYPE給改了。

　　1.更簡潔的標籤
　　接下來可能並不是一件很常見的事情，但是卻是我比較推崇的，使用更簡潔的標籤方式。 HTML5從這個名字大家可以聽出，它是從HTML4繼承過來 的。 HTML4裡面有嚴格模式跟過渡模式，HTML5是支援這個過渡模式的，就是你可以不把一些標籤閉合。但是，我並不推薦所有的標籤，比方說BODY標 籤的不閉合，這種我們不推薦。但是像P標籤最常用的，還有列表標籤LI。為什麼這樣說?先從視覺的角度來說，這樣的方式更簡潔一點。然後關鍵的是在文件 傳輸過程中，內容會更少。
　　HTML5標籤屬性的聲明支援三種方式：單括號、雙括號和不加括號。為了減少文件大小，我是選擇不加雙引號的方式或單引號的方式。但是要注意，假設 是類屬性的聲明，因屬性可能包括多個類，多個類的時候則必須用括號括起來。在這方面，給大家看一下谷歌的一個實踐。谷歌自己有一個頁面完全實踐了上面的東 西，文檔的大小減少了20%，使HTML文檔的傳輸減少了20%。如果把整個都實踐起來，可以達到5%—20%之間的減少。這是第一步，縮減HTML文件 的大小。
　　2.圖片優化
　　接下來是關於圖片的優化，圖片永遠是又愛又恨的元素。因為圖片多的時候，會嚴重拖垮整個頁面的載入速度。關於圖片的最佳化方式，《高效能網站》書中已有很多介紹，總結起來主要有三點：使用精靈圖、優化圖片的大小，使用DATA URI，具體這裡就不細說了。
　　圖片優化的另一個想法是：no-image。拋棄圖片，擁抱CSS3。原先需要設定一張圓角效果的圖片，現在使用CSS3中的border-radius;原先需要設定陰影效果的圖片，現在使用CSS3中的box-shadow;原先需要設定漸變的背景圖片，現在使用CSS3中的gradient。
　　3.預取
　　接下來講Prefetching，預取，是優化的另一個思路。我們現在優化的思路無非就是少。很多都是從少的角度，比方說前面把文檔大小減少，把圖 片的大小減少。很多張的圖片變成一張精靈圖，都是為了把發送請求的數量減少。預取的話，是另一種思路，提早加載好資源，用戶去點的時候，實際上已經加載 好，那肯定是更快了。
　　預取，一共有兩部分：一部分是資源的預取，還有一部分是DNS的預解析。
　　資源預載有幾個點要注意：
　　預載只是在瀏覽器空閒的時候才會去拉，但不保證一定會去拉，這是很重要的一點。因為本身瀏覽器有一個全域的監聽器，這是內部的一個接口，當瀏覽氣空閒的時候，它會去執行瀏覽器空閒的時候應該做事情，但是這個空閒的回調不一定被觸發，所以說並不保證一定會執行預先載入。
　　Chrome不支援HTTPS資源的預先加載，像Alipay是HTTPS的頁面，Chrome不會去預付。
　　一個預拉取的頁面雖存在後不可見，實際上它是在正常解析。假如說我預拉取登陸頁面，登陸頁面有很多資源，比方說有圖片，有CSS文件，JS文件。它 是從上往下正常的會被解析，解析的過程中，這個頁面沒有顯現，但是它實際上是存在的。在HTML5裡面，可透過 document.visibilityState得到目前頁面狀態，通常頁面有兩種狀態，可見與不可見，但現在有新的狀態，叫做預先渲染的狀態。可 以直接透過document.visibilityState 是否等於 prerender 來判斷頁面是否在預先渲染狀態。
　　4.DNS解析
　　接下來是關於DNS的解析。有時候我們登入頁面，對用戶可能點的地方相對而言是比較難探測到，當然有時候我們會做一些埋點來探知用戶下一步行為大部 分是往裡走。但有些情況下，我們不知道使用者下一步具體會走到哪一個頁面的時候，但是我們知道他要走到哪一個網域。這個時候，我就可以預解析DNS。因為實際 上，整個頁面的請求過程中間有一個很長的DNS的解析過程，如果說這個我們提前做了，就可以更進一步讓用戶看到這一頁。
　　以下是Q 壁紙的案例。 Q 壁紙是Q 某一個系統系統，首先Q 整個的架構是基於WEB 用戶端。我們現在看到的就是一個WEB的頁面，雖然它外面是一個客戶端的殼，但是它的心是WEB的。整個過程在我們第一次在完成的時候，因為圖片比較多， 所有的靜態資源是分配到十幾個靜態伺服器上。也就是說，如果我要去拉的時候，我就要解析10個DNS，這個時間是相當耗時的，最慢的時候可能會延遲幾秒 鐘，這是我們肉眼能感覺到的。如果進行DNS預解析，因為本身資源我不知道具體是哪一個，所有圖片都是隨機的，所以我們只能說在DNS預解析上下功夫，來 提升它的速度。這樣的話，從原來可能要2秒鐘，我就變成1秒鐘。
　　接下來講Q 的應用。我們會像QQ裡面一樣，QQ裡面跟Q 都有很多文字鏈，就是視窗的左下角有一個文字APP訊息的推送。這邊是透過WEB時時 去拉取後端，後端拉取過來然後在前台顯示。但在某一個時期，其實所有的APP它一共推送的營運資訊是固定的。如果說按某個具體APP去分析每個文字鏈對 應數組的話，這個時候是非常大數據。因為這裡一個大概有達到三四百個字節，從優化的角度說，我們把這些每次拉區過來的存在本地。再存上本地的 localStorage，我們是同一域，所有的APP之間的資訊都是可以互相存取的。然後就是把所有拉過的ID，就不會再重新拉一次。
　　在這裡也有一個需要注意的點，localStorage目前很多廠商的實作是同步的。如果你大量地呼叫localStorage這個接口，實際上他 會阻塞你的渲染程序。這時候，當用戶往下拖動頁面的時候，然後你這個時候又正好在做存儲數據，這個數據又比較大，這時候用戶就會感覺你這個頁面非常 卡。之前他們都有討論這個問題，本身這個介面的設計IE是設計成非同步的，他們設計成同步。這會導致在調這個藉口的時候，假設你程式比較多，因為有一個 序列化的過程，序列到磁碟。這樣的話，整個過程就會顯得比較慢。再加上本身localStorage可以做不同的視窗之間共享這個數據，它會在這個數據上 加鎖。如果大量地資料在調用這個本地接口，它就會顯得比較卡。所以目前沒有什麼特別好的解決方案，但這是需要記住的。即使說目前最大的五點多兆，如果你 用了五點多兆，會讓用戶很悲催。因為如果一去呼叫這個藉口，用戶在拖用滑鼠，就覺得非常卡。
　　5.離線儲存
　　接下來講離線儲存在效能方面為使用者帶來的好處。首先是進離線儲存的定義文件，在Q 中所有的系統模組，都是有定義離線支援。是說所有的應用，如果 網斷了，還是可以用。在文件中加入MANIFEST的文件，MANIFEST是一個定義文件，聲明當前頁面哪些是需要存儲在本地的?哪些是不需要存儲的? 哪些如果說請求失敗，應該用哪些新的圖片或者什麼來代替?這樣分三塊：
　　第一，CACHE，哪些需要儲存到本地。
　　第二，NETWORK，是不會儲存在本地的，它每次都回去請求一遍但是這裡需要指出的是，本地存儲跟瀏覽器存儲實際上是兩回事情，他們存的是兩塊不同的地方。即使NETWORK這邊需要告訴APP說，我需要每次都拉一次，因為像Chrome，他這個儲存快取是非常可惡的，比較難清除的，必須透過手動 去清除，才能完全生效。所以說你即使設定了不要讓它儲存在本地，但是瀏覽器可能本身把它儲存起來了，因為他存的是兩塊不同地方。
　　第三，FALLBACK。如果說一個圖片假如說請求失敗，它是404。那要用什麼圖片代替?我覺得這個比較好玩。
　　MAEIFEST怎麼設定?​​ MANIFEST這裡需要注意的是三點：
　　MANIFEST同源限制;
　　MIME類型必須為text/cache-manifest，這是標準的，如果是其他格式，都不會是其他格式，生效;
　　CHROME，如果要看這個東西有沒有生效，可能透過CHROME這個偽協定的方式在瀏覽器輸入，chrome://appcache-internals。
　　關於如何去更新應用程式的快取。為什麼要離線儲存?離線儲存在本機，當瀏覽器知道你有離線儲存你，它會先去離線儲存的目錄下，去找這個資源是否已經被 Cache。當它已被Cache的時候，他就直接從這邊拿到這個資源，不會再去發送一個請求。因為瀏覽器的請求是這樣的，當有離線儲存的話，就連請求都不 會發，所以說會更快。 如果說有的時候我們需要更新，更新的時候怎麼辦?
　　用戶可以手動去清除瀏覽器的Cache，這個時候自動把本地存儲給清除了。
　　修改MANIFEST的任何內容，這是比較推薦的方式，也是我們線上用的方式。是說我們可以修改裡面的具體項目，但是這裡應該最好是修改註釋， 因為我每次發布的時候，我們自動發布機制，發布的時候在上面註釋修改一下就可以了。這樣的話，每次發布的內容，都會即時同步到客戶端的本機;
　　透過程式去執行，程式的就是window.applicationCache.update()。就是我要去操作離線存儲，其實我有時候叫應用存儲，因為它的語意就是應用存儲。我們去手動的更新應用程式儲存。
　　6.Web Worker
　　接下來Web Worker。 Web Worker是一個多執行緒的JS程序。應用場景其實我們在線上的話，是沒有的，我就不講了。但可以講下具體我看過的應用場景。
　　先介紹一下WEBWORK是什麼東西?它是一個OS級別的線程。之前我們模仿多線程，實際上都是多開一個視窗。但現在的話，瀏覽器本身就提供了，這會讓操作帶來更多便利，是讓我們整個文件比較重，並不是很建議的方式。
　　然後WebWorker存取能力是有限的，它並不能存取到很多全域物件。比如說documnet物件它是存取不了的。 WebWorker最適合的場景就是CPU密集的運算操作。之前我們做遊戲的時候，我們用BOX2D。應該很多人聽過，它牽涉到大量的計算，就是整個 頁面裡面，下面所有的物體要去計算它們的碰撞關係，這個計算量是非常大的。但是如果放在目前的JS的進程裡面去執行，這個計算量一大，一計算，整個頁面就 非常卡。但是如果用WebWorker去做，它是非同步的過程，即時的發送過去，在計算的過程中還能幹其他事，這就是多執行緒。
　　7.裝置API
　　來講一下裝置API。設備API我覺得最重要在效能方面，也是目前實現最早的API。一個是CONNECTION，就是網路頻寬。這個有什麼作用?在 中國這個場景下，必須要記住，很多用戶的網速依舊是很低的。我們希望讓用戶網速低的時候，能夠自動降級到比較低的方案。如果用現有的技術，我們是做不 到的。但是使用設備API我們是可以的。因為我們知道，從設備上可以取到這些資訊。它的寬頻是多少，多少寬頻的時候我們能幹的事情。比方說寬頻好的時候， 我就用高清圖片。寬頻比較低的時候，就用清晰度比較低的圖片。
　　8.電池
　　下面一個是關於電池的。我覺得從性能角度來說，主要是電力方面。假如說用戶電池電量比較低的時候，我覺得我應該盡量少做一些事情。本身手機現在電池的技術來沒有突破，我覺得讓APP看起來比較高性能，也是宣傳亮點。
　　9.CANVAS
　　接下來是CANVAS。講CANVAS的幾個效能最佳化點，用了這些東西，效能會有10倍的提升。
　　第一，每個CANVAS就是一個畫布，我們要去渲染一個圖形的時候， 我們是可以把它分層的。就是像PS裡面一樣，是一層兩層三層。很多用戶在做遊戲的時候，直接把所有東西仿放到一個層裡，一更新所有的東西都要更新。但如果 你把它分層，你讓背景放在背景圖層，角色放到角色圖層。這樣的話，我要更新角色的時候，只會更新角色，背景層不需要改變。讓CPU幹的事情更少了，效能自然而然 就提升了。
　　第二，context.drawImage。不要去縮放圖片，我們一開始就犯了一個錯誤，我們的美工做的圖片始終跟我們不一致，然後我們要去縮放圖 片。因為本身設備它的圖片大小是這樣的，我們必須按比率縮放圖片。縮放圖片以後發現在低端設備下，比方說iPad或者iPhone就會非常卡，我們就想為 什麼?就進行代碼上的分析，當用這個方法時候，花費的時候特別多。
　　第三，requestAnimationFrame。這是專門為渲染優化的一個方法。它本身的原理是這樣的，當瀏覽器每過一楨的時候，會觸發這個方 法，當我在觸發的時候，Canvas得到這個瀏覽器已經準備好做下楨的事情。如果用傳統的方法，是不會去考慮你更多的東西，它只會知道我過了多少時間，我 就要執行。假如說用戶之前被阻塞了，每10秒鐘執行這個方法，在10秒之內，實際他之前的事情還沒做完，然後這個事情就會被推遲。它就是為了動畫看上去 更流暢而優化的，因為每一楨的時候，它就告訴你說，你可以做一些事情。 (文：infoq）