文件缓存：查询字符串vs最后修改？ [英] File Caching: Query string vs Last-Modified?
问题描述
我是在愚蠢的缓存我的网站的资产的方式，并注意到大多数网站类似于我使用查询字符串来覆盖缓存（例如：/css/style.css?v=124942823）
之后，我注意到，每当我保存我的style.css文件，最后修改的标题是更新，使查询字符串不必要。
所以我不知道：
- 为什么这么多网站使用查询字符串方法，而不是让最后修改的标题
- 我应该取消设置Last-modified标头，只使用查询字符串吗？ （这有什么特别的优点吗？）
谢谢！
TL; DR
为什么这么多网站使用查询字符串
更改查询字符串会更改URL，确保内容是新鲜的。
/ p>
我应该取消设置最后修改的标题，只处理查询字符串吗？
否。虽然这几乎是正确的答案。
网路上使用三种基本的快取策略：
- 未禁用缓存或缓存
- 使用验证/条件请求
- 永久缓存
为了说明这三种情况，请考虑以下情况：
用户第一次访问网站，加载10页和离开。每个页面加载相同的css文件。对于上述每个缓存策略，有多少请求？
无缓存：10个请求
这种情况下，应该清楚，没有任何影响结果，10个请求的css文件将导致它被发送到客户端（浏览器）10次。
优点
- 内容总是新鲜
- 不需要努力/管理
缺点
- 最低效率， li>
验证请求：10个请求
如果。如果是这种情况，对于后续请求，客户端将从其自己的缓存中读取内容，并且根本不与远程服务器通信。
这具有明显的性能优势，
优点
- 效率最高，内容只传输一次
缺点
- 网址必须更改以防止现有访问者加载过时的缓存版本
-
不要对缓存清除使用查询字符串
它是绕过客户端的缓存网站使用查询参数。当内容更改（或如果网站的新版本已发布），查询参数将被修改，因此，当网址已更改时，将请求该文件的新版本。这是比每次更改文件时重命名文件更少的工作/更方便，但它不是没有它的问题，
使用查询字符串阻止代理缓存，在以下引用中，作者显示了来自浏览器代理缓存服务器网站的请求不使用代理缓存：
加载mylogo.gif？v = 1.2两次（清除之间的缓存）结果
在这些头：> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP / 1.1
<< HTTP / 1.0 200 OK
<<日期：星期六，2008年8月23日00:19:34 GMT
<到期日：星期二，2018年8月21日00:19:34 GMT
< X-Cache：MISS from someserver.com
< X-Cache-Lookup：MISS from someserver.com
>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP / 1.1
<< HTTP / 1.0 200 OK
<<日期：2008年8月23日星期六00:19:47 GMT
<到期日：星期二，2018年8月21日00:19:47 GMT
< X-Cache：MISS from someserver.com
< X-Cache-Lookup：MISS from someserver.com
这里很清楚，代理：
缓存响应头指示MISS，Date和Expires值更改，
和拖尾stevesouders.com访问日志显示两个命中。
这不应该轻率 - 当访问实际位于世界另一端的网站响应时间可能非常缓慢。从路径上的代理服务器获取答案可能意味着网站之间的区别可用或不可用 - 在缓存 - 永远的资源的情况下，这意味着网址的第一次加载是慢的，在使用验证请求的情况下
而不是版本控制资产
最好的解决方案是版本控制文件，使得每当内容改变时，url。通常，这将作为构建过程的一部分自动化。
但是，一个接近妥协的是实现一个重写规则如
＃---------------------------------------- --------------------------------------
＃|基于文件名的缓存清除|
＃--------------------------------------------- ---------------------------------
＃如果你不使用构建过程来管理您的文件名版本revving，
＃您可能想考虑启用以下指令将所有
＃请求（如`/ css / style.12345.css'）路由到`/ css / style。 css`。
＃要理解为什么这是重要的，比`* .css？v231`更好的主意，请阅读：
＃http://stevesouders.com/blog/2008/08/23 / revving-filenames-dont-use-querystring
< IfModule mod_rewrite.c>
RewriteCond％{REQUEST_FILENAME}！-f
RewriteRule ^（。+）\。（\d +）\。（js | css | png | jpe？g | gif）$ $ 1. $ 3 [L]
< / IfModule>
以这种方式请求 foo.123.css 由服务器处理为 foo.css - 这具有使用查询参数用于缓存无效化的所有优点，但没有禁用代理缓存的问题。
I was fooling around with ways of caching my website's assets and noticed most websites similar to mine use query strings to override caching (e.g.: /css/style.css?v=124942823)
Afterwards, I noticed that whenever I saved my style.css file, the last-modified headers were "updated", making the query string unnecessary.
So I wonder:
- Why do so many websites use the "query string" method, instead of just letting the last-modified header do its work?
- Should I unset the Last-modified header and just work with query strings? (Is there any particular advantage to this?)
Thanks!
TL;DR
Why do so many websites use the "query string" method, instead of just letting the last-modified header do its work?
Changing the query string changes the url, ensuring content is "fresh".
Should I unset the Last-modified header and just work with query strings?
No. Though that's almost the right answer.
There are three basic caching strategies used on the web:
- No caching, or caching disabled
- Using validation/conditional requests
- Caching forever
To illustrate all three, consider the following scenario:
A user accesses a website for the first time, loads ten pages and leaves. Each page loads the same css file. For each of the above caching strategies how many requests would be made?
No caching: 10 requests
In this scenario, it should be clear that there isn't anything else influencing the result, 10 requests for the css file would result in it being sent to the client (browser) 10 times.
Advantages
- Content always fresh
- No effort/management required
Disadvantages
- Least efficient, content always transferred
Validation requests: 10 requests
If Last-Modified or Etag are used, there will also be 10 requests. However 9 of them will only be the headers, and no body is transferred. Clients use conditional requests to avoid re-downloading something it already has. Take for example the css file for this site.
The very first time the file is requested, the following happens:
$ curl -i http://cdn.sstatic.net/stackoverflow/all.css
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 12 May 2014 07:38:31 GMT
Content-Type: text/css
Connection: keep-alive
Set-Cookie: __cfduid=d3fa9eddf76d614f83603a42f3e552f961399880311549; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.sstatic.net; HttpOnly
Cache-Control: public, max-age=604800
Last-Modified: Wed, 30 Apr 2014 22:09:37 GMT
ETag: "8026e7dfc064cf1:0"
Vary: Accept-Encoding
CF-Cache-Status: HIT
Expires: Mon, 19 May 2014 07:38:31 GMT
CF-RAY: 1294f50b2d6b08de-CDG
.avatar-change:hover{backgro.....Some KB of content
A subsequent request for the same url would look like this:
$ curl -i -H "If-Modified-Since:Wed, 30 Apr 2014 22:09:37 GMT" http://cdn.sstatic.net/stackoverflow/all.css
HTTP/1.1 304 Not Modified
Server: cloudflare-nginx
Date: Mon, 12 May 2014 07:40:11 GMT
Content-Type: text/css
Connection: keep-alive
Set-Cookie: __cfduid=d0cc5afd385060dd8ba26265f0ebf40f81399880411024; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.sstatic.net; HttpOnly
Cache-Control: public, max-age=604800
Last-Modified: Wed, 30 Apr 2014 22:09:37 GMT
ETag: "8026e7dfc064cf1:0"
Vary: Accept-Encoding
CF-Cache-Status: HIT
Expires: Mon, 19 May 2014 07:40:11 GMT
CF-RAY: 1294f778e75d04a3-CDG
Note there is no body, and the response is a 304 Not Modified. This is telling the client that the content it already has (in local cache) for that url is still fresh.
That's not to say this is the optimal scenario. Using tools such as the network tab of chrome developer tools allows you to see exactly how long, and doing what, a request takes:
Because the response has no body, the response time will be much less because there's less data to transfer. But there is still a response. and there is still all of the overhead of connecting to the remote server.
Advantages
- Content always fresh
- Only one "Full" request sent
- Nine requests are much slimmer only containing headers
- More efficient
Disadvantages
- Still issues the maximum number of requests
- Still incurs DNS lookups
- Still needs to establish a connection to the remote server
- Doesn't work offline
- May require server configuration
Caching forever: 1 request
If there are no etags, no last modified header and only an expires header set far in the future - only the very first access to a url will result in any communication with the remote server. This is a well-known? best practice for better frontend performance. If this is the case, for subsequent requests a client will read the content from it's own cache and not communicate with the remote server at all.
This has clear performance advantages, which are especially significant on mobile devices where latency can be significant (to put it mildly).
Advantages
- Most efficient, content only transferred once
Disadvantages
- The url must change to prevent existing visitors loading stale cached versions
- Most effort to setup/manage
Don't use query strings for cache busting
It is to circumvent a client's cache that sites use a query argument. When the content changes (or if a new version of the site is published) the query argument is modified, and therefore a new version of that file will be requested as the url has changed. This is less work/more convenient than renaming the file every time it changes, it is not however without its problems,
Using query strings prevents proxy caching, in the below quote the author is demonstating that a request from browser<->proxy cache server<->website does not use the proxy cache:
Loading mylogo.gif?v=1.2 twice (clearing the cache in between) results in these headers:
>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1 << HTTP/1.0 200 OK << Date: Sat, 23 Aug 2008 00:19:34 GMT << Expires: Tue, 21 Aug 2018 00:19:34 GMT << X-Cache: MISS from someserver.com << X-Cache-Lookup: MISS from someserver.com >> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1 << HTTP/1.0 200 OK << Date: Sat, 23 Aug 2008 00:19:47 GMT << Expires: Tue, 21 Aug 2018 00:19:47 GMT << X-Cache: MISS from someserver.com << X-Cache-Lookup: MISS from someserver.comHere it’s clear the second response was not served by the proxy: the caching response headers say MISS, the Date and Expires values change, and tailing the stevesouders.com access log shows two hits.
This shouldn't be taken lightly - when accessing a website physically located on the other side of the world response times can be very slow. Getting an answer from a proxy server located along the route can mean the difference between a website being usable or not - in the case of cached-forever resources it means the first load of a url is slow, in the case of using validation requests it means the whole site will be sluggish.
Instead version-control assets
The "best" solution is to version control files such that whenever the content changes so does the url. Normally that would be automated as part of the build process.
However a near-compromise to that is to implement a rewrite rule such as
# ------------------------------------------------------------------------------
# | Filename-based cache busting |
# ------------------------------------------------------------------------------
# If you're not using a build process to manage your filename version revving,
# you might want to consider enabling the following directives to route all
# requests such as `/css/style.12345.css` to `/css/style.css`.
# To understand why this is important and a better idea than `*.css?v231`, read:
# http://stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)\.(\d+)\.(js|css|png|jpe?g|gif)$ $1.$3 [L]
</IfModule>
In this way a request for foo.123.css is processed by the server as foo.css - this has all the advantages of using a query parameter for cache busting, but without the problem of disabling proxy caching.
这篇关于文件缓存：查询字符串vs最后修改？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
