关闭

尽可能的缓存

标签: cachearchivecaching浏览器chromemozilla
676人阅读 评论(0) 收藏 举报
分类:

                                          尽可能的缓存

2012-03-27 08:54 | 212次阅读 | 来源:译言网  

关键词:缓存 | 作者:heavenhuang |

           转载自:http://sd.csdn.net/a/20120327/313562.html

Cache是如此的重要,但长期以来我们对它的认识存在着一些误区。作者Stevesouders通过HTTP Archive 收集的数据,发现在全球前5万的网站中,有46%的网站出现了cache配置不正确的问题,每天有多少流量就这样被白白浪费了?请阅读此文,并共同携手解决这个问题。

“最快的HTTP请求就是不要发起请求。”

我不记得是谁最早提出这个观点,在过去几年里我在无数次聚会和性能优化会议上反复听到这句话,没错! Cache是网站访问速度优化中重要的一环。我写了一些与此相关的内容:

在过去一年里,互联网对Cache的使用情况有所改善,但仍然不够快。以下的数据来自HTTP Archive 。我们可以看到,页面可缓存内容较去年增加不足10%,而与此同时,页面请求数增加了12%,页面的总传输体积增加了24%。

也许我们很难迅速的解决这个问题,因为这不仅仅是单方面的,而是涉及了网站开发、第三方提供商和浏览器开发者,但可以肯定的是我们必须做得更好,让更多的内容可以被缓存下来。

在过去的几周里,我收集了一些可靠的数据去证明合理使用Cache的重要性并指引下一步的优化工作:

  1. 55%的请求缺少 max-age 声明
  2. 46%的请求缺少 max-age 并且在2周内内容没有发生变化
  3. 一些在互联网上最流行的资源仅仅只缓存1-2小时
  4. 40%-60%的用户每天访问你的网站,但缓存无效。
  5. 30%的用户能够享受缓存带来的便利
  6. 对用户来说,合理的缓存更新时间应该是 4小时

最重要的一条规则:必须指定 max-age

我以前写过不少Cache优化相关的文章,但前提是你已经在Http头中对cache的使用进行声明。例如以下例子,请求将被缓存1年。

“Cache-Control: max-age=31536000”

因为你在阅读本文,所以你可能已经使用了max-age,但来自HTTP Archive 的数据表明 55%的资源并没有指定一个max-age。这表示重复访问一个网站,在81个资源中依然有45个资源需要发起新的http请求。

缺少 max-age != 动态

为什么有55%的资源没有指定 Cache信息?看着这来自世界各地数以千计的数据时,我第一个猜测是开发者缺乏对缓存的认识,另外一个猜测是他们认为那些资源是动态的不需要缓存(JSON,广告,标记等)。究竟是哪个原因导致的呢?幸好我们可以量化这些数据,并从中找出这些没有被Cache的内容有多少是真正动态的。

HTTP Archive 分析了全球前5万名的网站页面,在每月1号和15号记录下页面中每个请求的信息。使用这些历史记录对比,我们就能找到本月15号和上一个月15号之间,那些内容没有发生改变,或者再向前推1一个月。HTTP Archive的分析是基于相同的URL,Last-Modified,ETag和Content-Length。

46%缺少max-age的请求在过去至少2周的时间里内容没有发生改变,这表示在上文提到45个缺少max-age的请求中有21个资源是应该从缓存访问但实际上没有。超过一个月内容没有发生变化的有38%,也就是有17个资源出现了上述的问题。

这是严重的失职,以下是一些主流网站中出现缺少max-age声明的资源数量:

回顾上面提到的:“最快的HTTP请求就是不要发起请求”,这是很多不必要的流量。鉴于可缓存与非缓存内容之比,在过去一年里没有什么变化,我相信缺少max-age和资源的内容相关性不大,而是因为人们对Cache缺乏认识。

第三方内容

如果一个网站所有者不让他的资源能够被缓存,那是在伤害他自己和用户。对于第三方内容提供商来说,这有正反两面,如果他们没有做cache,受影响的是所有使用他们服务的网站,如果他们做好了则会放大效应。

