深圳网站建设哪家好?深圳做网站就找深圳乐道网络科技有限公司,乐道网络科技-专业的网站建设公司、网站建设工作室

News新闻

业界新闻动态、技术前沿
Who are we?

您的位置:首页      网站建设知识      WebKit]管好页面缓存

WebKit]管好页面缓存

最快的网络请求就是不发请求。”


无论何时有人说到这句话,我都会心一笑。这的确是真理,HTTP Cache对网页速度至关重要。

现在缓存的使用看似正渐入佳境,但还不够。下面HTTP Archive的数据显示在过去一年里(2011),  缓存的资源增加了10%,而同时页面资源却增加了12%,页面数据量增加了24%(css" rel="external nofollow" style="color: rgb(202, 0, 0); text-decoration: none;" target="_blank">http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/lP_Rtwh3P-S.css (8710 hours)

  • http://static.ak.fbcdn.net/rsrc.php/v1/yA/r/TSn6F7aukNQ.js (8760 hours)
  • http://static.ak.fbcdn.net/rsrc.php/v1/yk/r/Wm4bpxemaRU.js (8702 hours)
  • http://static.ak.fbcdn.net/rsrc.php/v1/yZ/r/TtnIy6IhDUq.js (8699 hours)
  • http://static.ak.fbcdn.net/rsrc.php/v1/yy/r/0wf7ewMoKC2.css (8699 hours)
  • http://static.ak.fbcdn.net/rsrc.php/v1/yO/r/H0ip1JFN_jB.js (8760 hours)
  • http://platform.twitter.com/widgets/hub.1329256447.html (87659 hours)
  • http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/T9SYP2crSuG.png (8699 hours)
  • http://platform.twitter.com/widgets.js (1 hour)
  • https://plusone.google.com/_/apps-static/_/js/plusone/[...] (720 hours)
  • http://pagead2.googlesyndication.com/pagead/js/graphics.js (24 hours)
  • http://s0.2mdn.net/879366/flashwrite_1_2.js (720 hours)
  • 其中有些有趣的发现.

    • 简单的URLs有着较短的缓存时间 – 一些资源时间特别短,它们常常是在粘贴到页面中的一个片段。短的缓存时间有利于解决一些紧急的问题。
    • 较长的URLs有着同样较长的缓存时间 – 许多第三方bootstrap脚本会动态地加载其它资源,他们所生成的URLs一般都比较长,里面含有一些唯一标识符。如果出现了紧急问题,负责加载的脚本会被修改支加载不同URL的资源,这样就不需要对应更新那些资源了。
    • Facebook中点赞按钮去哪了? – Facebook的like.php和likebox.php是经常被使用的,但没有出现在上面的列表里。原因是不同的页面下会有一个唯一标识,从而降低了总体的占比。相比于那些负责加载的脚本,它们有着更为激进的过期策略,如no-cache, no-store, must-revalidate。
    • 拥有较短缓存时间的资源通常是异步的 – 为那些bootstrap脚本指定较短的缓存时间有利于应对紧急状况,但会因为发送条件更新(Conditional GET)请求而影响性能。幸运地是一些第三方资源开发者已经意识到这个问题,并提供了异步的方式来加载这些脚本,以减少较短的缓存时间带来的影响。

    常用的第三方资源通常有不错的表现,但当我们考察更多的资源时,就可以发现这里相当的提升空间。


    缓存容量不足 

    根据2007年的一项实验(experiment) 40%-60%的用户没有所浏览页面的缓存,其中20%的浏览页面没有本地缓存。


    缺少足够缓存的原因很多,我认为其中最重要的原因是过小的缓存容量。下面是我在我自己的设备测试的数据(一些浏览器的缓存大小会基于可用磁盘空间计算,而我的磁盘是250GB,其中54GB可用。):

    • Chrome:320MB
    • Internet Explorer 9:250 MB
    • Firefox 11: 830 MB (about:cache)
    • Opera 11: 20 MB (Preferences | Advanced | History)
    • iPhone 4, iOS 5.1: 30-35 MB (基于测试)
    • Galaxy Nexus: 18 MB (基于测试)

    除了Firefox 11比较接近我期望的大小,其它的都太小了。一部钢铁侠2也有1.82GB了,根本不够用。(让浏览器中缓存多媒体文件!!!!!)。


    现实的缓存状况 

    为了提供让浏览增加缓存容量的依据,必须要获取真实用户的统计数据。为此参与Velocity Summit的各家浏览器团队一起完成了一项课题 。特别推荐Will Chan的提交的这篇Chromium cache metrics,里面列出了一些非常有价值的缓存数据。

    主要数据有:

    • 近30%用户的缓存全满(320 MB)
    • 对于缓存满的用户,他们平均要花4小的浏览时间(约20小时)才会填满缓存
    • 7%的用户至少一周清一次缓存
    • 19%用户会一周经历一次"缓存损坏"的错误,然后清掉他们的缓存

    最后一项关于缓存损坏的统计非常有趣,我非常欣赏这样的坦率。IE9团队有着相似的数据(something similar). IE 7&8 将缓存容量限制在50MB, 因为基于测试当时发现超过50MB并没有提升缓存命中率。而IE9中,他们终于知道更大的缓存容量的确可以改善缓存命中率:

    In IE9, we took a much closer look at our cache behaviors to better understand our surprising finding that larger caches were rarely improving our hit rate. We found a number of functional problems related to what IE treats as cacheable and how the cache cleanup algorithm works. After fixing these issues, we found larger cache sizes were again resulting in better hit rates, and as a result, we’ve changed our default cache size algorithm to provide a larger default cache.


    Will也认识到Chrome的320MB缓存限制需要更新。对于拥有全满缓存的用户而言,30%的比例有些偏低。不过用户也许只对少量的页面比较活跃,比如是只看看Gmail和Facebook。建议加一下针对活跃度的统计。很可能一个用户常常浏览大量的网页,虽然拥有满满的缓存,却体验着低效的页面加载时间。


    下一步 

    浏览器开发者对于改进缓存责无旁贷。1)提升缓存容量就是改进之一,特别是对于移动设备。2)需要提供和缓存容量及用户行为相关的数据。3)更加有效的淘汰算法(比如IE 9′s prioritization based on mime type )。 4)更加关注个性化,当用户访问常用页面可以得到更快的体验。


    转载请注明出处: http://blog.csdn.net/horkychen  

    原文地址: Cache them if you can