cakephp - 使用 CakePHP(和 Asset Compress)处理图像缓存

Question

来自 Yahoo! 的 Best Practices for Speeding Up Your Web Site文档:

Expires headers are most often used with images, but they should be used on all components including scripts, stylesheets, and Flash components.

我使用“mod_expires”Apache 模块遵循上述建议。我的实现很像 HTML5 Boilerplate 的。见 this .htaccess code .

这是来自同一雅虎的另一个报价!文档:

Keep in mind, if you use a far future Expires header you have to change the component's filename whenever the component changes. At Yahoo! we often make this step part of the build process: a version number is embedded in the component's filename, for example, yahoo_2.0.6.js.

我已经使用 Mark Story 的 Asset Compress 处理了我的 CSS 和 JavaScript 文件。插入。只需将 Asset Compress 的 shell 作为构建过程的一部分。

现在对于我遇到的两个问题，都与图像有关:

我有定期的 <img>我的网站上都有标签，我也有 CSS background-image s。我目前没有一种优雅的方式来处理这两种图像中的任何一种的缓存破坏。对于 <img>标签，我的“core.php”文件中有这一行:

Configure::write('Asset.timestamp', 'force');

虽然这确实提供了一种自动处理 <img> 的缓存破坏的方法。标签(假设标签是使用 $this->Html->image(...) 生成的)，我不认为这很优雅，原因有两个:

它使用查询字符串 not recommended .

每次访问特定 View 时都会检查图像的时间戳。是的，您可以缓存 View ，但您可能希望在 View 的缓存版本过期之前更新该 View 中的图像，因此您必须执行触发该 View 重新缓存所需的任何操作，我认为这不优雅。

至于处理 CSS 的缓存破坏 background-image s，我必须手动更新 LESS 文件。绝对不优雅。

CakePHP 和/或 Asset Compress 应该如何处理图像缓存？

Answer 1

缓存失效、性能和网络
人们普遍认为编程中最难做的事情之一是cache invalidation .然而，对于 Assets (js 文件、css 文件、图像等)来说，提供 Web Assets 并不是真正的最佳逻辑:

服务于long cache expiry (1 年)

Don't use etags

如果 Assets 更改，请更改 url

然而，当应用于网络时，有一个复杂的问题。
考虑对 /css/main.css 的请求，包含:

body {
    background-image:url('../img/bar.gif');
}

显然，这将触发对 /img/bar.gif 的请求。加载 css 文件时。假设图像带有适当的标题，只有两种方法可以加载 bar.gif 的更新版本:

更改css文件的内容

更改css文件所在的文件夹

第一个是有问题的，如果它不是自动化的(即使是自动化的，也可能出错)，第二个很容易。
版本前缀 Assets url -> 再也不会有问题
解决 css/js/files 问题的一种简单方法是使您的内部版本号成为 url 的一部分:

/v123/css/foo.css
 ^

您可以通过修改您的应用程序助手 webroot 功能来做到这一点，例如:

public function webroot($file) {
    $file = parent::webroot($file);
    if (Configure::read('debug')) {
        return $file;
    }

    return '/' . Configure::read('App.version') . $file;
}

顺便说一句，使用 cdn 是相同的技术——这可能是提高前端性能所能做的最好的事情。
通过这种方式，当您提升您的网站版本时 - 所有 Assets 都会获得新的网址。请注意，使用此技术，所有引用的 Assets 都需要使用相对 url，而不是绝对:

.foo {
    /* background-image:url('/img/bar.gif'); // won't work */
    background-image:url('../img/bar.gif');
}

否则，对 css 文件的请求是特定于应用程序版本的，但引用的图像不是，即使使用新的应用程序版本，也会从浏览器缓存(如果相关)中读取。
实现相同的结果，不更改文件系统
您可以使用重写规则 similar to the one in h5bp's如果您不想更改文件夹结构，则用于文件名缓存清除:

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^/v\d+/(css|files|js)/(.+)$ /$1/$2 [L]
</IfModule>

这意味着网址 /v123/css/main.css提供 /css/main.css 的内容在请求时。
解析css文件很复杂
你在评论中提到

I think the fact that changing one asset causes all assets to be re-downloaded is a deal-breaker

除非您每分钟都发布一个新的生产版本 - 这不会成为问题(除非您有 GB 的缓存内容，在这种情况下......您有不同的问题)。拥有特定于文件的高性能缓存逻辑的唯一方法是例如将站点中的每个文件存储为文件内容的 sha1 - 应用于 css 文件，这意味着替换 ../img/foo.gif与 ../img/<hash of foo.gif's contents>.gif .
没有什么可以停止使用多种技术，例如使用以下结构:

app
    webroot
        css
            img <- css assets only
        fonts
        img
        js

您可以为您的 css、字体和 js 请求添加版本前缀；间接地对 css-images 执行相同的操作(假设它们使用 background-image:url('img/bar.gif'); 形式的相对 URL)，而不将相同的逻辑应用于其他 Assets (用户头像、他们上传的猫视频等)。
或者对所有图像使用数据 uri
这就是谷歌所做的=)。
归根结底，您需要在构建过程的复杂程度和真正的好处之间做出选择。众多用户 have empty browser caches ，因此对于随机用户而言，应用程序的缓存逻辑很可能仅适用于他们当前的访问——一次性使整个 Assets 缓存过期并不是一件坏事的主要原因之一。