前言##

對于頁面速度上的優化展開可以有太多太多要講，如 淘寶首頁性能優化實踐

本文不會對這些具體的優化手段做補充，而是通過一個層次的區分，劃分出需要優化或是完善的點，讓所有的點能聯動起來。

簡介##

執行后端--網絡傳輸--生成模版--渲染視圖

然后可以基于幾個角色考慮，作出權衡
1.頁面速度（user）
2.開發效率（developer）
3.資源費用（boss）

未命名文件.png

執行后端##

頁面速度：
1.執行業務邏輯，獲取數據，常見手段于sql優化，數據結構優化，這些優化手段交給后端，他們會保證接口穩定以及速度。

開發效率：
1.controller邏輯推到前端，專注業務邏輯，減少溝通成本

資源費用：
后端不詳，需要補充。

小結：后端專注后端

網絡傳輸##

頁面速度：
1.資源大小：文件壓縮，gzip等
2.連接數量：COMBO ，BigPipe，多路復用等
3.網絡延遲：CDN

開發效率：
對于開發透明，所以是無影響

資源費用：
減小網絡開銷，費用嘛，當然是會少滴

小結：花錢上CDN得到速度上提高;BigPipe,多路復用需要額外的代碼降級處理;又要寫代碼又要花錢伺候用戶，好累~

生成模版##

頁面速度：
1.根據路由以及狀態生成模版

開發效率：
1.生成模版推到前端（但處于server），增大工作量，減少溝通成本，提高效率

資源費用：
1.對于server壓力增大，老板加配置！

小結：這里主要一點，將后端的MVC中的C還給前端，滿足前端的控制欲，還能減少溝通成本，增加開發效率，不過SSR就要在技術實現上就要多下功夫了。

渲染視圖##

頁面速度：
1.減少reflow

開發效率：
1.避免HTML，CSS一些用法
2.圖片固定大小

資源費用：
1.對圖片的處理需要記錄信息。

小結：
渲染上除去前面幾個步驟的影響，其實基本上是考驗HTML，CSS的功底了。

一些小花招##

其實主要在于一點，只要體(dan）驗（che）夠（de）好（hao），并不非得性能走向極致（其實是太菜做不到吧：），所以懶加載圖片，按需加載等手段層出不窮，或是緩存層存儲的是非實時數據(兜底數據)，等等。
說起來這一層面反而是很大的優化點，寫的好點效果奇大，畢竟技術菜，體驗湊。

問題##

強行把這些優化的問題分層處于不同的層次感覺有點牽強，算是拋磚引玉吧。有誰給個意見啥的？

結尾##

嚴格來說，并不完全算首屏的優化，一些優化點可以推廣到全頁面。
后續還需要針對問題補充些具體的方案，以及其他非主場景的折中方案（因為要考慮針對小場景快速優化）。