尽可能的缓存
尽可能的缓存
2012-03-27 08:54 | 212次阅读 | 来源：译言网
关键词：缓存 | 作者：heavenhuang |
Cache是如此的重要，但长期以来我们对它的认识存在着一些误区。作者Stevesouders通过HTTP Archive 收集的数据，发现在全球前5万的网站中，有46%的网站出现了cache配置不正确的问题，每天有多少流量就这样被白白浪费了？请阅读此文，并共同携手解决这个问题。
“最快的HTTP请求就是不要发起请求。”
我不记得是谁最早提出这个观点，在过去几年里我在无数次聚会和性能优化会议上反复听到这句话，没错！ Cache是网站访问速度优化中重要的一环。我写了一些与此相关的内容：
- Call to improve browser caching
- (lack of) Caching for iPhone Home Screen Apps
- Redirect caching deep dive
- Mobile cache file sizes
- Improving app cache
- Storager case study: Bing, Google
- App cache & localStorage survey
- HTTP Archive: max
在过去一年里，互联网对Cache的使用情况有所改善，但仍然不够快。以下的数据来自HTTP Archive 。我们可以看到，页面可缓存内容较去年增加不足10%，而与此同时，页面请求数增加了12%，页面的总传输体积增加了24%。
也许我们很难迅速的解决这个问题，因为这不仅仅是单方面的，而是涉及了网站开发、第三方提供商和浏览器开发者，但可以肯定的是我们必须做得更好，让更多的内容可以被缓存下来。
在过去的几周里，我收集了一些可靠的数据去证明合理使用Cache的重要性并指引下一步的优化工作：
- 55%的请求缺少 max-age 声明
- 46%的请求缺少 max-age 并且在2周内内容没有发生变化
- 一些在互联网上最流行的资源仅仅只缓存1-2小时
- 40%-60%的用户每天访问你的网站，但缓存无效。
- 30%的用户能够享受缓存带来的便利
- 对用户来说，合理的缓存更新时间应该是 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://www.toyota.jp/ – 172 个资源缺少max-age并且内容在过去1个月内没有变化。
- http://www.sfgate.com/ – 133
- http://www.hasbro.com/ – 122
- http://www.rakuten.co.jp/ – 113
- http://www.ieee.org/ – 97
- http://www.elmundo.es/ – 80
- http://www.nih.gov/ – 76
- http://www.frys.com/ – 68
- http://www.foodnetwork.com/ – 66
- http://www.irs.gov/ – 58
- http://www.ca.gov/ – 53
- http://www.oracle.com/ – 52
- http://www.blackberry.com/ – 50
回顾上面提到的：“最快的HTTP请求就是不要发起请求”，这是很多不必要的流量。鉴于可缓存与非缓存内容之比，在过去一年里没有什么变化，我相信缺少max-age和资源的内容相关性不大，而是因为人们对Cache缺乏认识。
第三方内容
如果一个网站所有者不让他的资源能够被缓存，那是在伤害他自己和用户。对于第三方内容提供商来说，这有正反两面，如果他们没有做cache，受影响的是所有使用他们服务的网站，如果他们做好了则会放大效应。
以下是30个最常用第三方资源列表：
- http://www.google-analytics.com/ga.js（2小时）
- http://ssl.gstatic.com/s2/oz/images/stars/po/Publisher/sprite2.png（8760小时）
- http://pagead2.googlesyndication.com/pagead/js/r20120208/r20110914/show_ads_impl.js（336小时）
- http://pagead2.googlesyndication.com/pagead/render_ads.js（336小时）
- http://pagead2.googlesyndication.com/pagead/show_ads.js（1小时）
- https://apis.google.com/_/apps-static/_/js/gapi/gcm_ppb，googleapis_client，plusone / [...]（720小时）
- http://pagead2.googlesyndication.com/pagead/osd.js（24小时）
- http://pagead2.googlesyndication.com/pagead/expansion_embed.js（24小时）
- https://apis.google.com/js/plusone.js（1小时）
- http://googleads.g.doubleclick.net/pagead/drt/s?safe=on（1小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/y7/r/ql9vukDCc4R.png（3825小时）
- http://connect.facebook.net/rsrc.php/v1/yQ/r/f3KaqM7xIBg.swf（164小时）
- https://ssl.gstatic.com/s2/oz/images/stars/po/Publisher/sprite2.png（8760小时）
- https://apis.google.com/_/apps-static/_/js/gapi/googleapis_client，iframes_styles [...]（720小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/ZSM9MGjuEiO.js（8742小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/qP7Pvs6bhpP.js（8699小时）
- https://plusone.google.com/_/apps-static/_/ss/plusone/ [...]（720小时）
- http://b.scorecardresearch.com/beacon.js（336小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/lP_Rtwh3P-S.css（8710小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yA/r/TSn6F7aukNQ.js（8760小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yk/r/Wm4bpxemaRU.js（8702小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yZ/r/TtnIy6IhDUq.js（8699小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yy/r/0wf7ewMoKC2.css（8699小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yO/r/H0ip1JFN_jB.js（8760小时）
- http://platform.twitter.com/widgets/hub.1329256447.html（87659小时）
- http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/T9SYP2crSuG.png（8699小时）
- http://platform.twitter.com/widgets.js（1小时）
- https://plusone.google.com/_/apps-static/_/js/plusone/ [...]（720小时）
- http://pagead2.googlesyndication.com/pagead/js/graphics.js（24小时）
- 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请求，节省多少流量？
文章出自：译言网