首先，我們這里優(yōu)化對(duì)象為移動(dòng)站點(diǎn) 。
移動(dòng)開發(fā)具備了pc開發(fā)所有的特點(diǎn)，并且可以使用一些pc端無法使用的一些手段（主要還是為了兼容ie8及以下瀏覽器啦），pc端的優(yōu)化手段都可以在移動(dòng)端使用。但是移動(dòng)有些地方就不如pc端了(網(wǎng)絡(luò)慢，不穩(wěn)定)，尤其2G網(wǎng)絡(luò)，每秒按10kb來算，下載一個(gè)資源要耗很多時(shí)間。

HTML5頁面優(yōu)化點(diǎn)主要有以下幾點(diǎn)：

1.redirect：重定向耗時(shí)
2.APP cache：讀取緩存耗時(shí)
3.DNS：域名解析耗時(shí)
4.TCP：網(wǎng)絡(luò)連接耗時(shí)
5.request和response：發(fā)起請(qǐng)求和接受響應(yīng)時(shí)間
6.processing：接受到響應(yīng)頁面渲染時(shí)間
7.onload：渲染完畢，加載其他異步靜態(tài)資源時(shí)間
優(yōu)化思路可以針對(duì)以上每個(gè)點(diǎn)各個(gè)擊破。
根據(jù)經(jīng)驗(yàn)，優(yōu)化重點(diǎn)主要放在靜態(tài)資源加載和頁面渲染，網(wǎng)絡(luò)連接耗時(shí)和服務(wù)器響應(yīng)時(shí)間不考慮在內(nèi)。

隨著Html5的正式定稿，移動(dòng)前端步入APP世界的步伐也隨之加速。目前主流的兩大手機(jī)系統(tǒng)廠商（google、蘋果）都是Html5的參與者，所以這兩大系統(tǒng)在對(duì)html5的支持上基本是沒什么問題的。然而對(duì)于很多開發(fā)者來說，也許僅僅是因?yàn)槭褂们暗囊环尚行苑治霰惴艞夁@種方案。因?yàn)楹芏噘Y料都敘述著Html5相比原生App的各種不足。其中最尷尬的一條莫過于“性能”問題。

前端性能問題與優(yōu)勢(shì)

因?yàn)檫@個(gè)問題，剛開始接觸的時(shí)候我也有很強(qiáng)的抵觸情緒。但后來慢慢的發(fā)現(xiàn)，其實(shí)很多時(shí)候性能本就不是問題。適當(dāng)?shù)恼{(diào)整Html和Css，我們的網(wǎng)頁同樣可以無限接近原生程序。而且個(gè)人認(rèn)為，大多數(shù)時(shí)候程序是否流暢并非取決于某種編程語言，而是取決于寫程序的人。相比通過各種代碼填充來完成目標(biāo)任務(wù)，我更喜歡把技術(shù)當(dāng)做藝術(shù)，寫代碼也應(yīng)該有所追求。（扯淡扯遠(yuǎn)了。）

其實(shí)，Html5相比原生App的開發(fā)有很多誘人的方面。

其一：可快速迭代。 最簡(jiǎn)單最直接的一個(gè)：IOS程序每次上傳都需要通過漫長(zhǎng)的審核時(shí)間，如果趕時(shí)間的話這是個(gè)問題，而且耐心等待之后未必就能得到一個(gè)我們想要的結(jié)果，審核不通也不是不可能。Html5開發(fā)完成之后也不用再次上傳審核。（若與原生程序有交互變更，此項(xiàng)無效）
其二：跨平臺(tái)。Html跨平臺(tái)的特性早已不是一天兩天的事了。IOS開發(fā)完成的同時(shí)，Android也基本完成。開發(fā)效率和成本上相比原生應(yīng)用確實(shí)有較明顯的優(yōu)勢(shì)。
其三：轉(zhuǎn)發(fā)率高。現(xiàn)在打開微信朋友圈就能看到各種分享。如：文章分享，產(chǎn)品分享，XX店鋪等。通過連接轉(zhuǎn)發(fā)可以實(shí)現(xiàn)快速分享，提高流量。
談完優(yōu)勢(shì)，再說說自身經(jīng)歷。本是一名老老實(shí)實(shí)的C#程序員，沒事就學(xué)習(xí)各種程序優(yōu)化（sql為主）的我在幾個(gè)月前突然轉(zhuǎn)向移動(dòng)網(wǎng)頁開發(fā)。在一個(gè)不算小的團(tuán)隊(duì)里前端工程師是一枚傳統(tǒng)前端工程師。除能完成簡(jiǎn)單的手機(jī)布局外其他一竅不通，于是乎關(guān)于JavaScript、前端性能優(yōu)化等各種重?fù)?dān)都落到了我這里。由于前端所完成的僅僅是以html的形式展現(xiàn)出效果圖的模樣，很少涉及到性能問題。于是漫長(zhǎng)的學(xué)習(xí)之路由此開始了。

究竟什么樣的頁面是需要優(yōu)化的頁面？

1、頁面上下滑動(dòng)時(shí)感覺卡頓不流暢或是基本不動(dòng)；
2、動(dòng)畫效果卡頓，看上去感覺一幀一幀的跳動(dòng)；
簡(jiǎn)單點(diǎn)說，就是感覺卡。也許iphone6不卡但是iphone4上會(huì)卡，也許iphone上不卡三星上感覺卡、魅族、小米、華為、聯(lián)想？國(guó)內(nèi)屌絲機(jī)各有個(gè)的長(zhǎng)相各有各的特色，比如魅族的MX，其他手機(jī)都很正常的時(shí)候它就卡。Html兼容一直都不是一件容易的事。

上述問題該如何破？

解決問題的關(guān)鍵在于找到問題的所在?？巢襁€得有裝備，工具很重要。以前用chrome，是因?yàn)楦杏X這貨比較好使（直到放棄多年來一直鐘愛的IE）。幾個(gè)月前才發(fā)現(xiàn)這是一個(gè)調(diào)試工具也很好使的瀏覽器（簡(jiǎn)直就是神器）。其實(shí)關(guān)于html性能問題，很多博客上都有解釋重繪這個(gè)事。下面主要談?wù)勅绾斡胏hrome鑒別重繪元素。

