1. HTML5終于名正言順地沖上歷史的舞臺,無論是應用還是游戲 2. HTTP/2第14個草案版已發布,正式版將于明年發布。通過引進報頭字段 壓縮以及多路復用來更有效利用網絡資源、減少感知延遲(TTI)。另外還 介紹了服務器推送規范。 https://github.com/fex-team/http2- spec/blob/master/HTTP2%E4%B8%AD%E8%8B%B1%E5%AF%B9% E7%85%A7%E7%89%88(06-29).md 3. HTML5的調用能力和開發手法在變化。可以了解百度BlendUI 4. 盡管全棧工程師是后端課程,但我們擁抱移動互聯網 3. 一切的前端優化是為了節省資源,最終優化成用戶體驗,其次,一切都在 飛速地變化,不要把所有的內容當作終極的教條 #Quickling 與 PageCache 5. 前端鏈接監聽與處理 6. 好處:公共資源不用重復下載解析,只需要得到內容部分的 7. 更進一步:PageCache 緩存 8. 對比 AngularJS 的實現:admin-flatify 關于 onhashchange 事件的描述以下不正確的是? A. onhashchange 事件,在當今主流瀏覽器中都支持。 B. onhashchange 事件,在早期的瀏覽器里,可以采用較頻 繁定期檢測地址實現或者采用iframe實現 C. 如果不支持 onhashchange 事件,并不影響quickling技 術中的鏈接指向定位,但會影響前進和后退定位 D. 只要URL發生變化,就會引發onhashchange事件 實現要點 1 鏈接監聽 2 歷史管理器與永久鏈接支持 3 忙指示 4 統計時間變更影響 緩存問題 1 頁面更新怎么辦? 2 Ajax 獲取(動態) 3 即時更新(評論) 效果 1 Quickling Reduce user perceived latency by more than 10% Save 10% of Facebook’s data center cost! 2 PageCache 10X speedup in user perceived speed Save 2% of Facebook’s data center cost!    這張圖有什么特點? 1. 最大的特點是順序執行,當然,在某些節點上有并行的因素 2. 其次是:步驟繁多,周期漫長,但遠遠不細 3. 用戶在最后的步驟才見到頁面! 4. 問題:有沒有什么辦法提速?今天給你不一樣的答案 5. #BigPipe 演進 1 史前 認識到頁面輸出的局限性 ? 頁面沒有完成,無以輸出 2 演進中 我們可以通過Flush出內容,來獲得提前 的內容輸出,一步一輸出 3 達成 先輸出框架,再JS填充內容  Bigpipe 第二層次 1 資源下載與重用 ? 事實的Bigpipe 還涉及到資源的處理 2 并行處理與輸出 ? 并行處理,實現真正的 Bigpipe 3 SEO 與搜索引擎友好 ? 通過 UA(User Agent)的檢測來判定,如果是搜索引擎, 不啟用Bigpipe 做一個鏈接檢測的例子 第一步:順序處理 第二步:提供 flush 第三步:并行獲取 第四步:不成功的子進程實驗 一個 Bigpipe的第三方庫 ? https://github.com/linares/bigpipe ? 支持資源 ? 模擬FB的實現 有關bigpipe 以下說法不正確的是? A. bigpipe 的核心思想是并發輸出,這個一般服務器都支持 B. bigpipe 是一種前后端相結合的優化技術 C. bigpipe 先輸出頁面框架,再輸出內容 D. bigpipe方式,對比Ajax優化方式填充內容的好處在于并 不需要發起多個請求 答案a 1. 清空LocalStorage, 觀測天貓的類目和樓層輸出 2. Bigpipe是稍緩后輸出內容,先讓你看到框架,感 覺速度加快 3. 類目、樓層、瀑布流是到了才去取,不到不去取 前端性能優化神器 1. Firebug + YSlow 2. PageSpeed Insights 可能需要翻墻