以下是30个最常用第三方资源列表:

  1. http://www.google-analytics.com/ga.js(2小时)
  2. http://ssl.gstatic.com/s2/oz/images/stars/po/Publisher/sprite2.png(8760小时)
  3. http://pagead2.googlesyndication.com/pagead/js/r20120208/r20110914/show_ads_impl.js(336小时)
  4. http://pagead2.googlesyndication.com/pagead/render_ads.js(336小时)
  5. http://pagead2.googlesyndication.com/pagead/show_ads.js(1小时)
  6. https://apis.google.com/_/apps-static/_/js/gapi/gcm_ppb,googleapis_client,plusone / [...](720小时)
  7. http://pagead2.googlesyndication.com/pagead/osd.js(24小时)
  8. http://pagead2.googlesyndication.com/pagead/expansion_embed.js(24小时)
  9. https://apis.google.com/js/plusone.js(1小时)
  10. http://googleads.g.doubleclick.net/pagead/drt/s?safe=on(1小时)
  11. http://static.ak.fbcdn.net/rsrc.php/v1/y7/r/ql9vukDCc4R.png(3825小时)
  12. http://connect.facebook.net/rsrc.php/v1/yQ/r/f3KaqM7xIBg.swf(164小时)
  13. https://ssl.gstatic.com/s2/oz/images/stars/po/Publisher/sprite2.png(8760小时)
  14. https://apis.google.com/_/apps-static/_/js/gapi/googleapis_client,iframes_styles [...](720小时)
  15. http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/ZSM9MGjuEiO.js(8742小时)
  16. http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/qP7Pvs6bhpP.js(8699小时)
  17. https://plusone.google.com/_/apps-static/_/ss/plusone/ [...](720小时)
  18. http://b.scorecardresearch.com/beacon.js(336小时)
  19. http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/lP_Rtwh3P-S.css(8710小时)
  20. http://static.ak.fbcdn.net/rsrc.php/v1/yA/r/TSn6F7aukNQ.js(8760小时)
  21. http://static.ak.fbcdn.net/rsrc.php/v1/yk/r/Wm4bpxemaRU.js(8702小时)
  22. http://static.ak.fbcdn.net/rsrc.php/v1/yZ/r/TtnIy6IhDUq.js(8699小时)
  23. http://static.ak.fbcdn.net/rsrc.php/v1/yy/r/0wf7ewMoKC2.css(8699小时)
  24. http://static.ak.fbcdn.net/rsrc.php/v1/yO/r/H0ip1JFN_jB.js(8760小时)
  25. http://platform.twitter.com/widgets/hub.1329256447.html(87659小时)
  26. http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/T9SYP2crSuG.png(8699小时)
  27. http://platform.twitter.com/widgets.js(1小时)
  28. https://plusone.google.com/_/apps-static/_/js/plusone/ [...](720小时)
  29. http://pagead2.googlesyndication.com/pagead/js/graphics.js(24小时)
  30. http://s0.2mdn.net/879366/flashwrite_1_2.js(720小时)

一些有趣的特征:

  • 越简单的url缓存时间越短。
  • 越长的url缓存时间越长。
  • 短缓存的脚本往往是异步的。

这些受欢迎的第三方资源在缓存方面都表现得不错,但是我们如果把第三方widget考虑在内的话整体评价需要降级,另外第三方供应商需要更好的支持异步脚本,避免对页面造成阻塞。

Cache的容量太小

在2007年,我和Tenni Theurer在Yahoo!做了一个实验,通过在页面底部插入一个1x1的透明图片并且把过期时间设在了过去的时间,这样当用户从缓存访问了这个文件,我们将收到一个 304的请求,而如果用户没有缓存这个文件,我们则会收到一个200请求。我们惊讶的发现,有40%-60%的活跃用户访问我们的网站而没有cache,20%的pv访问同样不带cache。

