英文原文：
Reloading post-onload resources
两个最好的功能理论是
增加一个远期的失效工夫和增加
延迟加载资本（特殊是剧本）在onload事情以后。可是这些最好理论的组合却招致了用户很难刷新资本的状况。更确实的说，点击重载（或乃至shift+重载）其实不能在irefox, Chrome, Safari, Android,和 iPhone中刷新这些缓存的，延迟加载的资本。
我们等待重载能带来甚么
阅读器有一个缓存（或10个），那边它保管呼应的拷贝。假如用户觉得那些缓存的后果曾经陈腐，她可以点击重载按钮疏忽缓存并刷新一切，以此包管她看到的是网站内容的最新的拷贝。在HTTP标准中我找不就任何会商重载按钮的材料，但据我所知一切阅读器都有这类特征。
- 假如你点击重载（或 control+R 或 command+R)，一切资本将以有前提的GET恳求方法刷新(携有能否自前次以来修正和能否不适配的校验)。假如Server呼应的版本没有变更，它会前往简洁的不含呼应主体的“304 Not Modified”形态。假如呼应改动则呼应“200 OK”并前往全体的呼应主体。
- 假如你点击shift+Reload (或r control+Reload 或 control+shift+R 或 command+shift+R)，那末一切的资本就会用不带校验头的方法刷新。因为每一个呼应主体都会前往，这要低效一些，可是确保了一切缓存的失真的呼应都被掩盖重写。
最最少，我们盼望点击重载的时分失掉网站资本的最新版本而不论其失效工夫，shift+重载会更努力的做到这些。
其它翻译版本 (1)
加载中
欢送重载2.0
在Web1.0时期，资本经过HTML标签的方法恳求—IMG, SCRIPT, LINK等等。在Web2.0，资本常常主动态恳求。两个广泛的例子是异步加载剧本（例如Google Analytics）和图片静态获得（例如扭转灯笼式图片或下方区域图片延迟加载）。有时这些资本在窗口onload以后被恳求，以使主页能更快的衬着供给更好的用户体验，更好的目标等等。假如资本有一个好久当前的失效工夫，阅读器则需求特殊的智能去做准确的工作。
- 假如用户以正常方法阅读到该页(点击一个link，输出一个URL，应用一个书签等等)并且静态的资本在缓存中，阅读器将运用缓存拷贝（假定失效工夫仍在将来）
- 假如用户重载了该页，阅读器将从头获得一切资本，包含页面中静态加载的资本。
- 假如用户重载了该页，我想onload处置顺序中加载的资本也异样被从头获得。这些多是页面根底架构的一部分，它们该当在用户想刷新页面内容的时分从头获得。
- 可是假如用户重载页面的时分，有资本在onload事情以后加载，阅读器在该做甚么？有点web使用经过保管数小时甚至数天的session来坚持活动形态。假如用户重载了，一切在web使用性命期内的静态的资本会疏忽cache从头获得吗？
一个例子：
我们看一个例子：Postonload Reload
这个页面用五种分歧的方法加载图片与剧本：
- 标签 – 根底的HTML道路：<img src=和<script src=.
- 注释中静态 – 在页面注释中是一个剧本块，静态的创立一幅图片和一段剧本，设置SRC来获得资本。这些代码在onload之前履行。
- 加载时 – 在onload处置顺序中静态的创立一段剧本和一幅图片。
- 加载后1 ms – 经过在onload处置顺序中的1毫秒setTimeout回调，静态的创立一段剧本和一幅图片。
- 加载后5秒– 经过在onload处置顺序中的5秒setTimeout回调，静态的创立一段剧本和一幅图片。
一切图片和剧本有一个将来一个月的失效期。假如用户点击重载，哪个技术会从头获得？固然我们盼望1和2可以惹起从头获得。我盼望3也从头获得。我想4应当会从头获得可是迷惑于很多阅读器能否能做到，另有5可能不会从头获得。排一下你等待的后果然后看看下面的表格。
后果
在重视载的后果之前，我们看一下假如用户只是阅读到该页会发作甚么。这是经过点击例子中“try again”链接完成的。在这类状况下，没有资本被从头获得。一切的资本都标着将来一个月失效期被存入缓存，所以我测试的阅读器都只是从缓存中读出它们。这很好正如我们预期。
可是我们看下面表中捕捉的重载的后果，行动变得分化了。
| Table 1. Resources that are refetched on Reload |
| technique |
resource |
Chrome 25 |
Safari 6 |
Android Safari/534 |
iPhone Safari/7534 |
Firefox 19 |
IE 8,10 |
Opera 12 |
| markup |
image 1 |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| script 1 |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| dynamic |
image 2 |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| script 2 |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| onload |
image 3 |
- |
- |
- |
- |
Y |
Y |
Y |
| script 3 |
- |
- |
- |
- |
- |
Y |
Y |
| 1ms postonload |
image 4 |
- |
- |
- |
- |
- |
- |
Y |
| script 4 |
- |
- |
- |
- |
- |
- |
Y |
| 5sec postonload |
image 5 |
- |
- |
- |
- |
- |
- |
- |
| script 5 |
- |
- |
- |
- |
- |
- |
- |
Chrome, Safari, Android mobile Safari和iPhone mobile Safari 的后果是一样的。当你在这些阅读器中点击重载 ，页面中的资本被从头取得（资本1和2），可是在onload处置顺序中和以后加载的资本却纷歧样（资本3-5）。
Firefox很成心思。它重载了页面中的四种资本包含onload处置顺序的图片（image 3），可是不包含onload处置顺序的剧本（script 3）。很奇异。
IE8和10是一样的：他们重载了页面中的四种资本，和onload处置顺序中的image和script(资本1-3)。我没有测试IE9但我猜它也是一样的。
以我的观念Opera具有最好的后果。它从头获得了主页面中的一切资本，onload处置顺序中的，和onload 1ms当前的，可是它没有从头获得onload5秒当前加载的资本（image 5 和 script 5）。我在此多做了几个测试。假如将延迟由1ms进步到50ms，那末image 4 和 script 4就不会从头获得了。我想这是一种竞争的状况，当这些初次延迟加载的资本被创立的时分，Opera经过onload处置顺序依然鄙人载资本，与此同时它们被从头获得了。为了进一步证明这一点，我将延迟进步到500ms而且确信资本没有被从头获得，但当一切资本呼应工夫进步到1秒(而不是瞬时)，这便使得 image 4 和 script 4 被从头获得，即便延迟是在onload以后500ms。
留意敲击shift+重载（和其他组合）不克不及改动这些后果。
播种
有点难明？可能。这是一个小范畴问题的深化讨论，我向你供认。但有一些破例：
假如你是一个运用超长失效期和延迟加载的web开发职员，你可能在改动一个资本且点击重载，乃至是shift+重载的时分得不到希冀的后果。假如你没有失掉开发资本的最新版本，你可能不能不肃清你的缓存。
这不单单是有关web开发者的问题。它也影响到用户。十分多的网站采取了具有超长失效期的延迟加载，包含在排名前10位的网站中的8个：Google, YouTube, Yahoo, Microsoft Live, Tencent QQ, Amazon 和 Twitter。假如你用列出来的前四个阅读器，翻开包嗅探器，重载这些网站的任何一个，你将看到一个奇异的形式：可缓存的资本在onload之前加载，带有304呼应形态，而onload以后的从缓存读出来其实不会从头获得。独一确保取得最新版本的方法是清空缓存，这使得重载按钮的希冀价值幻灭了。
这里是Amazon在Chrome阅读器下的恳求瀑布流。白色竖线就是onload事情时辰。留意到几多资本在onload之间前往304形态。红线右边onload以后一些图片不被缓存，所以被再恳求前往200形态。而可以缓存的图片在onload以后都从缓存中读取，因而这些资本都得不到更新。
最初，不管什么时候都应当细心研讨分歧阅读器的行动究竟是为何。常常一些行动优先于另外一个，我们应当把这些特征和厂商对应起来。在重载页面的状况时，我们应当更一致地从头加载一切资本，即便是onload事情后的静态资本。
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
