内联缓存丢失_缓存与内联

内联缓存丢失

2010 update: Lo, the Web Performance Advent Calendar hath moved

2010年更新： Lo， Web Performance Advent Calendar已移动

Dec 10 This post is part of the 2009 performance advent calendar experiment. Stay tuned for the next articles.

12月10日这篇文章是2009年性能出现日历实验的一部分。 请继续关注下一篇文章。

Looking back at the life of Page 2.0. and all the opportunities for optimization, the posts I've put up so far as part of this advent calendar have been mostly around optimizing the waterfall - making it shorter by having fewer components in it. This post will be probably the last in this area of optimization. After that let's talk about having smaller components and then move away from the waterfall and talk about what happens next - rendering, user interaction, JavaScript...

回顾Page 2.0的生命。 以及所有优化的机会，到目前为止，我在此出现日历中发布的帖子主要围绕优化瀑布-通过减少组件的数量来缩短瀑布。 这篇文章可能是该优化领域的最后一篇。 在那之后，让我们讨论一下具有更小的组件，然后离开瀑布，并讨论接下来会发生什么—渲染，用户交互，JavaScript ...

快取 (Caching)

Caching comes into the picture for repeat page visits. When the user comes to your page for the second time, wouldn't it be beautiful if all components are in the cache and the waterfall is really short?

缓存进入图片以供重复页面访问。 当用户第二次访问您的页面时，如果所有组件都在缓存中并且瀑布真的很短，那岂不是很美吗？

Here are the two views - first and repeat - from visiting the same page.

这是访问同一页面的两个视图-第一视图和重复视图。

first view	repeat view

初见	重复检视

Ideally the repeat views should be with full cache and everything should be loaded from the local disk. That's what many people still assume: "Who cares about CSS? It's in the cache. Images? How do you mean sprites? But it's all in the cache, right?" Wrong. There are surprisingly few visits with full cache that we're used to believe. This research demonstrates that on an extremely popular site - yahoo.com - about 50% of the visits are empty cache visits and 20% of all page *views*.

理想情况下，重复视图应具有完整的缓存，并且应从本地磁盘加载所有内容。 那就是许多人仍然假设的：“谁在乎CSS？它在缓存中。图像？您是什么意思？精灵？但是都在缓存中，对吗？” 错误。 令人惊讶的是，我们过去很少相信具有完整缓存的访问。 这项研究表明，在一个非常受欢迎的网站yahoo.com上，大约50％的访问是空的缓存访问，而所有页面的20％*访问*。

You cannot control what the users do what their cache, but you can suggest that their browsers keep a copy of your files for as long as they can.

您无法控制用户执行其缓存的操作，但是可以建议用户的浏览器尽可能长时间地保留文件的副本。

“永不过期”政策 ("Never expire" policy)

The never expire policy is to set a far future Expires (or Cache-Control) header effectively saying to the browser - hey this copy is good for a long time, keep it and reuse it.

永不过期的策略是设置一个有效的远期Expires(或Cache-Control)标头，该标头对浏览器有效-嘿，此副本长期有效，请保留并重复使用。

The way to set the expires header for your static components is to tweak the Apache configuration (in .htaccess if your host gives you no other options) for example like so:

设置静态组件的expires标头的方法是调整Apache配置(如果主机没有其他选择，则在.htaccess )，例如：

ExpiresActive On  
ExpiresByType application/x-javascript "access plus 10 years"  
ExpiresByType text/css "access plus 10 years"
ExpiresByType image/png "access plus 10 years"

Now if you access a PNG on Dec 10th 2009, Apache will add this header to the HTTP response:

现在，如果您在2009年12月10日访问PNG，则Apache会将以下标头添加到HTTP响应中：

Expires: Sun, 10 Dec 2019 05:47:47 GMT

The browser should never request this file again till 2019, effectively "forever".

浏览器永远不要再请求此文件，直到2019年为止，实际上是“永远”。

The drawback is, of course, that you cannot modify this file anymore, since some users have already cached it forever and ever till the end of 2019. If you need to change the file, you have to save it under a different name and update all references to it. For the new name some use consecutive numbers, some use timestamps, some even hashes of the content, so that the name reflects the actual body of the component.

缺点当然是您不能再修改该文件，因为有些用户已经永久地将该文件缓存到了2019年底。如果需要更改该文件，则必须使用其他名称保存并更新对它的所有引用。 对于新名称，一些使用连续数字，一些使用时间戳，甚至使用内容的哈希值，以便该名称反映组件的实际主体。

