2009-09-16 108 views
4

堆栈的尊重溢出,HTTP缓存,浏览器差异

所以我最近一直试图围绕HTTP资源缓存完全包装我的头。值得注意的是,现在我正在查看一个简单的缓存图像,该图像用于在页面中呈现图标/小图片。下面是我看到的奇怪行为的解释:

因此,在给定的页面上,我只有一个图像:icons.sprite.gif。有四个元素使用精灵在页面上显示各种图标。在我的Apache配置,我已经安装了指定mod_expires和以下缓存控制指令:

ExpiresActive On 
ExpiresDefault "access plus 300 seconds" 

ExpiresByType text/html "access plus 1 day" 
ExpiresByType text/css "access plus 1 day" 
ExpiresByType text/javascript "access plus 1 day" 
ExpiresByType image/gif "access plus 1 week" 
ExpiresByType image/jpg "access plus 1 week" 
ExpiresByType image/png "access plus 1 week" 
ExpiresByType application/x-shockwave-flash "access plus 1 day" 

现在,这里的怪事。在Safari中,当我加载页面时,net-inspector只显示一个精灵的请求。这是完美的,按预期工作。另一方面,在Internet Explorer和Firefox中,Fidder/Firebug揭示了四个成功的sprill图像请求=什么!?随后的请求导致单个缓存命中,但是第一个加载包含四个并发请求。这似乎是一个相当大的wtf,因为它似乎绕过了整个spriting的重点,这是为了减少给定页面加载周期中资源请求的数量。

什么可能会发生:

的页面加载速度不够快的时候第二个元素呈现于使用拼合背景图片文件,对于精灵的第一个请求尚未完成。因此,如果资源尚未被缓存,随着后续元素的渲染,它们会导致对资源的新请求,即使它已被加载。 Safari以某种方式处理并防止这种情况(我知道Safari的缓存实践与其他浏览器有所不同)。

所以 - 我在这里寻找一些确认/输入。这些浏览器是否“按预期工作” - 此外,它否定了与spriting相关的性能收益(这会引入css维护复杂性)?或者,我在做什么错了?

我很欣赏你的想法/建议。

干杯,

Skone

回答

4

因此,经过广泛的嗡嗡声之后,我想出了如何解决这个问题。

让我们说,例如,我创建一个精灵并使用CSS如下:

.icon { 
    background: transparent url(/media/common/images/sprite.gif) scroll no-repeat 0 -33px; 
} 

.logo { 
    background: transparent url(/media/common/images/sprite.gif) scroll no-repeat 0 -10px; 
} 

在Firefox中,这将导致该图像的两个请求,而不是针对图像的单个请求。此修复程序,因此,是巩固CSS规则这样:

.sprited { 
    background: transparent url(/media/common/images/sprite.gif) scroll no-repeat 0 0; 
} 

.icon { 
    background-position: 0 -33px; 
} 

.logo { 
    background-position: 0 -10px; 
} 

我意识到这本身是比较合适的,因为它避免了拼合元件之间的background属性的重复。

无论如何,希望这证明对另一个spriter是有用的!

编辑:经过一些额外的测试后,这实际上只发生在Mozilla Firefox(与平台无关)。 Safari和IE将同一图像的多个引用解释为单个请求,而Firefox似乎对通过CSS链接到的每个图像发出一个独特的请求。

我意识到它可能并没有被明确地理解为一个错误,但是在浏览器争相被标记为最快的时代 - 看起来像是Firefox的潜在改进!

你们认为什么,我应该将它作为错误提交给Mozilla吗?

1

你的情况分析,似乎是想正确的方向。以下是我的一些想法:

一,最大连接数的概念。浏览器设置不同。与此相关的是,Firefox /其他浏览器可能会尝试在多个连接上加载相同的资源,直到成功完成为止,而Safari只会为给定资源尝试一个连接。

二,Safari是否只打一个电话?还是仅仅报告一次成功的通话?也就是说,Safari对给定资源发出4次请求,第一次请求完成,剩下的将被忽略并不报告。

三,Safari是否更快?尝试更大的图像或通过Safari中的慢速连接进行下载,以查看它是否与其他浏览器具有相同的“问题”。

最后,我一般不相信这会否定使用精灵的性能收益。在有几个10或100个图像的情况下,精灵确实有助于减少http请求。如果你使用精灵来制作少量图像(例如5-10),那么在这种情况下几乎没有意义。

与HTTP请求无关的精灵的另一个好处涉及到交互延迟。过去,IE浏览器只会在元素上显示图像(例如悬停)时才下载图像,从而在悬停状态下产生延迟。精灵解决了这个问题。