打開chrome，開啟開發(fā)者工具(F12)。打開模擬器，并選擇需要模擬的設(shè)備，在Console中選擇Rendering 選中第一條（Show paint rectangles）。若打開開發(fā)者工具后沒看見下方Console這塊可以按下Esc。

完成上述操作后，請(qǐng)將視線移動(dòng)到左側(cè)網(wǎng)頁上的綠色矩形框上。

ps：一直都很喜歡淘寶的廣告，創(chuàng)意從未間斷過。

這個(gè)綠色框就是瀏覽器重繪的部分。這個(gè)框越大，說明重繪的區(qū)域也就越大。重繪并沒什么問題，這很正常，不正常的是大面積重繪，比如上圖中的時(shí)間跳動(dòng)，如果僅僅是時(shí)間那個(gè)區(qū)域重繪并沒有什么問題，要是整個(gè)頁面都一直閃著個(gè)綠框框那就完蛋了。為何大面積重繪會(huì)出現(xiàn)性能問題，這個(gè)還得從瀏覽器渲染上談起。那是一個(gè)很長(zhǎng)的故事，有興趣的朋友可以找些資料看看。簡(jiǎn)單的舉例就是，瀏覽器把html文檔解析成網(wǎng)頁展現(xiàn)到我們面前，其中間是一個(gè)“漫長(zhǎng)”的過程。再載入文檔之后需要對(duì)html進(jìn)行分割、讀取并計(jì)算其樣式大小、然后進(jìn)行圖層繪制、合并圖層等一系列操作。整個(gè)過程其實(shí)使用最多的部件是CPU和GPU。

重繪的面積大小和回流（reflows）有關(guān)，關(guān)于回流其實(shí)可以這樣理解，當(dāng)改變一個(gè)元素后對(duì)其它節(jié)點(diǎn)元素產(chǎn)生影響。就如同可石子投入水中引起的波紋一樣，波紋所到之處基本都會(huì)有所影響。而在Html中子節(jié)點(diǎn)的變化會(huì)引起祖先的回流，同時(shí)也會(huì)影響到部分兄弟節(jié)點(diǎn)，大部分的回流將導(dǎo)致頁面的重新渲染。那么如何降低回流，減小重繪面積呢？淘寶時(shí)間不也只更新了一小塊么！這里提供兩種方法：

1、使用 position 屬性的 fixed 值或 absolute 值。
2、創(chuàng)建獨(dú)立的Layer（層）（為避免和div（層）產(chǎn)生混淆文中盡量同一使用Layer）。
繼續(xù)看淘寶：

第一種方法已經(jīng)很明顯了就不再贅述。說說第二種方法吧。首先說說在Chrome中如何查看獨(dú)立的Layer呢。如上圖，選擇Show composited layer borders后在頁面上獨(dú)立的Layer上回顯示一個(gè)橘黃色邊框。那么又要如何才能建立獨(dú)立的Layer呢？

在Chrome中創(chuàng)建獨(dú)立的Layer僅需要符合下述條件之一：

1.有3D元素的屬性；
2.video標(biāo)簽并使用加速視頻解碼；
3.canvas元素并啟用3D；
4.插件，比如flash；
5.CSS動(dòng)畫；
6.CSS濾鏡；
7.有一個(gè)后代元素是獨(dú)立的layer；
8.元素的相鄰元素是獨(dú)立layer。
看上去挺多挺復(fù)雜的，其實(shí)最簡(jiǎn)單、最容易理解、也最容易濫用的是第一條。實(shí)現(xiàn)第一條僅需要在元素的樣式里加上。transform:translateZ(0);-webkit-transform:translateZ(0); 就可以了。我們將淘寶往下滑動(dòng)一點(diǎn)，找一個(gè)元素試試看。

還是看淘寶：