缓存与内联 (Caching vs. inlining)

External components have a shot at being cached. But on the other hand having inline components (script, styles) means having fewer HTTP requests. Which one is better?

外部组件会被缓存。 但是另一方面，具有内联组件(脚本，样式)意味着具有更少的HTTP请求。 哪一个更好？

It depends from one case to the next but generally inlining is better for first visits (for homepages) and external components are better for repeat visits. But homepages are so 1998, with the modern search engines people find deep content pages and don't browse from the homepage. There are exceptions, of course. Some pages are common user homepages (the first page when the browser loads).

这取决于一个案例到下一个案例，但内联通常对于首次访问(对于首页)更好，而外部组件对于重复访问则更好。 但是首页是如此，1998年，随着现代搜索引擎的出现，人们会找到内容丰富的页面，而不会从首页中浏览。 当然也有例外。 某些页面是普通用户主页(浏览器加载时的第一页)。

Anyway - inline vs. external? How about both?

无论如何-内联还是外联？ 两者呢？

内联，然后缓存 (Inlining, then caching)

During first visits you can inline some components, then once the page is loaded, lazy-load the same components but this time as external files (and proper far-future Expires date).

在首次访问期间，您可以内联某些组件，然后在加载页面后，延迟加载与外部文件相同的组件，但这一次是外部文件(以及适当的远期Expires日期)。

For repeat visits, you only link to the external components as they are already in the cache!

对于重复访问，您只需链接到外部组件，因为它们已在缓存中！

So how do you determine first visits? How can you tell that the user's cache is empty?

那么，您如何确定首次访问？ 您如何分辨用户的缓存为空？

You can use cookies and assume missing cookie means empty cache. Drawbacks: 1. someone can delete cache without deleting cookies and 2. what happens when the external component updates

您可以使用cookie并假设缺少cookie意味着缓存为空。 缺点：1.有人可以删除缓存而不删除Cookie； 2.外部组件更新时会发生什么

Both of these scenarios are not so bad, because the page will still work, only less optimally. And you can take care of 2. by introducing (complexity and) a component version information in the cookie.

这两种情况都还不错，因为页面仍然可以工作，但优化程度较低。 并且，您可以通过在cookie中引入(复杂性和)组件版本信息来进行维护。

Oh, and drawback 3. - writing longer term cookies increases the size of your headers.

哦，还有缺点3.-编写更长时间的cookie会增加标题的大小。

Another option is to track sessions only and assume empty cache for all new sessions. This way you don't need longer-term (and unreliable, see drawback 1.) cookies. In this case the problem might be that you may be missing out on optimizing the first visit in the session. The user may have visited the site yesterday, closed the browser and there she comes today with the full bag of cached components. But you assume first visit = empty handed visit, so you don't benefit from the components already in the cache during the first page view.

另一种选择是仅跟踪会话，并为所有新会话假定为空缓存。 这样，您就不需要长期(也不可靠，请参见缺点1)Cookie。 在这种情况下，问题可能是您可能错过了优化会话中的首次访问的机会。 用户昨天可能访问了该站点，关闭了浏览器，今天她带着一整袋缓存的组件来到了那里。 但是您假设首次访问=空手访问，因此您在第一页视图期间不会从缓存中已有的组件中受益。

Which case is the right for you? Only your logs and experimentation can tell.

哪种情况适合您？ 只有您的日志和实验可以告诉您。

For an example in the wild, check Bing's search results. The first visit in the session you get a number of inline stylesheets, which then get lazy-loaded as external files. Second search in the same session and you get the stylesheets as external files.

例如，请查看Bing的搜索结果。 在会话中的第一次访问时，您将获得许多内联样式表，然后这些样式表会作为外部文件进行延迟加载。 在同一会话中第二次搜索，您将样式表作为外部文件获取。

谢谢阅读！ (Thanks for reading!)

And that concludes the "fewer HTTP requests" part of the calendar. Tomorrow's topic will be about making smaller those components that slip through the cracks of the HTTP reduction effort.

日历的“ HTTP请求减少”部分到此结束。 明天的主题将是使那些减少HTTP减少工作量的组件变得更小。

Tell your friends about this post on Facebook and Twitter

在Facebook和Twitter上告诉您的朋友有关此帖子的信息

翻译自: https://www.phpied.com/caching-vs-inlining/

内联缓存丢失