前端优化策略列举(一)

1.尽量减少http请求个数

  • 合并图片(如css sprites,内置图片使用数据)、合并CSS、JS(JsCssZip),这一点很重要,但是要考虑合并后的文件体积。
  • 可见每次请求都会带上一些额外的信息进行传输(这次请求中还没有带cookie),当请求的资源很小,比如1个不到1k的图标,可能request带的数据比实际图标的数据量还大。
  • 所以当请求越多的时候,在网络上传输的数据自然就多,传输速度自然就慢了。

2.为文件头指定Expires或Cache-Control,已缓存资源不再发起http请求,使内容具有缓存性。

  • 区分静态内容和动态内容,避免以后页面访问中不必要的HTTP请求。
  • 对一个网站而言,CSS、JavaScript、图片等静态资源更新的频率都比较低,而这些文件又几乎是每次HTTP请求都需要的,如果将这些文件缓存在浏览器中,可以极好的改善性能。
  • 通过设置http头中的cache-control和expires的属性,可设定浏览器缓存,将静态内容设为永不过期,或者很长时间后才过期。
    • Cache-Control
      Cache-Control属性是在服务器端配置的,不同的服务器有不同的配置,apache、nginx、IIS、tomcat等配置都不尽相同。
      以Apache为例,在http.conf中做如下配置:
<filesMatch ”.(jpg|jpeg|png|gif|ico)$”>  Header set Cache Control max-age=16768000,public  
</filesMatch>  
<filesMatch ”.(css|js)$”>  Header set Cache Control max-age=2628000,public  
</filesMatch>  

    • Expires
      Expires属性也是在服务端配置的,具体的配置也根据服务器而定。

问题:浏览器缓存的资源,若又想更新资源,如何实现?
解决:通过修改该资源的名称来实现。修改了资源名称,浏览器会当做不同的资源。
问题:可能存在客户端时间跟服务端时间不一致的问题。
解决:建议Expires结合Cache-Control一起使用。

3.避免空的src和href

  • 留意具有这两个属性的标签如link,script,img,iframe等;

4.使用gzip压缩内容

  • Gzip压缩所有可能的文件类型以来减少文件体积

5.把CSS放到顶部

  • 实现页面有秩序地加载,这对于拥有较多内容的页面和网速较慢的用户来说更为重要,同时,HTML规范清楚指出样式表要放包含在页面的区域内。

6.把JS放到底部

  • HTTP/1.1 规范建议,浏览器每个主机名的并行下载内容不超过两个,而问题在于脚本阻止了页面的平行下载,即便是主机名不相同。

7.避免使用CSS中expression表达式

  • 页面显示和缩放,滚动、乃至移动鼠标时,CSS表达式的计算频率是我们要关注的。可以考虑一次性的表达式或者使用事件句柄来代替CSS表达式。

8.将CSS和JS放到外部文件中

  • 我们需要权衡内置代码带来的HTTP请求减少与通过使用外部文件进行缓存带来的好处的折中点。

9.精简CSS和JS

  • 目的就是减少下载的文件体积,可考虑压缩工具JSMin和YUI Compressor。

10.剔除重复的JS和CSS(代码的复用性)

  • 重复调用脚本,除了增加额外的HTTP请求外,多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存,它们都存在重复运算JavaScript的问题。

11.使AJAX可缓存

  • 利用时间戳,更精巧的实现响应可缓存与服务器数据同步更新。

    avaScript 获取当前时间戳:

    • 第一种方法:

      var timestamp = Date.parse(new Date());
      结果:1280977330000

    • 第二种方法:
      var timestamp = (new Date()).valueOf();
      结果:1280977330748

    • 第三种方法:

      var timestamp=new Date().getTime();
      结果:1280977330748

    第一种获取的时间戳是把毫秒改成000显示,第二种和第三种是获取了当前毫秒的时间戳。

12.尽早刷新输出缓冲

  • 尤其对于css,js文件的并行下载更有意义

13.使用GET来完成AJAX请求

  • 当使用XMLHttpRequest时,浏览器中的POST方法是一个“两步走”的过程:首先发送文件头,然后才发送数据。在url小于2K时使用GET获取数据时更加有意义。

14.延迟加载

  • 确定页面运行正常后,再加载脚本来实现如拖放和动画,或者是隐藏部分的内容以及折叠内容等。

15.预加载

  • 关注下无条件加载,有条件加载和有预期的加载。

16.尽量减少iframe的个数

  • 考虑即使内容为空,加载也需要时间,会阻止页面加载,没有语意,注意iframe相对于其他DOM元素高出1-2个数量级的开销,它会在典型方式下阻塞onload事件,IE和Firefox中主页面样式表会阻塞它的下载。

17.避免404

  • HTTP请求时间消耗是很大的,有些站点把404错误响应页面改为“你是不是要找*”,这虽然改进了用户体验但是同样也会浪费服务器资源(如数据库等)。

