時至5G時代，是否還有必要談：前端性能優化？

以前，何同窗的視頻在網上活了一陣子。引起了咱們思考：5G將會給咱們帶來什麼。同時也回顧了4G乃至3G時代已經給咱們帶來了哪些新的變革。最近，一個問題老是時不時的冒出個人腦海：前端性能優化時候還有必要？

回顧前端性能優化

而後我找到了 雅虎軍規 的 35 條

1. 儘可能減小 HTTP 請求個數——須權衡
2. 使用 CDN（內容分發網絡）
3. 爲文件頭指定 Expires 或 Cache-Control ，使內容具備緩存性。
4. 避免空的 src 和 href
5. 使用 gzip 壓縮內容
6. 把 CSS 放到頂部
7. 把 JS 放到底部
8. 避免使用 CSS 表達式
9. 將 CSS 和 JS 放到外部文件中
10. 減小 DNS 查找次數
11. 精簡 CSS 和 JS
12. 避免跳轉
13. 剔除重複的 JS 和 CSS
14. 配置 ETags
15. 使 AJAX 可緩存
16. 儘早刷新輸出緩衝
17. 使用 GET 來完成 AJAX 請求
18. 延遲加載
19. 預加載
20. 減小 DOM 元素個數
21. 根據域名劃分頁面內容
22. 儘可能減小 iframe 的個數
23. 避免 404
24. 減小 Cookie 的大小
25. 使用無 cookie 的域
26. 減小 DOM 訪問
27. 開發智能事件處理程序
28. 用 link 代替 @import
29. 避免使用濾鏡
30. 優化圖像
31. 優化 CSS Spirite
32. 不要在 HTML 中縮放圖像——須權衡
33. favicon.ico要小並且可緩存
34. 保持單個內容小於25K
35. 打包組件成複合文本

咱們歸檔一下這裏咱們着重說明的網絡相關的優化，而非瀏覽器端性能上的：

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次數的問題：

1. 使 AJAX 可緩存
2. 避免使用濾鏡
3. 保持單個內容小於25K

emmm，好像咱們如今反而比較喜歡使用一些比較炫酷的濾鏡來作一些很驚豔的效果。至於 34，怕是咱們如今一張小圖片都不止 25k 了吧？再者是緩存的問題：單頁面氾濫以及 localStorage 盛行的當下，緩存Ajax信息以及稱爲了咱們的標配。

what？怎麼沒有了？我不服：

6.把 CSS 放到頂部
7.把 JS 放到底部

這兩條怎麼不說？
敢問網速給力的今天，你一個三五百 kb 的 js 文件，即使是放在 head 標籤最開始的位置，你會先看到 HTML 再看到 CSS 的渲染嗎？so，還有必要刻意的糾結把js文件放在底部嗎？
或許你會爲了面子說：放在底部更好代碼更爲規範。但這些已經不重要了。

總結

技術是服務於產品的，產品是面向用戶的。當咱們所作的一些優化對於用戶是無感知的，對於整個項目也不能提升什麼效率的。那就是時候停下來，問一問：是否還有必要這樣作。
固然，說了這麼多，並非但願你們在從此面試的時候，再被問到：前端性能有哪些優化方案的時候，就直接起身掀桌子。畢竟向人民幣適當的低頭也不算一件特別丟人的事情。

這裏，僅僅是我我的見解，你以爲呢？