前言##
對于頁面速度上的優(yōu)化展開可以有太多太多要講，如 淘寶首頁性能優(yōu)化實踐
本文不會對這些具體的優(yōu)化手段做補(bǔ)充，而是通過一個層次的區(qū)分，劃分出需要優(yōu)化或是完善的點，讓所有的點能聯(lián)動起來。
簡介##
執(zhí)行后端--網(wǎng)絡(luò)傳輸--生成模版--渲染視圖
然后可以基于幾個角色考慮，作出權(quán)衡
1.頁面速度（user）
2.開發(fā)效率（developer）
3.資源費用（boss）
執(zhí)行后端##
頁面速度：
1.執(zhí)行業(yè)務(wù)邏輯，獲取數(shù)據(jù)，常見手段于sql優(yōu)化，數(shù)據(jù)結(jié)構(gòu)優(yōu)化，這些優(yōu)化手段交給后端，他們會保證接口穩(wěn)定以及速度。
開發(fā)效率：
1.controller邏輯推到前端，專注業(yè)務(wù)邏輯，減少溝通成本
資源費用：
后端不詳，需要補(bǔ)充。
小結(jié)：后端專注后端
網(wǎng)絡(luò)傳輸##
頁面速度：
1.資源大小：文件壓縮，gzip等
2.連接數(shù)量：COMBO ，BigPipe，多路復(fù)用等
3.網(wǎng)絡(luò)延遲：CDN
開發(fā)效率：
對于開發(fā)透明，所以是無影響
資源費用：
減小網(wǎng)絡(luò)開銷，費用嘛，當(dāng)然是會少滴
小結(jié)：花錢上CDN得到速度上提高;BigPipe,多路復(fù)用需要額外的代碼降級處理;又要寫代碼又要花錢伺候用戶，好累~
生成模版##
頁面速度：
1.根據(jù)路由以及狀態(tài)生成模版
開發(fā)效率：
1.生成模版推到前端（但處于server），增大工作量，減少溝通成本，提高效率
資源費用：
1.對于server壓力增大，老板加配置！
小結(jié)：這里主要一點，將后端的MVC中的C還給前端，滿足前端的控制欲，還能減少溝通成本，增加開發(fā)效率，不過SSR就要在技術(shù)實現(xiàn)上就要多下功夫了。
渲染視圖##
頁面速度：
1.減少reflow
開發(fā)效率：
1.避免HTML，CSS一些用法
2.圖片固定大小
資源費用：
1.對圖片的處理需要記錄信息。
小結(jié)：
渲染上除去前面幾個步驟的影響，其實基本上是考驗HTML，CSS的功底了。
一些小花招##
其實主要在于一點，只要體(dan）驗（che）夠（de）好（hao），并不非得性能走向極致（其實是太菜做不到吧：），所以懶加載圖片，按需加載等手段層出不窮，或是緩存層存儲的是非實時數(shù)據(jù)(兜底數(shù)據(jù))，等等。
說起來這一層面反而是很大的優(yōu)化點，寫的好點效果奇大，畢竟技術(shù)菜，體驗湊。
問題##
強(qiáng)行把這些優(yōu)化的問題分層處于不同的層次感覺有點牽強(qiáng)，算是拋磚引玉吧。有誰給個意見啥的？
結(jié)尾##
嚴(yán)格來說，并不完全算首屏的優(yōu)化，一些優(yōu)化點可以推廣到全頁面。
后續(xù)還需要針對問題補(bǔ)充些具體的方案，以及其他非主場景的折中方案（因為要考慮針對小場景快速優(yōu)化）。