18.减少Cookie的大小

  • 去除不必要的coockie 使coockie体积尽量小以减少对用户响应的影响,设置合理的过期时间。较早地Expire时间和不要过早去清除coockie,都会改善用户的响应时间。

19.优化图像

  • 尝试把GIF格式转换成PNG格式,看看是否节省空间。在所有的PNG图片上运行pngcrush(或者其它PNG优化工具)
    利用sumsh it无损压缩图片。
    其它图片格式与PNG比较

众所周知GIF适合图形,JPEG适合照片,PNG系列两种都适合。

  • 相比GIF
    PNG 8除了不支持动画外,PNG8有GIF所有的特点,但是比GIF更加具有优势的是它支持alpha透明和更优的压缩。所以,大多数情况下,你都应该用PNG8不是GIF(除了非常小的图片GIF会有更好的压缩外)。
  • 相比JPEG
    JPEG比全色PNG具有更加好的压缩,因此也使得JPEG适合照片,但是编辑JPEG过程中容易造成质量的损失,所以全色PNG适合作为编辑JPEG的过渡格式.

这样我们在工作中就有了方向:

  • 色彩丰富的、大的图片切成jpg的;
  • 尺寸小的,色彩不丰富的和背景透明的切成gif或者png8的;
  • 半透明的切成png24。

20.不要在HTML中缩放图像——须权衡

  • 不要为了在HTML中设置长宽而使用比实际需要大的图片。

21.使用CDN(内容分发网络)

  • 这里可以关注CDN的三类实现:镜像、高速缓存、专线,以及智能路由器和负载均衡。

22.避免跳转

  • 为了确保“后退”按钮可以正确地使用,使用标准的 3XXHTTP状态代码;同域中注意避免反斜杠 “/” 的跳转;
  • 跨域使用 Alias或者 mod_rewirte建立 CNAME(保存一个域名和另外一个域名之间关系的DNS记录)

23.配置ETags

  • Entity tags(ETags)(实体标签)是web服务器和浏览器用于判断浏览器缓存中的内容和服务器中的原始内容是否匹配的一种机制(“实体”就是所说的“内 容”,包括图片、脚本、样式表等),是比last-modified date更更加灵活的机制,单位时间内文件被修过多次,Etag可以综合Inode(文件的索引节点(inode)数),MTime(修改时间)和Size来精准的进行判断,避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用,可取后两个参数。使用ETags减少Web应用带宽和负载。

24.减少DOM访问

  • 缓存已经访问过的有关元素
  • 线下更新完节点之后再将它们添加到文档树中
  • 避免使用JavaScript来修改页面布局

25.开发智能事件处理程序

  • 有时候我们会感觉到页面反应迟钝,这是因为DOM树元素中附加了过多的事件句柄并且些事件句病被频繁地触发。这就是为什么说使用event delegation(事件代理)是一种好方法了。
  • 如果你在一个div中有10个按钮,你只需要在div上附加一次事件句柄就可以了,而不用去为每一个按 钮增加一个句柄。事件冒泡时你可以捕捉到事件并判断出是哪个事件发出的。
  • 你同样也不用为了操作DOM树而等待onload事件的发生。你需要做的就是等待树结构中你要访问的元素出现。你也不用等待所有图像都加载完毕。
  • 你可能会希望用DOMContentLoaded事件来代替 事件应用程序中的onAvailable方法。

26.用代替@import

  • 在IE中,页面底部@import和使用作用是一样的,因此最好不要使用它。

27.避免使用滤镜

  • 完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替,这种格式能在IE中很好地工作。如果你确实需要使用 AlphaImageLoader,请使用下划线_filter又使之对IE7以上版本的用户无效。

28.favicon.ico要小而且可缓存

  • favicon.ico是位于服务器根目录下的一个图片文件。它是必定存在的,因为即使你不关心它是否有用,浏览器也会对它发出请求,因此最好不要返回一 个404 Not Found的响应。
  • 由于是在同一台服务器上,它每被请求一次coockie就会被发送一次。这个图片文件还会影响下载顺序,例如在IE中当你在 onload中请求额外的文件时,favicon会在这些额外内容被加载前下载。
  • 因此,为了减少favicon.ico带来的弊端,要做到:文件尽量地小,最好小于1K
  • 在适当的时候(也就是你不要打算再换favicon.ico的时候,因为更换新文件时不能对它进行重命名)为它设置Expires文件头。你可以很安全地 把Expires文件头设置为未来的几个月。你可以通过核对当前favicon.ico的上次编辑时间来作出判断。
  • Imagemagick可以帮你创建小巧的favicon。

29.保持单个内容小于25K

  • 因为iPhone不能缓存大于25K的文件。注意这里指的是解压缩后的大小。
  • 由于单纯gizp压缩可能达不要求,因此精简文件就显得十分重要。

30.打包组件成复合文本

  • 页面内容打包成复合文本就如同带有多附件的Email,它能够使你在一个HTTP请求中取得多个组件(切记:HTTP请求是很奢侈的)。当你使用这条规则时,首先要确定用户代理是否支持(iPhone就不支持)。


本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击【内容举报】进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部