性能一直是網站成功的關鍵。愈來愈多的研究已經證實,無論是小型電商,仍是像沃爾瑪那樣的連鎖店,即便是頁面加載時間方面的細微改善,均可以帶來更多的業務,更多的廣告收入,更多的用戶粘性和更多的客戶滿意度。javascript
在過去幾年,Web開發者都是基於改善硬件或者提升帶寬速度來優化用戶體驗。可是最近幾年,爆炸式的移動Web瀏覽器的使用打破了這個途徑。低帶寬,高延遲,小內存,低處理器性能的移動設備環境,迫使開發者不得不想辦法經過優化前端頁面的性能來知足用戶的性能預期。php
在強調如何解決移動端性能問題上,這篇文章總結了一些前端優化的案例,而且歸納了一些加速頁面的方法和策略。css
不論你的頁面設計地多麼有趣、漂亮、交互性好,無論是在桌面仍是移動設備上,若是頁面須要花2到3秒時間去渲染展現,那麼用戶都會很快變得不耐煩的。能夠預期的是,在頁面還在加載的時候,用戶頗有可能從瀏覽購買的行爲轉變爲點擊回退鍵或者是關閉瀏覽器的行爲。html
不到1秒鐘的延遲甚至也會顯著地影響收入。在2006年,當時還在Google工做的Marissa Mayer說,因爲用戶表示但願在一個搜索頁上看到多於10個搜索結果,Google就實驗性地修改成30個。可是讓人吃驚的是,在這個實驗裏,流量和投 資都減小了20個百分點,顯然是因爲更多的搜索結果致使多花費了半秒時間來加載頁面。^5前端
用戶的指望老是在不斷的提高。2009年,Forrester研究所的Akamai的一項研究發現代表,網頁響應時間可容忍的閥值是2秒,一旦網頁 相應時間超過3秒,會有40%的用戶放棄瀏覽頁面。一年以後,Akamai的另外一項研究代表,超過3秒放棄瀏覽頁面的用戶比例上升到了57%。^1,7html5
此外,移動端的用戶但願移動設備上的頁面性能不亞於桌面PC。由Tealeaf科技(如今已經併入IBM)委託的「Harris的互動2011移動 交互調查」顯示,在前一年有過移動消費經歷的成年人中,有85%但願移動設備上的體驗能與手提電腦或者PC上的體驗至關,甚至於更好。而且有63%的人表 示,一旦他在移動設備上的交易遇到了一個問題,他們就不會再想經過其餘渠道去購買這個公司的其餘產品了。^10換句話說,差勁的移動頁面性能會影響到公司 其餘各類平臺的銷售,這其中固然也包括線下的實體店。java
移動流量正在迅速增加。對許多消費者而言,他們的手機或者平板設備已經成爲他們瀏覽網絡的主要入口了,可是其性能表現卻差強人意。2011年2 月,Compuware公司委託Equation 研究所作的一項研究代表,幾乎一半的移動用戶(46%)表示他們手機上的網站加載速度過慢。60%的用戶但願頁面能在3秒或者更少的時間內加載完 成,74%的用戶表示,當單個頁面加載時間花費5秒或者更多的時候,他們會選擇離開這個頁面。在2012年,由Strangeloop網絡(現已併入 Redware)發起的一項針對200家領先的電子商務網站研究代表,3G網絡環境下,平均加載時間爲11.8秒(圖1),而在LTE(4G)環境下,加 載時間只有輕微的改善,爲8.5秒。^8jquery
正如上文所說的,移動設備天生有下面三種性能限制:帶寬低,內存小,處理器性能低。這些性能挑戰又加上一些其餘的問題,例如:ios
網頁比之前更大。根據HTTP Archive網站的分析,如今平均的一個web頁面須要加載超過1MB的數據,其中包含有圖片,Javascript,CSS(Cascading Style Sheets)等。更大的網頁會影響桌面PC的顯示性能。對於移動端的性能 — 特別是3G環境下的性能 — 影響更嚴重。這個影響會在從此的三年更加明顯。以如今的頁面增加速度來講,到2015年,平均的頁面大小會達到2MB。web
延遲相差巨大。對LTE來講,延遲大概有34ms,對3G來講,延遲大概有350毫秒甚至更多。移動端的延遲性 惟一不變的就是延遲時間永遠是不定的,即便是在同一個地點,每次的延遲都是不定的。這是因爲大量的數據是經過信息塔進行傳輸的。所以諸如天氣,甚至是持有 者所面向的方向都有可能成爲影響因素。
下載速度相差巨大。下載速度的範圍從3G環境下的1Mbps到LTE環境下的31Mbps。把這個和美國平均的帶寬15Mbps相比是一個頗有意思的事情,3G環境比平均帶寬慢了15倍,而LTE卻能達到平均帶寬的2倍那麼快。
許多網站建設者嘗試針對多用戶訪問,大網頁和低流量鏈接的訪問頁面,開發出短小,快速,精簡的m.sites;可是,這些嘗試並無什麼用,當用戶有選擇權的時候,高達35%的移動用戶會選擇瀏覽完整的網站。
這些選擇瀏覽完整網站的用戶顯然比瀏覽m.sites的用戶更有購買慾望。一個研究代表,移動端每$7.00的消費中,有$5.50是來自於網站的網站瀏覽,只有$1.00是來自於m.sites,剩下的$0.50則是來自於客戶端。^9
改善網站性能的主要策略並無由於從PC變成手機或者平板設備而有變化,只是會參雜一些小的策略。
不論在PC仍是在移動瀏覽器上,頁面展現須要的時間裏,只有20%是用來讀取頁面的HTML的。剩下的80%是用來加載額外的像樣式表、腳本文件、或者圖片這樣的資源和執行客戶端的程序。
三個主要的改善性能的策略是:
因爲移動網絡一般比桌面機器的網絡慢,因此減小請求數和請求加載量是很是重要的。因爲移動端的瀏覽器解析HTML和執行JavaScript的效率 比桌面PC低,因此優化客戶端程序也是很是關鍵的。另外,移動端瀏覽器的緩存大小比桌面PC低,因此須要有方法能重複利用本地的緩存資源。
文章剩餘部分總結了能解決這些問題的方法。雖然這些方法大均可以自動化解決,固然也能夠由有經驗的前端工程師來手動解決。關鍵就是要知道人工解決這 些技術的方法如何控制資源的請求。一般在CMS(內容管理系統)或者其餘Web應用中,有些頁面包含一些自動生成好的或者離線的HTML片斷、CSS或者 Javascript文件,這樣的頁面開發者就不須要去優化它們了。
最大的性能漏洞就是一個頁面須要發起幾十個網絡請求來獲取諸如樣式表、腳本或者圖片這樣的資源。這個在相對低帶寬和高延遲的移動設備鏈接上來講影響 更嚴重。CDNs(內容分發網絡)把資源放在離用戶地理位置更近的地方對解決這個問題能起到很大做用,可是比起獲取請求,大量的請求對頁面加載時間的影響 更爲嚴重。並且最近的發現代表,CDNs對移動端用戶的性能影響愈來愈低。
下面的章節討論了簡化HTTP請求的幾種方法。
對開發者來講,將Javascript代碼和CSS樣式放到公共的文件中供多個頁面共享是一種標準的優化方法。這個方法能很簡單的維護代碼,而且提升客戶端緩存的使用效率。
在Javascript文件中,要確保在一個頁面中相同的腳本不會被加載屢次。當大團隊或者多個團隊合做開發的時候,這種冗餘的腳本就很容易出現。你可能會對它的發生頻率並不低感到很是吃驚。
Sprites是css中處理圖片的一項技術。Sprites就是將多張圖片整合到一個線性的網狀的大圖片中。頁面就能夠將這個大圖片一次性獲取回 來而且作爲css的背景圖,而後使用css的背景定位屬性展現頁面須要的圖片部分。這種技術將多個請求整合成一個,能顯著地改善性能。
實現小貼士:平穩地改進可是須要對資源有控制權限。根據開發者的網站不一樣權限,一些資源並不須要被整合起來(例如,一些由CMS生成的資源)。還 有,對於一些外部域引用的資源,強行整合可能會致使問題。須要注意的是,整合資源對手機瀏覽器來講是一把雙刃劍。整合資源確實會在首次訪問減小請求,可是 大的資源文件可能會致使緩存失效,因此,須要當心地使用各類技術整合資源,以達到優化本地存儲的目的。
如今全部的瀏覽器都會使用本地資源去緩存住那些被Cache-Control或者Expires頭標記的資源,這些頭能標記資源須要緩存的時間。另 外,ETag(實體標籤)和Last-Modified頭來標識當資源過時後是否須要從新請求。瀏覽器爲了減小沒必要要的服務器請求,儘量地從本地緩存中 獲取資源,而且將那些已通過期的、或者當緩存空間減少的時候將那些好久不用的資源進行清理。瀏覽器緩存一般包括圖片,CSS,Javascript代碼, 這些緩存能合理地提升網站的性能。(好比爲了支持後退和前進的按鈕,使用一個單獨的緩存來保存整個渲染的頁面)。
移動瀏覽器緩存,一般是比桌面PC小的多,這就致使了緩存的數據會很常常被清理。HTML5的緩存基於瀏覽器緩存提供了一個很好的替換方案。 Javascript的localStorage已經在全部主流的桌面和移動端瀏覽器上都實現了。使用腳本代碼能簡便地支持HTML5的 localStorage操做,能夠讀寫鍵值數據,每一個域名大概有5MB的容量。雖然不一樣的移動瀏覽器上讀寫速度相差很大,可是localStorage 大容量的緩存使得它很適合做爲客戶端的緩存。從localStorage獲取資源明顯快於從服務器上獲取資源,並且在大多數移動設備上也比依靠緩存頭或者 瀏覽器的本地緩存更靈活可靠。這是移動瀏覽器比桌面PC更有優點的一個地方,在桌面PC上,本地緩存仍然優先使用標準的瀏覽器緩存,致使桌面PC本地緩存 的性能落後於移動瀏覽器。
實現小貼士:須要進一步考慮。雖然localStorage的機制易於實現,可是它的一些控制機制倒是很是複雜的。你須要考慮到緩存帶給你的全部問題,好比緩存失效(何時須要刪除緩存?),緩存丟失(當你但願數據在緩存中的時候它並不在怎麼辦?),還有當緩存滿的時候你怎麼辦?
HTML的標準是使用連接來加載外部資源。這使得更容易在服務器上(或者在CDN上)操做更新這些資源,而不是在每一個頁面上修改更新這些資源。根據上文討論的,這種模式也使得瀏覽器能從本地緩存而不是服務器上獲取資源。
可是對尚未緩存到瀏覽器localStorage的資源來講,這種模式對網站的性能有負面的影響。通常來講,一個頁面須要幾十個單獨的請求來獲取 資源從而渲染頁面。因此說,從性能的角度來講,若是一個資源沒有很高的被緩存的概率的話,最好把它嵌入到頁面的HTML中(叫inlining),而不是 使用連接外部。腳本和樣式是支持內嵌到HTML中的,可是圖片和其餘的二進制資源其實也是能夠經過內嵌包含base64編碼的文原本嵌入到HTML中的。
內嵌的缺點是頁面的大小會變得很是大,因此對於Web應用來講,關鍵的是可以跟蹤分析這個資源何時須要從服務端獲取,何時已經緩存到客戶端 了。另外,在第一次請求資源後必須可以使用代碼在客戶端緩存資源,所以,在移動設備上,使用HTML5 localStorage能很好地作到內嵌。
實現小貼士:平穩處理。因爲不知道用戶是否已經訪問過這個頁面了,因此須要網站有機制能生成不一樣版本的頁面。
Web應用已經使用了各類從服務器上輪詢資源的方法來持續地更新頁面。HTML5的EventSource對象和Server-Sent事件能經過 瀏覽器端的JavaScript代碼打開一個服務端鏈接客戶端的單向通道。服務端可使用這個寫通道來發送數據,這樣能節省了HTTP建立多個輪詢請求的 消耗。這種方式比HTML的WebSocket更高效。WebSocket的使用場景是,當有許多客戶端和服務端的交互的時候(好比消息或者遊戲),在全 雙工鏈接上創建一個雙向通道。
實現小貼士:須要進一步考慮。這個技術是基於具體的技術實現的。若是你的網站當前是使用其餘的Ajax或者Comet技術來輪詢的,轉變成Server-Sent 事件須要重構網站的Javascript代碼。
當用戶在一個移動設備上訪問桌面PC網站的時候,Web網站應用一般讀取HTTP的user-agent頭來判斷這個用戶是不是來自移動設備的。然 後應用會發送帶有空HTTP body和重定向HTTP地址頭的HTTP 301(或者302)請求,把用戶重定向到網站的移動版本上去。可是,這個額外的客戶端和服務端的交互一般在移動網絡上會消耗幾百毫秒。所以,在原先的請 求上傳遞移動的web頁會比傳遞一個重定向的信息並讓客戶端再請求移動頁面更快。
對於那些想要在移動設備上看桌面PC網站的用戶來講,你能夠在移動web頁面上提供一個連接入口,這樣也能同時表示你的網站是並不提倡這種行爲的。
實現小貼士:雖然這個技術在理論上是簡單的,可是實際上並不易於實施。因爲有些m.sites是宿主在其餘地方 的,因此許多網站會選擇重定向到一個不一樣的服務器上。有的網站則是會在重定向請求的時候種植上Cookie告訴Web應用這個用戶是在使用移動設備。這種 方法可能對web應用來講更容易控制。
大小問題。渲染小頁面更快,獲取小資源也更快。減少每一個請求的大小一般不如減小頁面請求個數那麼顯著地提升性能。可是,有些技術在性能方面,特別是在須要對帶寬和處理器性能精打細算的移動設備環境下,仍然是能帶來很大利益的。
諸如gzip這樣的壓縮技術,依靠增長服務端壓縮和瀏覽器解壓的步驟,來減小資源的負載。可是,通常來講,這些操做都是被高度優化過了。並且測試表 明,壓縮對網站仍是起到優化性能的做用的。那些基於文本的響應,包括HTML,XML,JSON(Javascript Object Notation),Javascript,和CSS能夠減小大約70%的大小。
瀏覽器在Accept-Encoding請求頭中申明它的解壓縮技術,而且當它們接收到服務端返回的Content-Encoding響應頭標示的時候,就會按照這個響應頭自動作解壓操做。
實現小貼士:易於實現。若是設置正確的話,如今全部的Web服務器都支持壓縮響應。可是,也有一些桌面PC的安全工具會將請求頭中的Accept-Encoding頭去掉,這樣即便瀏覽器支持解壓縮,用戶也沒法獲取到壓縮後的響應。
簡化一般是使用在腳本和樣式文件中,刪除一些沒必要要的字符,好比空格,換行符,或者註釋等。不須要暴露給外部的命名就能夠被縮短爲一個或者兩個字 符,好比變量名。合適的簡化資源一般在客戶端不須要作任何其餘的處理,而且平均減小20%的資源大小。內嵌在HTML中的腳本和樣式文件也是能夠精簡的。 有不少很好的庫來作精簡化的操做,這些庫通常也同時會提供合併多個文件這樣減小請求數的服務。
簡化帶來的好處並不侷限於減小帶寬和延遲,對於那些移動設備上緩存沒法保存的過大資源來講,也是頗有改善的。Gzip在這個方面並無任何幫助,由於資源是在被解壓後才被緩存起來的。
實現小貼士:易於實現。Google的Closure Compiler已經難以置信地完成了理解和簡化Javascript的工做。可是CSS的簡化則沒有那麼容易,由於對不一樣瀏覽器來講有不一樣的CSS技術 能迷惑CSS簡化工具,而後讓CSS簡化後沒法正常工做。必需要注意的是,已經有這樣的案例了,即便只是刪除了沒必要要的字符,簡化工做也有可能破壞頁面。 因此當你應用簡化技術以後,請作一下完整的功能測試工做。
圖片一般是佔用了Web頁面加載的大部分網絡資源,也佔用了頁面緩存的主要空間。小屏幕的移動設備提供了經過調整圖片大小來加速傳輸和渲染圖片資源的機會。若是用戶只是在小的移動瀏覽器窗口中看圖片的話,高分辨率的圖片就會浪費帶寬、處理時間和緩存空間。
爲了加速頁面渲染速度和減小帶寬及內存消耗,能夠動態地調整圖片大小或者將圖片替換爲移動設備專用的更小的版本。不要依靠瀏覽器來將高分辨率的圖片轉換成小尺寸的圖片,這樣會浪費帶寬。
另一個方法是先儘快加載一個低分辨率的圖片來渲染頁面,在onload或者用戶已經開始和頁面交互之後將這些低分辨率的圖片替換成爲高分辨率的圖片。
實現小貼士:特別應用在高度動態化的網站是有優點的。
HTML5包括了一些新的結構元素,例如header,nav,article和footer。使用這些語義化的元素比傳統的使用div和span 標籤能使得頁面更簡單和更容易解析。一個簡單的頁面更小加載更快,而且簡單的DOM(Document Object Model)表明着更快的JavaScript執行效率。新的標籤能很快地應用在包括移動端的新瀏覽器版本上,而且HTML5設計讓那些不支持它的瀏覽器 能平穩過渡使用新標籤。
HTML5的一些表單元素提供了許多新屬性來完成本來須要javascript來完成的功能。例如,新的placeholder屬性用於顯示在用戶輸入進入輸入框以前顯示的介紹性文字,autofocus屬性用於標示哪一個輸入框應當被自動定位。
也有一些新的輸入框元素能不用依靠Javascript就能夠完成一些通用的需求。這些新的輸入框類型包括像e-mail,URL,數字,範圍,日 期和時間這樣須要複雜的用戶交互和輸入驗證的元素。在移動瀏覽器上,當須要輸入文本的時候,彈出的鍵盤一般是由特定的輸入框類型來作選擇的。不支持指定的 輸入類型的瀏覽器就會只顯示一個文本框。
另外,只要瀏覽器支持內建的層次,圓角,陰影,動畫,過渡和其餘的圖片效果,CSS 3.0就能幫助你建立輕便簡易的頁面了,而這些圖片效果原先是須要加載圖片才能完成的。這樣,這些新特性就能加速頁面渲染了。
有不少Web站點都提供哪些移動或者桌面瀏覽器支持哪項性能的更新說明。(例如:http://caniuse.com/ 和 mobilehtml5.org)。
實現小貼士:須要進一步考慮。人工地作這些改動是很是複雜和耗時的。若是你使用CMS,它能夠幫你生成許多你不須要控制的HTML和CSS。
瀏覽器按照什麼順序來執行代碼生成一個頁面,和頁面複雜性及JavaScript的技術選擇,都對性能有很大的影響。特別在客戶端相對較慢的CPUs和少內存的移動端中尤其明顯。下面的章節提供一些策略來提高頁面處理的性能。
能夠肯定的是若是咱們將不可見區域的內容延遲加載,那麼頁面就會更快地展示在用戶面前,這個區域叫作」below the fold」。爲了減小頁面加載後須要從新訪問的內容,能夠將圖片替換爲正確的高寬所標記的<img>標籤。
實現小貼士:平穩處理。一些好的Javascript庫能夠用來處理這些below-the-fold 延遲加載的圖像。^12
在一些移動設備上,解析Javascript代碼的速度能達到100毫秒每千字節。許多腳本的庫直到頁面被渲染之後都是不須要的加載的。下載和解析 這些腳本能夠很安全地被推遲到onload事件以後來作。例如,一些須要用戶交互的行爲,好比託和拽,都不大可能在用戶看到頁面以前被調用。相同的邏輯也 能夠應用在腳本執行上面。儘可能將腳本的執行延遲到onload事件以後,而不是在初始化頁面中重要的可被用戶看到的內容的時候執行。
這些延遲的腳本多是你本身寫的,更重要的是,也有多是第三方的。對廣告、社交媒體部件、或者分析的差勁的腳本優化會致使阻塞頁面的渲染,會增長 珍貴的加載時間。固然,你須要當心地評估諸如jquery這樣爲移動網站設計的大型腳本框架,特別當你僅僅只是使用這些框架中的一些對象的時候更要當心評 估。
實現小貼士:平穩處理。許多第三方的框架如今提供延遲加載的異步版本的API。開發者只須要將原先的邏輯轉化到 這個異步版本。一些JavaScript要作延遲加載會有些複雜,由於在onload以後執行這些腳本須要注意不少注意事項。(例如,你有個腳本須要綁定 到onload事件上,你須要作什麼?若是你將腳本延遲到onload事件以後,就必定就會失去不少執行的時機。)
Ajax(Asynchronous JavaScript and XML)是一項使用XHR(XMLHttpRequest)對象來從Web服務器上獲取數據的技術,它並不須要更新正在運行的頁面。Ajax能更新頁面上 的某個部分而不須要從新構建整個頁面。它一般用來提交用戶的交互相應,可是也能夠用來先加載頁面的框架部分,而後當用戶準備好瀏覽網頁的時候再填充詳細的 內容。
儘管是這個名字,可是XMLHttpRequest並不強制要求你只能使用XML。你能夠經過調用overrideMineType方法來制 定」application/json」類型來使用json替換XML。使用JSON.parse會比使用原生的eval()函數快了幾乎兩倍,而且更爲 安全。
同時,切記Ajax的返回響應也會得益於那些應用在普通的返回響應的優化技術上面。確保對你的Ajax返回響應使用了緩存頭,簡化,gzip壓縮,資源合併等技術。
實現小貼士:因爲這個技術是根據具體應用不一樣而不一樣的,因此很難量化。或許因爲跨域問題,你須要使用XHR2,這個技術能使用外部域的資源,從而能進行跨域的XHR請求。
因爲使用更多帶寬會使用更多移動網絡的費用,因此只有能檢測網絡的類型才能使用針對特定網絡的優化技術。例如,預加載將來使用到的請求是很是聰明的作法,可是若是用戶的帶寬很稀有,而且加載的有些資源是永遠不會用到的話,這個技術就是不合理的了。
在Android 2.2+,navigator.connection.type屬性的返回值能讓你區分Wifi和2G/3G/4G網絡。在Blackberry 上,blackberry.network也能提供類似的信息。另外,服務端經過檢測請求中的User-Agent頭或者其餘的嵌入到請求中的信息能讓你 的應用檢測到網絡情況。
實現小貼士:須要進一步考慮。檢測網絡信息的API最近已經有所變化了。^11 接口如今不是直接定義Wi-Fi,3G等網絡情況,而是給出了帶寬信息和諸如「很是慢,慢,快和很是快」這樣的建議。有個屬性能給出估計的MB/s值和一 個「meterd」的Boolean值來表示它的可信度,可是對瀏覽器來講,很難根據這個來判斷環境。判斷當前網絡環境而後適配仍然是一種最好的方法,但 是這種方法正在被考慮被替換。
HTML5中的Web Worker是使用多個線程併發執行Javascript程序。另外,這種特別的多線程實現能減小困惑開發者多年的,在其餘平臺上遇到的問題。例如,當一 個線程須要改變一個正在被其餘線程使用的資源該如何處理。在Web Worker中,子線程不能修改主用戶界面(UI)線程使用的資源。
對提升移動站點的性能來講,Web Worker中的代碼很適合用來預處理用戶完成進一步操做所須要的資源的,特別是在用戶的帶寬資源不緊缺的狀況下。在低處理器性能的移動設備上,過多的預 加載可能會干擾當前頁面的UI響應。使用多線程代碼,讓Web Worker對象(而且儘量使用localStorage來緩存數據)在另一個線程中操做預加載資源,這樣就能不影響當前的UI表現了。
要特別說明的是,Web Worker只在Android 2.0以上的版本實現,並且iphone上的ios5以前的版本也不支持。在桌面PC上,老是落後的IE只在IE 10才支持Web Worker。
實現小貼士:平穩過渡。雖然這項技術並非很是難實現,可是對Web Workers來講,有一些限制須要強制遵照。Web Workers不能進入到頁面的DOM,也不能改變頁面上的任何東西。Web Worker很適合那種須要後臺計算和處理的工做。
在觸摸屏設備上,當一個用戶觸碰屏幕的時候,onclick事件並無當即觸發。設備會使用大約半秒(大多數設備差很少都是300毫秒)來讓用戶確 定是手勢操做仍是點擊操做。這個延遲會很明顯地影響用戶指望的響應性能。要使用touchend事件來替換才能解決。當用戶觸碰屏幕的時候,這個事件會立 即觸發。
爲了要確保不會產生用戶不指望的行爲,你應該也要使用touchstart和touchmove事件。例如,除非同時有個touchstart事件 在button上,不然不要判斷touchend事件在button上就意味着點擊行爲 — 由於用戶有可能從其餘地方觸碰開始,而後拖拽到button上觸碰結束的。你也能夠在touchstart事件以後使用touchmove事件來避免將 touchend事件誤判爲點擊,固然前提是須要假設拖拽的手勢並非預期產生點擊行爲。
另外,你也須要去處理onclick事件來讓瀏覽器改變button的外觀從而標識爲已點擊的狀態,同時你也須要處理那些不支持touch事件的瀏 覽器。爲了不代碼在touchend和onclick代碼中重複執行,你須要在確保用戶觸碰事件已經在touchend執行了以後,在click事件中 調用preventDefault和stopPropagation方法。^4
實現小貼士:須要進一步考慮。這種技術須要更多工做才能在一個頁面中增長和維護連接。touch事件的代碼必須考慮其餘手勢,由於替換click的還有多是縮放或者敲擊動做。
應用層HTTP和HTTPS協議致使的一些性能瓶頸,使得不管是桌面仍是移動端的網站都很是難受。在2009年,谷歌開始研發一種叫作SPDY(諧 意是」speedy」)的協議來替換已有的協議,這種協議宣稱能突破這些限制。這個協議的目標是讓多種瀏覽器和多種Web服務都能支持,因此這個協議是開 源的,可是初步地,只有Google的Chrome瀏覽器(在版本10及以後的)和google的站點支持。一旦一個Web服務支持SPDY,那麼它上面 的全部站點均可以和支持這個協議的瀏覽器使用SPDY進行交互。將SPDY應用在25個top100的Internet網站上,Google收集到的數據 是網站的速度會改善27%到60%不等。^2
SPDY自動使用gzip壓縮全部內容,和HTTP不一樣的是,它連header的數據也使用gzip壓縮。SPDY使用多線程技術讓多個請求流或者響應流能共用一個TCP鏈接。另外SPDY容許請求設置優先級,好比,頁面中心的視頻會比邊框的廣告擁有更高的優先級。
或許SPDY中最變革性的發明就是流是雙向的,而且能夠由客戶端或者服務端發起,這樣能使得信息能推送到客戶端,而不用由客戶端發起第一次請求。例 如,當一個用戶第一次瀏覽一個站點,尚未任何站點的緩存,這個時候服務端就能夠在響應中推送全部的請求資源,而不用等候每一個資源被再次獨立請求了。做爲 替換協議,服務端能夠發送暗示給客戶端,提示頁面須要哪些資源,同時也容許由客戶端來初始化請求。即便是使用後一種這樣的方式也比讓客戶端解析頁面而後自 己發現有哪些資源須要被請求來得快。
雖然SPDY並無對移動端有什麼特別的設置,可是移動端有限的帶寬就使得若是支持SPDY的話,SPDY在減小移動網站的延遲是很是有用的。
實現小貼士:依據網站和服務的環境來進行平穩操做或進一步考慮。Google有一個SPDY模塊支持 Apache2.2 – mod_spdy – 這個模塊是免費的;可是mod_spy有線程上的問題,而且和mod_php協做並非很好,因此要求你使用這個技術的時候要確保你的網站的正常運行。 ^6
若是缺乏了持續和仔細的測試提醒,性能的優化就只是討論而已,是沒法完成的。若是沒有指定基準作比較,你係統上的任何改動都僅僅是理論而已。若是沒有真實的測試數據,猜想性能的瓶頸是毫無心義的。
有不少開源和通用的工具能進行集成測試,而且能進行不一樣地域和帶寬/延遲的測試。另外,RUM(real user monitoring)工具能將測試環境從實驗室變成不可預測的真實用戶行爲。
觀察移動設備的測試選擇和桌面場景同樣。若是你在選擇一個自動化的解決方案,請確保使用一個能持續測試,而且能區分出應用優化方法先後的變化的解決方案。
若是性能優化若是隻是在發展過程當中的一個步驟而已,它不會有什麼效果的。它必須成爲一個持續改善網站的一部分。
1. Bustos, L. 2009. Every second counts; how website performance impacts shopper behavior. GetElastic;http://www.getelastic.com/performance/.
2. Chromium Projects. SPDY: an experimental protocol for a faster Web;https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper.
3. Everts, T. 2013. Case study: how effective are CDNs for mobile visitors. Web Performance Today;http://www.Webperformancetoday.com/2013/05/09/case-study-cdn-content-delivery-network-mobile-3g/.
4. Fioravanti, R. 2011. Creating fast buttons for mobile Web applications. Google Developers;http://code.google.com/mobile/articles/fast_buttons.html.
5. Linden, G. 2006. Marissa Mayer at Web 2.0. Geeking with Greg;http://glinden.blogspot.com/2006/11/marissa-mayer-at-Web-20.html.
6. mod-spdy; http://code.google.com/p/mod-spdy/.
7. PhoCusWright. 2010. PhoCusWright/Akamai study on travel site performance;http://connect.phocuswright.com/2010/06/phocuswrightakamai-study-on-travel-site-performance/;http://www.akamai.com/dl/whitepapers/Akamai_PCW_Travel_Perf_Whitepaper.pdf.
8. Radware. 2011. Case studies from the mobile frontier: the relationship between faster mobile sites and business KPIS; http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/.
9. Bixby, J. 2012. 2012 state of mobile e-commerce performance;http://www.strangeloopnetworks.com/resources/videos/case-studies-from-the-mobile-frontier-the-relationship-between-faster-mobile-sites-and-business-kpis-video/.
10. Tealeaf. 2011. Report on the Mobile Customer Experience. Based on the Harris Interactive 2011 Mobile Transactions Survey.
11. W3C. 2012. Network Information API; http://www.w3.org/TR/netinfo-api/.
12. YUI. ImageLoader. Yahoo! User Interface Library; http://yuilibrary.com/yui/docs/imageloader/.