之前，何同学的视频在网上活了一阵子。引发了我们思考：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 文件放在底部吗？
或许你会为了面子说：放在底部更好代码更为规范。但这些已经不重要了。
总结
技术是服务于产品的，产品是面向用户的。当我们所做的一些优化对于用户是无感知的，对于整个项目也不能提高什么效率的。那就是时候停下来，问一问：是否还有必要这样做。
当然，说了这么多，并不是希望大家在今后面试的时候，再被问到：前端性能有哪些优化方案的时候，就直接起身掀桌子。毕竟向人民币适当的低头也不算一件特别丢人的事情。
这里，仅仅是我个人看法，你觉得呢？