前言##
對于頁面速度上的優(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)化）醋火。