當(dāng)加上css樣式后對(duì)應(yīng)的元素上出現(xiàn)了橘黃色邊框，事實(shí)證明這招是有效的。而在Chrome中這樣做可以啟用GPU硬件加速。初次看到加速兩個(gè)字讓人覺得無比興奮，仿佛找到了克敵制勝的無敵神招。可是，首先這是在chrome下，其次大量使用真的好嗎？

其實(shí)就算是在chrome下GPU也未必能排上用場(chǎng)，首先需要確定你的GPU驅(qū)動(dòng)程序不在chromium的黑名單中。因?yàn)槟承〨PU驅(qū)動(dòng)程序存在錯(cuò)誤，可能會(huì)影響瀏覽器穩(wěn)定，所以會(huì)被加入到黑名單里。在chrome地址欄里輸入 about:gpu 可以查看相關(guān)的GPU信息?，F(xiàn)在再說說GPU加速的事情吧，簡(jiǎn)單點(diǎn)解釋就是通過GPU渲染的Layer，GPU會(huì)將圖層信息緩存起來，到下次改變的時(shí)候就只需要重新渲染修改過的部分。這樣固然是快，但是會(huì)加大系統(tǒng)RAM和GPU的內(nèi)存開銷。在配置參差不齊的移動(dòng)設(shè)備上，過多的層不僅不能加速，反而會(huì)嚴(yán)重影響性能。很多時(shí)候我們?cè)诟杏X到移動(dòng)網(wǎng)頁較卡的時(shí)候不防試試減少頁面上的Layer試試。

通過Chrome我們還可以鑒別一些其他影響性能的方面。比如：

上面兩幅圖，左邊一幅是百度.新聞的移動(dòng)網(wǎng)頁版，箭頭指向的是這個(gè)頁面的loading效果（就是一種一直一直轉(zhuǎn)動(dòng)的感覺）。右邊是以前最常用的一種loading。在效果上兩種方式都一樣，一直不停的轉(zhuǎn)動(dòng)。而區(qū)別在于右邊的loading是一個(gè)帶有背景圖片的div，通過css3使其產(chǎn)生轉(zhuǎn)動(dòng)效果；而右邊則是一張Gif動(dòng)態(tài)圖片。雖然效果上一樣，但在瀏覽其中我們可以看到右邊的loading會(huì)有一個(gè)不停閃動(dòng)的綠色框（頻率相當(dāng)高）。gif動(dòng)畫會(huì)導(dǎo)致瀏覽器不斷的進(jìn)行繪制、柵格化、合成，整個(gè)過程相當(dāng)影響性能，所以最好干掉它。

簡(jiǎn)而言之言而簡(jiǎn)之：

布局

1、減少重繪，減小重繪面積（改良布局，創(chuàng)建獨(dú)立的Layer），降低重繪頻率。
2、合理使用GPU加速，避免過度依賴GPU而導(dǎo)致性能下降。
動(dòng)畫

說完布局，再簡(jiǎn)單談?wù)剟?dòng)畫吧。

常用的JavaScript動(dòng)畫在移動(dòng)web上很多時(shí)候都顯得心有余而力不足（不給力啊）。這個(gè)原因很多， JavaScript動(dòng)畫通常是通過定時(shí)改變?cè)貥邮綄傩缘姆绞絹韺?shí)現(xiàn)，JavaScript的運(yùn)行是在一個(gè)獨(dú)立線程里完成的，作為單線程程序， JavaScript會(huì)因?yàn)槟硞€(gè)耗時(shí)動(dòng)作而影響下一幀動(dòng)畫的執(zhí)行。而且，JavaScript的定時(shí)也并沒有想象中的那么守時(shí)，如在setinterval中設(shè)置每毫秒輸出一個(gè)數(shù)， 當(dāng)輸出到2000次的時(shí)候，當(dāng)真就只需要2秒鐘嗎？相比之下更加推薦使用CSS3來完成相關(guān)動(dòng)畫效果。首先Css由獨(dú)立線程完成，它和JavaScript的運(yùn)行并不沖突， 其次Css3很多屬性不會(huì)觸發(fā)重繪（當(dāng)然JavaScript里也可以是改變的css3的屬性）。 從流暢度上來講的話Css3基本上完勝JavaScript，而且操作較容易。關(guān)于Css3相關(guān)知識(shí)就不再贅述。

然而Css3的動(dòng)畫也并沒有想象中那般完美。

首先，在動(dòng)畫控制上不夠靈活，整動(dòng)畫過程不太好監(jiān)控。
其次，其兼容性不太好。僅移動(dòng)端而言，位移動(dòng)畫通常使用transform，但在某些瀏覽器中需要使用-webkit-transform（如微信里的瀏覽器）。
雖然Css3并非完美解決方案，但實(shí)際使用中大多數(shù)時(shí)候是完全可以解決我們所遇到的問題 （遇到復(fù)雜問題再解決吧，事在人為嘛，解決問題也是一種樂趣）。 且目前的移動(dòng)應(yīng)用上并不推薦過于復(fù)雜的效果設(shè)計(jì)。