本文最初發表於，並在github上持續更新前端的系列文章。歡迎在github上關注我，一起入門和高階前端。
以下是正文。提公升頁面效能優化的常見方式：
快取是所有效能優化的方式中最重要的一步【重要】
有的人可能會回答local storage 和session storage，其實不是這個。瀏覽器快取和儲存不是一回事。
瀏覽器第一次開啟頁面時，快取是起不了作用的。這個時候，cdn就上場了。
非同步載入的方式：（這裡不說框架，只說原理）
使用document.createelement建立乙個script標籤，即document.createelement('script')，然後把這個標籤載入到body上面去。
通過非同步的方式載入defer1.js檔案：
html5新增特性。通過非同步的方式載入async1.js檔案：
同步任務
defer1
defer2
同步任務
async2
async1
強快取：不用請求伺服器，直接使用本地的快取。
強快取是利用 http 響應頭中的expires或cache-control實現的。【重要】
瀏覽器第一次請求乙個資源時，伺服器在返回該資源的同時，會把上面這兩個屬性放在response header中。比如：
注意：這兩個response header屬性可以只啟用乙個，也可以同時啟用。當response header中，expires和cache-control同時存在時，cache-control的優先順序高於expires。
下面講一下二者的區別。
1、expires：伺服器返回的絕對時間。
是較老的強快取管理 response header。瀏覽器再次請求這個資源時，先從快取中尋找，找到這個資源後，拿出它的expires跟當前的請求時間比較，如果請求時間在expires的時間之前，就能命中快取，否則就不行。
如果快取沒有命中，瀏覽器直接從伺服器請求資源時，expires header在重新請求的時候會被更新。
缺點：
由於expires是伺服器返回的乙個絕對時間，存在的問題是：伺服器的事件和客戶端的事件可能不一致。在伺服器時間與客戶端時間相差較大時，快取管理容易出現問題，比如隨意修改客戶端時間，就能影響快取命中的結果。所以，在http1.1中，提出了乙個新的response header，就是cache-control。
2、cache-control：伺服器返回的相對時間。
http1.1中新增的 response header。瀏覽器第一次請求資源之後，在接下來的相對時間之內，都可以利用本地快取。超出這個時間之後，則不能命中快取。重新請求時，cache-control會被更新。
協商快取：瀏覽器發現本地有資源的副本，但是不太確定要不要使用，於是去問問伺服器。
當瀏覽器對某個資源的請求沒有命中強快取（也就是說超出時間了），就會發乙個請求到伺服器，驗證協商快取是否命中。
協商快取是利用的是兩對header：
1、last-modified、if-modified-since。過程如下：
（2）瀏覽器再次請求這個資源時，會加上if-modified-since這個 request header，這個header的值就是上一次返回的last-modified的值：
（3）伺服器收到第二次請求時，會比對瀏覽器傳過來的if-modified-since和資源在伺服器上的最後修改時間last-modified，判斷資源是否有變化。如果沒有變化則返回304 not modified，但不返回資源內容（此時，伺服器不會返回 last-modified 這個 response header）；如果有變化，就正常返回資源內容（繼續重複整個流程）。這是伺服器返回304時的response header：
（4）瀏覽器如果收到304的響應，就會從快取中載入資源。
缺點：
last-modified、if-modified-since一般來說都是非常可靠的，但有可能出現的問題是：伺服器上的資源變化了，但是最後的修改時間卻沒有變化。這一對header就無法解決這種情況。於是，下面這一對header出場了。
2、etag、if-none-match。過程如下：
（1）瀏覽器第一次請求乙個資源，伺服器在返回這個資源的同時，會加上etag這個 response header，這個header是伺服器根據當前請求的資源生成的唯一標識。這個唯一標識是乙個字串，只要資源有變化這個串就不同，跟最後修改時間無關，所以也就很好地補充了last-modified的不足。如下：
（2）瀏覽器再次請求這個資源時，會加上if-none-match這個 request header，這個header的值就是上一次返回的etag的值：
3）伺服器第二次請求時，會對比瀏覽器傳過來的if-none-match和伺服器重新生成的乙個新的etag，判斷資源是否有變化。如果沒有變化則返回304 not modified，但不返回資源內容（此時，由於etag重新生成過，response header中還會把這個etag返回，即使這個etag並無變化）。如果有變化，就正常返回資源內容（繼續重複整個流程）。這是伺服器返回304時的response header：
（4）瀏覽器如果收到304的響應，就會從快取中載入資源。
怎麼最快地讓使用者請求資源。一方面是讓資源在傳輸的過程中變小，另外就是cdn。
要注意，瀏覽器第一次開啟頁面的時候，瀏覽器快取是起不了作任何用的，使用cdn，效果就很明顯。
通過 dns 預解析來告訴瀏覽器未來我們可能從某個特定的 url 獲取資源，當瀏覽器真正使用到該域中的某個資源時就可以盡快地完成 dns 解析。
第一步：開啟或關閉dns預解析
你可以通過在伺服器端傳送 x-dns-prefetch-control 報頭。或是在文件中使用值為 http-equiv 的meta標籤：
第二步：對指定的網域名稱進行dns預解析
想學習**之外的軟技能掃一掃，你將發現另乙個全新的世界，而這將是一場美麗的意外：
前端頁面效能優化
最近參加了兩次社招，發現社招面試都會問到效能優化以及框架原理。當中效能優化即使我知道好幾種，然而我面試時總是很容易想不起來，只答出了兩三種。因此，寫一篇部落格來對效能優化做一下研究，加深理解。對於前端效能優化自然要關注首屏開啟速度，而這個速度，很大因素是花費在網路請求上，那麼怎麼減少網路請求的時間呢...
前端小遊戲頁面效能優化
公司是做教育類遊戲開發，以前是用flash製作，現在開始使用createjs框架開發canvas遊戲。今天突然收到乙個任務 遊戲在ipad2下面遊戲會打不開，然後自動重新整理，再載入不出來，然後再重新整理，陷入了死迴圈 通過度娘得知此問題是由越獄或記憶體引起的。排除越獄可能 因為沒有越獄 剩下就是記...
前端跨頁面傳值的幾種方式
1.url傳值這個就不說了獲取location.href之後打斷也好，擷取也好 2.cookie儲存引入jq的js庫cookie.js，之後 cookie key 存，cookie key,value 取 即可，設定時間 刪除cookie等等自己看一下文件 3.h5的web儲存，localstora...