首先，我們這里優化對象為移動站點 。
移動開發具備了pc開發所有的特點，并且可以使用一些pc端無法使用的一些手段（主要還是為了兼容ie8及以下瀏覽器啦），pc端的優化手段都可以在移動端使用。但是移動有些地方就不如pc端了(網絡慢，不穩定)，尤其2G網絡，每秒按10kb來算，下載一個資源要耗很多時間。
HTML5頁面優化點主要有以下幾點：
1.redirect：重定向耗時
2.APP cache：讀取緩存耗時
3.DNS：域名解析耗時
4.TCP：網絡連接耗時
5.request和response：發起請求和接受響應時間
6.processing：接受到響應頁面渲染時間
7.onload：渲染完畢，加載其他異步靜態資源時間
優化思路可以針對以上每個點各個擊破。
根據經驗，優化重點主要放在靜態資源加載和頁面渲染，網絡連接耗時和服務器響應時間不考慮在內。
隨著Html5的正式定稿，移動前端步入APP世界的步伐也隨之加速。目前主流的兩大手機系統廠商（google、蘋果）都是Html5的參與者，所以這兩大系統在對html5的支持上基本是沒什么問題的。然而對于很多開發者來說，也許僅僅是因為使用前的一番可行性分析便放棄這種方案。因為很多資料都敘述著Html5相比原生App的各種不足。其中最尷尬的一條莫過于“性能”問題。
前端性能問題與優勢
因為這個問題，剛開始接觸的時候我也有很強的抵觸情緒。但后來慢慢的發現，其實很多時候性能本就不是問題。適當的調整Html和Css，我們的網頁同樣可以無限接近原生程序。而且個人認為，大多數時候程序是否流暢并非取決于某種編程語言，而是取決于寫程序的人。相比通過各種代碼填充來完成目標任務，我更喜歡把技術當做藝術，寫代碼也應該有所追求。（扯淡扯遠了。）
其實，Html5相比原生App的開發有很多誘人的方面。
其一：可快速迭代。 最簡單最直接的一個：IOS程序每次上傳都需要通過漫長的審核時間，如果趕時間的話這是個問題，而且耐心等待之后未必就能得到一個我們想要的結果，審核不通也不是不可能。Html5開發完成之后也不用再次上傳審核。（若與原生程序有交互變更，此項無效）
其二：跨平臺。Html跨平臺的特性早已不是一天兩天的事了。IOS開發完成的同時，Android也基本完成。開發效率和成本上相比原生應用確實有較明顯的優勢。
其三：轉發率高。現在打開微信朋友圈就能看到各種分享。如：文章分享，產品分享，XX店鋪等。通過連接轉發可以實現快速分享，提高流量。
談完優勢，再說說自身經歷。本是一名老老實實的C#程序員，沒事就學習各種程序優化（sql為主）的我在幾個月前突然轉向移動網頁開發。在一個不算小的團隊里前端工程師是一枚傳統前端工程師。除能完成簡單的手機布局外其他一竅不通，于是乎關于JavaScript、前端性能優化等各種重擔都落到了我這里。由于前端所完成的僅僅是以html的形式展現出效果圖的模樣，很少涉及到性能問題。于是漫長的學習之路由此開始了。
究竟什么樣的頁面是需要優化的頁面？
1、頁面上下滑動時感覺卡頓不流暢或是基本不動；
2、動畫效果卡頓，看上去感覺一幀一幀的跳動；
簡單點說，就是感覺卡。也許iphone6不卡但是iphone4上會卡，也許iphone上不卡三星上感覺卡、魅族、小米、華為、聯想？國內屌絲機各有個的長相各有各的特色，比如魅族的MX，其他手機都很正常的時候它就卡。Html兼容一直都不是一件容易的事。
上述問題該如何破？
解決問題的關鍵在于找到問題的所在。砍柴還得有裝備，工具很重要。以前用chrome，是因為感覺這貨比較好使（直到放棄多年來一直鐘愛的IE）。幾個月前才發現這是一個調試工具也很好使的瀏覽器（簡直就是神器）。其實關于html性能問題，很多博客上都有解釋重繪這個事。下面主要談談如何用chrome鑒別重繪元素。
打開chrome，開啟開發者工具(F12)。打開模擬器，并選擇需要模擬的設備，在Console中選擇Rendering 選中第一條（Show paint rectangles）。若打開開發者工具后沒看見下方Console這塊可以按下Esc。
完成上述操作后，請將視線移動到左側網頁上的綠色矩形框上。
ps：一直都很喜歡淘寶的廣告，創意從未間斷過。
這個綠色框就是瀏覽器重繪的部分。這個框越大，說明重繪的區域也就越大。重繪并沒什么問題，這很正常，不正常的是大面積重繪，比如上圖中的時間跳動，如果僅僅是時間那個區域重繪并沒有什么問題，要是整個頁面都一直閃著個綠框框那就完蛋了。為何大面積重繪會出現性能問題，這個還得從瀏覽器渲染上談起。那是一個很長的故事，有興趣的朋友可以找些資料看看。簡單的舉例就是，瀏覽器把html文檔解析成網頁展現到我們面前，其中間是一個“漫長”的過程。再載入文檔之后需要對html進行分割、讀取并計算其樣式大小、然后進行圖層繪制、合并圖層等一系列操作。整個過程其實使用最多的部件是CPU和GPU。
重繪的面積大小和回流（reflows）有關，關于回流其實可以這樣理解，當改變一個元素后對其它節點元素產生影響。就如同可石子投入水中引起的波紋一樣，波紋所到之處基本都會有所影響。而在Html中子節點的變化會引起祖先的回流，同時也會影響到部分兄弟節點，大部分的回流將導致頁面的重新渲染。那么如何降低回流，減小重繪面積呢？淘寶時間不也只更新了一小塊么！這里提供兩種方法：
1、使用 position 屬性的 fixed 值或 absolute 值。
2、創建獨立的Layer（層）（為避免和div（層）產生混淆文中盡量同一使用Layer）。
繼續看淘寶：
第一種方法已經很明顯了就不再贅述。說說第二種方法吧。首先說說在Chrome中如何查看獨立的Layer呢。如上圖，選擇Show composited layer borders后在頁面上獨立的Layer上回顯示一個橘黃色邊框。那么又要如何才能建立獨立的Layer呢？
在Chrome中創建獨立的Layer僅需要符合下述條件之一：
1.有3D元素的屬性；
2.video標簽并使用加速視頻解碼；
3.canvas元素并啟用3D；
4.插件，比如flash；
5.CSS動畫；
6.CSS濾鏡；
7.有一個后代元素是獨立的layer；
8.元素的相鄰元素是獨立layer。
看上去挺多挺復雜的，其實最簡單、最容易理解、也最容易濫用的是第一條。實現第一條僅需要在元素的樣式里加上。transform:translateZ(0);-webkit-transform:translateZ(0); 就可以了。我們將淘寶往下滑動一點，找一個元素試試看。
還是看淘寶：
當加上css樣式后對應的元素上出現了橘黃色邊框，事實證明這招是有效的。而在Chrome中這樣做可以啟用GPU硬件加速。初次看到加速兩個字讓人覺得無比興奮，仿佛找到了克敵制勝的無敵神招。可是，首先這是在chrome下，其次大量使用真的好嗎？
其實就算是在chrome下GPU也未必能排上用場，首先需要確定你的GPU驅動程序不在chromium的黑名單中。因為某些GPU驅動程序存在錯誤，可能會影響瀏覽器穩定，所以會被加入到黑名單里。在chrome地址欄里輸入 about:gpu 可以查看相關的GPU信息。現在再說說GPU加速的事情吧，簡單點解釋就是通過GPU渲染的Layer，GPU會將圖層信息緩存起來，到下次改變的時候就只需要重新渲染修改過的部分。這樣固然是快，但是會加大系統RAM和GPU的內存開銷。在配置參差不齊的移動設備上，過多的層不僅不能加速，反而會嚴重影響性能。很多時候我們在感覺到移動網頁較卡的時候不防試試減少頁面上的Layer試試。
通過Chrome我們還可以鑒別一些其他影響性能的方面。比如：
上面兩幅圖，左邊一幅是百度.新聞的移動網頁版，箭頭指向的是這個頁面的loading效果（就是一種一直一直轉動的感覺）。右邊是以前最常用的一種loading。在效果上兩種方式都一樣，一直不停的轉動。而區別在于右邊的loading是一個帶有背景圖片的div，通過css3使其產生轉動效果；而右邊則是一張Gif動態圖片。雖然效果上一樣，但在瀏覽其中我們可以看到右邊的loading會有一個不停閃動的綠色框（頻率相當高）。gif動畫會導致瀏覽器不斷的進行繪制、柵格化、合成，整個過程相當影響性能，所以最好干掉它。
簡而言之言而簡之：
布局
1、減少重繪，減小重繪面積（改良布局，創建獨立的Layer），降低重繪頻率。
2、合理使用GPU加速，避免過度依賴GPU而導致性能下降。
動畫
說完布局，再簡單談談動畫吧。
常用的JavaScript動畫在移動web上很多時候都顯得心有余而力不足（不給力啊）。這個原因很多， JavaScript動畫通常是通過定時改變元素樣式屬性的方式來實現，JavaScript的運行是在一個獨立線程里完成的，作為單線程程序， JavaScript會因為某個耗時動作而影響下一幀動畫的執行。而且，JavaScript的定時也并沒有想象中的那么守時，如在setinterval中設置每毫秒輸出一個數， 當輸出到2000次的時候，當真就只需要2秒鐘嗎？相比之下更加推薦使用CSS3來完成相關動畫效果。首先Css由獨立線程完成，它和JavaScript的運行并不沖突， 其次Css3很多屬性不會觸發重繪（當然JavaScript里也可以是改變的css3的屬性）。 從流暢度上來講的話Css3基本上完勝JavaScript，而且操作較容易。關于Css3相關知識就不再贅述。
然而Css3的動畫也并沒有想象中那般完美。
首先，在動畫控制上不夠靈活，整動畫過程不太好監控。
其次，其兼容性不太好。僅移動端而言，位移動畫通常使用transform，但在某些瀏覽器中需要使用-webkit-transform（如微信里的瀏覽器）。
雖然Css3并非完美解決方案，但實際使用中大多數時候是完全可以解決我們所遇到的問題 （遇到復雜問題再解決吧，事在人為嘛，解決問題也是一種樂趣）。 且目前的移動應用上并不推薦過于復雜的效果設計。