有许多因素导致用户访问无cache的比例过高,但我相信主要的原因是因为浏览器的缓存容量限制太小了。自这个2007年以来,浏览器厂商已纷纷修改了他们的浏览器缓存容量限制,但这还不够。我们很难对浏览器cache容量限制进行统计,Blaze.io’s 的文章 Understanding Mobile Cache Sizes中提供了一些测试数据。而我在我的MacBook Air上测得了如下数据(有些浏览器的缓存容量限制是基于磁盘的可用空间,我的测试环境是250GB磁盘中有54GB可用。

  • Chrome: 320 MB
  • Internet Explorer 9: 250 MB
  • Firefox 11: 830 MB (shown in about:cache)
  • Opera 11: 20 MB (shown in Preferences | Advanced | History)
  • iPhone 4, iOS 5.1: 30-35 MB (based on testing)
  • Galaxy Nexus: 18 MB (based on testing)

我很惊讶的发现 FF 11居然有如此之大的缓存,几乎满足我所有的需要了,其他则显得太小了。在我的移动设备上仅仅只有18-35M的缓存,我有7部电影在我的iphone中,我很愿意把钢铁侠2的1.82G换取更多的缓存空间。

真实的缓存情况

我需要一些统计数据来证明,有多少用户因为缓存溢出而失去网站的缓存。在上个月的 Velocity Summit 中有来自Chrome, Internet Explorer, Firefox, Opera, Silk的代表(Safari受邀但没有来。来自Chrome SPDY小组的Will Chan分享在window chromes上收集到最翔实的cache统计数据)

  • 约30%的用户cache已满(320MB)
  • 用户主动访问约4小时将填满他们cache
  • 7%用户每周最少清空cache一次
  • 19%用户至少每周一次因为缓存内容被释放导致cache无效

最后一点比较有意思,IE9的开发团队也遇到了类似的问题, IE7&8的缓存大小限制是50MB,这是基于他们的测试验证缓存大小和缓存命中率无关。但是当他们在IE9开发过程中重新仔细审视这一测试时发现了不同的结论:

“在IE9开发过程中,我们非常重视缓存的设计。经过仔细的观察我们发现之所以IE7&8测试中发现缓存大小和命中率无关是因为 此前对可缓存内容及清理缓存的算法功能上有缺陷,修复这些问题后,我们发现缓存大小确实与缓存命中率相关,基于这结论,我们已调整了cache容量限制算法,提供比过去更大的cache空间。”

Will提到 Chrome 将重新考虑320MB的容量上限,30%用户cache已满似乎比例不高,但考虑到很多非常积极的和活跃用户主要集中访问少数网站(例如只访问 gmail, facebook, twitter)。如果有可能的话我想看到这些用户行为和cache的相关性统计。

下一步工作

以上的数据大部分来自 HTTP Archive,所以要感谢我们的赞助商:sponsors:Google, Mozilla, New Relic, O’Reilly Media, Etsy, Strangeloop, dynaTrace Software, and Torbit

这些数据集表明了问题主要集中在以下几个方面:

网站开发者:需要更多的使用Cache-Control max-age,以及设置更长的有效时间。38%的资源在1个月内无变化,却只有11%资源有指定max-age。大部分资源的更新可以通过改变url的时间戳实现。只有第三方提供的脚本引用片段适合使用短的cache时间(小时),真正需要每次动态访问的内容(JSON等)应该在请求中指定:must-revalidate。 希望一年后,我们能看到55%的资源可以被cache 一个月以上的时间,而不是55%资源没有指定max-age。

第三方开发者:需要更好的使用缓存和仿效Google,Twitter,Facebook的异步脚本片段。

浏览器开发者:需要提供更大的cache容量限制,尤其是在移动设备上。需要考虑cache清除算法和用户行为的关联(例如我经常访问的网站),也许能在用户访问他们喜欢的网站时提供更好的访问速度。

去年,HTTP请求数增长超过了10%,而cache则增长过慢。明年我们迫切的期望能看到资源的cache命中率增加一倍,试想一下,这能避免多少HTTP请求,节省多少流量?

文章出自:译言网

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1016649次
    • 积分:14446
    • 等级:
    • 排名:第895名
    • 原创:106篇
    • 转载:835篇
    • 译文:0篇
    • 评论:82条
    最新评论