在一样的网络环境下,两个一样能知足你的需求的网站,一个“Duang”的一下就加载出来了,一个纠结了半天才出来,你会选择哪一个?研究代表:用户最满意的打开网页时间是2-5秒,若是等待超过10秒,99%的用户会关闭这个网页。也许这样讲,各位还不会有太多感触,接下来我列举一组数据:Google网站访问速度每慢400ms就致使用户搜索请 求降低0.59%;Amazon每增长100ms网站延迟将致使收入降低1%;雅虎若是有400ms延迟会致使流量降低5-9%。网站的加载速度严重影响了用户体验,也决定了这个网站的生死存亡。css
可能有人会说:网站的性能是后端工程师的事情,与前端并没有多大关系。我只能说,too young too simple。事实上,只有10%~20%的最终用户响应时间是用在从Web服务器获取HTML文档并传送到浏览器的,那剩余的时间去哪儿了?来瞄一下性能黄金法则:html
只有10%~20%的最终用户响应时间花在了下载HTML文档上。其他的80%~90%时间花在了下载页面中的全部组件上。前端
接下来咱们将研究一下前端攻城狮如何来提升页面的加载速度。java
上面说到80%~90%时间花在了下载页面中的全部组件进行的HTTP请求上。所以,改善响应时间最简单的途径就是减小HTTP请求的数量。python
图片地图:web
假设导航栏上有五幅图片,点击每张图片都会进入一个连接,这样五张导航的图片在加载时会产生5个HTTP请求。然而,使用一个图片地图能够提升效率,这样就只须要一个HTTP请求。express
服务器端图片地图:将全部点击提交到同一个url,同时提交用户点击的x、y坐标,服务器端根据坐标映射响应后端
客户端图片地图:直接将点击映射到操做浏览器
使用图片地图的缺点:指定坐标区域时,矩形或圆形比较容易指定,而其它形状手工指定比较难缓存
CSS Sprites
CSS Sprites直译过来就是CSS精灵,可是这种翻译显然是不够的,其实就是经过将多个图片融合到一副图里面,而后经过CSS的一些技术布局到网页上。特别是图片特别多的网站,若是能用css sprites下降图片数量,带来的将是速度的提高。
运行结果:
PS:使用CSS Sprites还有可能下降下载量,可能你们会认为合并后的图片会比分离图片的总和要大,由于还有可能会附加空白区域。实际上,合并后的图片会比分离的图片总和要小,由于它下降了图片自身的开销,譬如颜色表、格式信息等。
字体图标
在能够大量使用字体图标的地方咱们能够尽量使用字体图标,字体图标能够减小不少图片的使用,从而减小http请求,字体图标还能够经过CSS来设置颜色、大小等样式,何乐而不为。
合并脚本 和样式表
将多个样式表或者脚本文件合并到一个文件中,能够减小HTTP请求的数量从而缩短效应时间。
然而合并全部文件对许多人尤为是编写模块化代码的人来讲是不能忍的,并且合并全部的样式文件或者脚本文件可能会致使在一个页面加载时加载了多于本身所须要的样式或者脚本,对于只访问该网站一个(或几个)页面的人来讲反而增长了下载量,因此你们应该本身权衡利弊。
若是应用程序web服务器离用户更近,那么一个HTTP请求的响应时间将缩短。另外一方面,若是组件web服务器离用户更近,则多个HTTP请求的响应时间将缩短。
CDN(内容发布网络)是一组分布在多个不一样地理位置的Web服务器,用于更加有效地向用户发布内容。在优化性能时,向特定用户发布内容的服务器的选择基于对网络慕课拥堵的测量。例如,CDN可能选择网络阶跃数最小的服务器,或者具备最短响应时间的服务器。
CDN还能够进行数据备份、扩展存储能力,进行缓存,同时有助于缓和Web流量峰值压力。
CDN的缺点:
一、响应时间可能会受到其余网站流量的影响。CDN服务提供商在其全部客户之间共享Web服务器组。
二、若是CDN服务质量降低了,那么你的工做质量也将降低
三、没法直接控制组件服务器
页面的初次访问者会进行不少HTTP请求,可是经过使用一个长久的Expires头,可使这些组件被缓存,下次访问的时候,就能够减小没必要要的HTPP请求,从而提升加载速度。
Web服务器经过Expires头告诉客户端可使用一个组件的当前副本,直到指定的时间为止。例如:
Expires: Fri, 18 Mar 2016 07:41:53 GMT
Expires缺点: 它要求服务器和客户端时钟严格同步;过时日期须要常常检查
HTTP1.1中引入Cache-Control来克服Expires头的限制,使用max-age指定组件被缓存多久。
Cache-Control: max-age=12345600
若同时制定Cache-Control和Expires,则max-age将覆盖Expires头
从HTTP1.1开始,Web客户端能够经过HTTP请求中的Accept-Encoding头来表示对压缩的支持
Accept-Encoding: gzip,deflate
若是Web服务器看到请求中有这个头,就会使用客户端列出来的方法中的一种来进行压缩。Web服务器经过响应中的Content-Encoding来通知 Web客户端。
Content-Encoding: gzip
代理缓存
当浏览器经过代理来发送请求时,状况会不同。假设针对某个URL发送到代理的第一个请求来自于一个不支持gzip的浏览器。这是代理的第一个请求,缓存为空。代理将请求转发给服务器。此时响应是未压缩的,代理缓存同时发送给浏览器。如今,假设到达代理的请求是同一个url,来自于一个支持gzip的浏览器。代理会使用缓存中未压缩的内容进行响应,从而失去了压缩的机会。相反,若是第一个浏览器支持gzip,第二个不支持,大家代理缓存中的压缩版本将会提供给后续的浏览器,而无论它们是否支持gzip。
解决办法:在web服务器的响应中添加vary头Web服务器能够告诉代理根据一个或多个请求头来改变缓存的响应。由于压缩的决定是基于Accept-Encoding请求头的,所以须要在vary响应头中包含Accept-Encoding。
vary: Accept-Encoding
首先说明一下,将样式表放在头部对于实际页面加载的时间并不能形成太大影响,可是这会减小页面首屏出现的时间,使页面内容逐步呈现,改善用户体验,防止“白屏”。
咱们老是但愿页面可以尽快显示内容,为用户提供可视化的回馈,这对网速慢的用户来讲是很重要的。
将样式表放在文档底部会阻止浏览器中的内容逐步出现。为了不当样式变化时重绘页面元素,浏览器会阻塞内容逐步呈现,形成“白屏”。这源自浏览器的行为:若是样式表仍在加载,构建呈现树就是一种浪费,由于全部样式表加载解析完毕以前务虚会之任何东西
更样式表相同,脚本放在底部对于实际页面加载的时间并不能形成太大影响,可是这会减小页面首屏出现的时间,使页面内容逐步呈现。
js的下载和执行会阻塞Dom树的构建(严谨地说是中断了Dom树的更新),因此script标签放在首屏范围内的HTML代码段里会截断首屏的内容。
下载脚本时并行下载是被禁用的——即便使用了不一样的主机名,也不会启用其余的下载。由于脚本可能修改页面内容,所以浏览器会等待;另外,也是为了保证脚本可以按照正确的顺序执行,由于后面的脚本可能与前面的脚本存在依赖关系,不按照顺序执行可能会产生错误。
CSS表达式是动态设置CSS属性的一种强大而且危险的方式,它受到了IE5以及以后版本、IE8以前版本的支持。
鼠标移动了几回,函数的运行次数垂手可得的达到了几千次,危险性显而易见。
如何解决:
一次性表达式:
事件处理机制
用js事件处理机制来动态改变元素的样式,使函数运行次数在可控范围以内。
做者:MarcoHan
出处:
http://www.cnblogs.com/MarcoHan/p/5295398.html
识别图中二维码,领取python全套视频资料