声明:文章内容主要从慕课网性能优化的视频中学习得来 以及 加上自己的测试和理解
2.1 http 的请求过程以及潜在的性能优化点 .
思考问题: 浏览器的一个请求从发送到返回都经历了什么 ?
我们了解了 整个过程会更好的理解使用什么样的解决方案来优化Web性能 也就是如何让页面更快的展示出来. 目的就是为了快!
网络请求过程.png
注意: CDN的域名不要和主站的一样 ,会有cookie带着一起在RequestHeader发过去 .这实际上是不需要的,占用了带宽 .
请求过程中潜在的性能优化点:
- dns 是否可以通过缓存减少dns查询时间
- 网络请求的过程走最近的网络环境
- 相同的静态资源是否可以缓存?
- 能否减少请求http请求大小 ?
- 减少http请求
- 服务端渲染
2.2 资源的合并与压缩
主要分两步 : 第一步尽量少的减少http请求数量 (合并)
第二步减少请求资源的大小 (压缩)
看一下新浪的首页的代码
打开网页 ,然后鼠标右键, 点击查看网页源代码 :
新浪.png
看一下百度首页的代码 .
百度.png
然后翻了个墙看了下 谷歌的代码
谷歌.png
效果还是比较明显的
谷歌和百度首页的html 是经过压缩过的.
html 压缩
HTML代码压缩就是压缩这些在文本文件中有意义,但是在HTML中不显示的字符 ,包括 空格,制表符,换行符等,还有一些其他意义的字符,如HTML注释也可以被压缩
很明显 谷歌和百度的源码中没有 新浪中的换行符
看一下压缩效果:
html压缩效果.png
可以看见最上边是一个蓝色的 ,总监是红色的 最下边的是黑色的.
蓝色的线 表示没有压缩过的.
红色的线 表示经过html压缩的
下边黑色的线,表示经过Gzip 也说之后的效果.
可以看出来, 蓝红之间的差距不是特别大 .24k 的html 代码压缩之后就可能是22k,
看起来效果不是特别明显, 但是如果访问的量级特别大的话 ,这个微笑的差距还是巨大的. 每年还是可以给这些巨头省很多的钱.
那么问题来了? 为啥新浪不压缩 ?
接下来就是如何进行html压缩,
- 使用在线网站进行压缩,(这个企业级的应用不会用.安全,性能等角度考虑,自己玩玩还行)
- nodejs提供了 html-minifier 工具 ,(可以进行配置,按照需要进行压缩)
- 后端模板引擎渲染压缩
CSS压缩以及JS压缩
谷歌的例子就不传了. 反正就是跟上边的差不多. 没有换行都贴在一起的.
CSS压缩会做两件事
- 无效代码删除
- css语义合并,(语义重复的需要合并)
如何进行css 压缩 ? - 在线网站压缩,同上
- 使用html-minifier ,同上
- 使用 clean-css 对css 进行压缩
JS压缩与混乱
- 无效字符的删除
- 剔除注释
- 代码语义的缩减和优化
- 代码保护
总体上来说 ,压缩就是去语义化的过程, 我们平常写的注释或者回车换行就是为了理解起来更轻松,看起来更简单些, 电脑不需要这些,js 中变量定义形参可能比较长,压缩之后就会变成a, b 这种简单的,反正电脑能看懂就行.
不想让黑客知道具体的核心业务代码,代码风格变得混乱变得不可读,
JS和css 的压缩的收益要比html压缩 效果明显.
Look 新浪js 也没压缩.
新浪.png
2.3 文件合并
网络请求文件.png
都是需要加载a,b,c 三个js文件, 两个区别:
左边分别请求a,b,c 三个js 文件 , 而右边一次请求 a-b-c.js 合并之后的文件 .
右边请求数量更少.
那么对比两个优缺点
左边缺点:
- 文件与文件之间有插入的上行请求,增加了N-1个网络延迟
- 受丢包问题影响更严重
- 经过代理服务器时可能会被断开.
右边的缺点 : - 首屏渲染问题 (如果100 个js 都放在一起,但是首页显示只需要一个js 那么首页显示就会等到全部js 加载完才能完成渲染.,用户体验不好)
- 缓存失效的问题 (缓存的时候a+ md5码 .js 这种形式缓存, 如果还是100 个js 文件打包成一个,改动了一个文件,其实只需要更新1个js 文件, 但是合并之后就全更新)
那么怎么用?
- 公共库合并(这里边的几乎不会变,单独打包 )
- 不同的页面的合并.(结合懒加载, 路由加载到当前页面再加载当前页面的js 文件 )
- 见机行事,随机应变
之前是单个js 的压缩和混乱, 这里是多个js 文件的合并.
按照需求合并.
合并方式:
- 使用在线网站进行文件合并
- 使用nodejs 实现文件合并
网友评论