之前，何同學的視頻在網上活了一陣子。引發了我們思考：5G將會給我們帶來什麼。同時也回顧了4G乃至3G時代已經給我們帶來了哪些新的變革。最近，一個問題總是時不時的冒出我的腦海：前端性能優化時候還有必要？
回顧前端性能優化
然後我找到了 雅虎軍規 的 35 條
- 儘量減少 HTTP 請求個數——須權衡
- 使用 CDN（內容分發網絡）
- 爲文件頭指定 Expires 或 Cache-Control ，使內容具有緩存性。
- 避免空的 src 和 href
- 使用 gzip 壓縮內容
- 把 CSS 放到頂部
- 把 JS 放到底部
- 避免使用 CSS 表達式
- 將 CSS 和 JS 放到外部文件中
- 減少 DNS 查找次數
- 精簡 CSS 和 JS
- 避免跳轉
- 剔除重複的 JS 和 CSS
- 配置 ETags
- 使 AJAX 可緩存
- 儘早刷新輸出緩衝
- 使用 GET 來完成 AJAX 請求
- 延遲加載
- 預加載
- 減少 DOM 元素個數
- 根據域名劃分頁面內容
- 儘量減少 iframe 的個數
- 避免 404
- 減少 Cookie 的大小
- 使用無 cookie 的域
- 減少 DOM 訪問
- 開發智能事件處理程序
- 用 link 代替 @import
- 避免使用濾鏡
- 優化圖像
- 優化 CSS Spirite
- 不要在 HTML 中縮放圖像——須權衡
- favicon.ico要小而且可緩存
- 保持單個內容小於25K
- 打包組件成複合文本
我們歸檔一下這裏我們着重說明的網絡相關的優化，而非瀏覽器端性能上的：
1.儘量減少 HTTP 請求個數——須權衡
5.使用 gzip 壓縮內容
10.減少 DNS 查找次數
11.精簡 CSS 和 JS
13.剔除重複的 JS 和 CSS
15.使 AJAX 可緩存
17.使用 GET 來完成 AJAX 請求
29.避免使用濾鏡
31.優化 CSS Spirite
32.不要在 HTML 中縮放圖像——須權衡
33.favicon.ico要小而且可緩存
34.保持單個內容小於25K
35.打包組件成複合文本
然後就剩下這麼幾個了。作爲現在前沿的前端技術，webpack已經幫我們做了5,11,13,33,35。而且其中的13.剔除重複的 JS 和 CSS，在框架盛行的時代，似乎我們已經選擇基於框架的覆寫而非直接修改框架的方式來構建我們的代碼，因爲維護成本。也就是說，我們在成本權衡下回做適當的放棄13.
與此同時，在 resultful 盛行的今天，17. 使用 GET 來完成 AJAX 請求也不能滿足需求，而被部分捨棄。然後字體圖標的流行，把31. 優化 CSS Spirite的問題也變成了歷史。接着我們看看還剩下些什麼：
1.儘量減少 HTTP 請求個數——須權衡
10.減少 DNS 查找次數
15.使 AJAX 可緩存
29.避免使用濾鏡
32.不要在 HTML 中縮放圖像——須權衡
34.保持單個內容小於25K
再去掉需權衡的兩項，因爲這兩項好像在我們日常的工作中已經不再權衡.。接着去掉前端沒法控制的DNS次數的問題：
- 使 AJAX 可緩存
- 避免使用濾鏡
- 保持單個內容小於25K
emmm，好像我們現在反而比較喜歡使用一些比較炫酷的濾鏡來做一些很驚豔的效果。至於 34，怕是我們現在一張小圖片都不止 25k 了吧？再者是緩存的問題：單頁面氾濫以及 localStorage 盛行的當下，緩存Ajax信息以及稱爲了我們的標配。
what？怎麼沒有了？我不服：
6.把 CSS 放到頂部
7.把 JS 放到底部
這兩條怎麼不說？
敢問網速給力的今天，你一個三五百 kb 的 js 文件，即便是放在 head 標籤最開始的位置，你會先看到 HTML 再看到 CSS 的渲染嗎？so，還有必要刻意的糾結把js文件放在底部嗎？
或許你會爲了面子說：放在底部更好代碼更爲規範。但這些已經不重要了。
總結
技術是服務於產品的，產品是面向用戶的。當我們所做的一些優化對於用戶是無感知的，對於整個項目也不能提高什麼效率的。那就是時候停下來，問一問：是否還有必要這樣做。
當然，說了這麼多，並不是希望大家在今後面試的時候，再被問到：前端性能有哪些優化方案的時候，就直接起身掀桌子。畢竟向人民幣適當的低頭也不算一件特別丟人的事情。
這裏，僅僅是我個人看法，你覺得呢？