以前,何同窗的视频在网上活了一阵子。引起了咱们思考:5G将会给咱们带来什么。同时也回顾了4G乃至3G时代已经给咱们带来了哪些新的变革。最近,一个问题老是时不时的冒出个人脑海:前端性能优化时候还有必要?前端
而后我找到了 雅虎军规 的 35 条webpack
- 尽可能减小 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
- 打包组件成复合文本
咱们归档一下这里咱们着重说明的网络相关的优化,而非浏览器端性能上的:web
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文件放在底部吗?
或许你会为了面子说:放在底部更好代码更为规范。但这些已经不重要了。cookie
技术是服务于产品的,产品是面向用户的。当咱们所作的一些优化对于用户是无感知的,对于整个项目也不能提升什么效率的。那就是时候停下来,问一问:是否还有必要这样作。
固然,说了这么多,并非但愿你们在从此面试的时候,再被问到:前端性能有哪些优化方案的时候,就直接起身掀桌子。毕竟向人民币适当的低头也不算一件特别丢人的事情。网络
这里,仅仅是我我的见解,你以为呢?框架