Compare Revisions

HTTP caching

Change Revisions

Revision 1108041:

Revision 1108041 by anthony-geoghegan on

Revision 1142057:

Revision 1142057 by rojazzy on

Title:
HTTP caching
Main Event>> Watch UFC 205 Alvarez vs McGregor Live Streaming Online Video!!
Slug:
Web/HTTP/Caching
Web/HTTP/Caching
Tags:
Caching, Guide, HTTP
"Caching" "Guide" "HTTP"
Comment:
Editorial review completed.
Content:

Revision 1108041
Revision 1142057
n8      {{HTTPSidebar}}n8      Main Event>> Watch UFC 205 Alvarez vs McGregor Live S
 >treaming Online Video!!
t10    <p class="summary">t
11      The performance of web sites and applications can be signif
>icantly improved by reusing previously fetched resources. Web cac 
>hes reduce latency and network traffic and thus lessen the time n 
>eeded to display a representation of a resource. By making use of 
> HTTP caching, Web sites become more responsive. 
12    </p>
13    <h2 id="Different_kinds_of_caches">
14      Different kinds of caches
15    </h2>
16    <p>
17      Caching is a technique that stores a copy of a given resour
>ce and serves it back when requested. When a web cache has a requ 
>ested resource in its store, it intercepts the request and return 
>s its copy instead of re-downloading from the originating server. 
> This achieves several goals: it eases the load of the server tha 
>t doesn’t need to serve all clients itself, and it improves perfo 
>rmance by being closer to the client, i.e., it takes less time to 
> transmit the resource back. For a web site, it is a major compon 
>ent in achieving high performance. On the other side, it has to b 
>e configured properly as not all resources stay identical forever 
>: it is important to cache a resource only until it changes, not  
>longer. 
18    </p>
19    <p>
20      There several kinds of caches: these can be grouped into tw
>o main categories: private or shared caches. A <em>shared cache</ 
>em> is a cache that stores responses for reuse by more than one u 
>ser. A <em>private cache</em> is dedicated to a single user. This 
> page will mostly talk about browser and proxy caches, but there  
>are also gateway caches, CDN, reverse proxy caches and load balan 
>cers that are deployed on web servers for better reliability, per 
>formance and scaling of web sites and web applications. 
21    </p>
22    <p>
23      <img alt="What a cache provide, advantages/disadvantages of
> shared/private caches." src="https://mdn.mozillademos.org/files/ 
>13777/HTTPCachtType.png" style="height: 573px; width: 910px;"> 
24    </p>
25    <h3 id="Private_browser_caches">
26      Private browser caches
27    </h3>
28    <p>
29      A private cache is dedicated to a single user. You might ha
>ve seen "caching" in your browser's settings already. A browser c 
>ache holds all documents downloaded via <a href="/en-US/docs/Web/ 
>HTTP" title="en/HTTP">HTTP</a> by the user. This cache is used to 
> make visited documents available for back/forward navigation, sa 
>ving, viewing-as-source, etc. without requiring an additional tri 
>p to the server. It likewise improves offline browsing of cached  
>content. 
30    </p>
31    <h3 id="Shared_proxy_caches">
32      Shared proxy caches
33    </h3>
34    <p>
35      A shared cache is a cache that stores responses to be reuse
>d by more than one user. For example, an ISP or your company migh 
>t have set up a web proxy as part of its local network infrastruc 
>ture to serve many users so that popular resources are reused a n 
>umber of times, reducing network traffic and latency. 
36    </p>
37    <h2 id="Targets_of_caching_operations">
38      Targets of caching operations
39    </h2>
40    <p>
41      HTTP caching is optional, but reusing a cached resource is 
>usually desirable. However, common HTTP caches are typically limi 
>ted to caching responses to {{HTTPMethod("GET")}} and may decline 
> other methods. The primary cache key consists of the request met 
>hod and target URI (oftentimes only the URI is used as only GET r 
>equests are caching targets). Common forms of caching entries are 
>: 
42    </p>
43    <ul>
44      <li>Successful results of a retrieval request: a {{HTTPStat
>us(200)}} (OK) response to a {{HTTPMethod("GET")}} request contai 
>ning a resource like HTML documents, images or files. 
45      </li>
46      <li>Permanent redirects: a {{HTTPStatus(301)}} (Moved Perma
>nently) response. 
47      </li>
48      <li>Error responses: a {{HTTPStatus(404)}} (Not Found) resu
>lt page. 
49      </li>
50      <li>Incomplete results: a {{HTTPStatus(206)}} (Partial Cont
>ent) response. 
51      </li>
52      <li>Responses other than {{HTTPMethod("GET")}} if something
> suitable for use as a cache key is defined. 
53      </li>
54    </ul>
55    <p>
56      A cache entry might also consist of multiple stored respons
>es differentiated by a secondary key, if the request is target of 
> content negotiation. For more details see the information about  
>the {{HTTPHeader("Vary")}} header <a href="#Varying_responses">be 
>low</a>. 
57    </p>
58    <h2 id="Controlling_caching">
59      Controlling caching
60    </h2>
61    <h3 id="The_Cache-control_header">
62      The <code>Cache-control</code> header
63    </h3>
64    <p>
65      The {{HTTPHeader("Cache-Control")}} HTTP/1.1 general-header
> field is used to specify directives for caching mechanisms in bo 
>th requests and responses. Use this header to define your caching 
> policies with the variety of directives it provides. 
66    </p>
67    <h4 id="No_cache_storage_at_all">
68      No cache storage at all
69    </h4>
70    <p>
71      The cache should not store anything about the client reques
>t or server response. A request is sent to the server and a full  
>response is downloaded each and every time. 
72    </p>
73    <pre>
74Cache-Control: no-store
75Cache-Control: no-cache, no-store, must-revalidate
76</pre>
77    <h4 id="No_caching">
78      No caching
79    </h4>
80    <p>
81      A cache will send the request to the origin server for vali
>dation before releasing a cached copy. 
82    </p>
83    <pre>
84Cache-Control: no-cache
85</pre>
86    <h4 id="Private_and_public_caches">
87      Private and public caches
88    </h4>
89    <p>
90      The "public" directive indicates that the response may be c
>ached by any cache. This can be useful, if pages with HTTP authen 
>tication or response status codes that aren't normally cacheable, 
> should now be cached. On the other hand, "private" indicates tha 
>t the response is intended for a single user only and must not be 
> stored by a shared cache. A private browser cache may store the  
>response in this case. 
91    </p>
92    <pre>
93Cache-Control: private
94Cache-Control: public
95</pre>
96    <h4 id="Expiration">
97      Expiration
98    </h4>
99    <p>
100      The most important directive here is "<code>max-age=&lt;sec
>onds&gt;</code>" which the maximum amount of time a resource will 
> be considered fresh. Contrary to {{HTTPHeader("Expires")}}, this 
> directive is relative to the time of the request. For the files  
>in the application that will not change, you can usually add aggr 
>essive caching. This includes static files such as images, CSS fi 
>les and JavaScript files, for example. 
101    </p>
102    <p>
103      For more details, see also the <a href="#Freshness">Freshne
>ss</a> section below. 
104    </p>
105    <pre>
106Cache-Control: max-age=31536000
107</pre>
108    <h4 id="Validation">
109      Validation
110    </h4>
111    <p>
112      When using the "<code>must-revalidate</code>" directive, th
>e cache must verify the status of the stale resources before usin 
>g it and expired ones should not be used. For more details, see t 
>he <a href="#Cache_validation">Validation</a> section below. 
113    </p>
114    <pre>
115Cache-Control: must-revalidate
116</pre>
117    <h3 id="The_Pragma_header">
118      The <code>Pragma</code> header
119    </h3>
120    <p>
121      {{HTTPHeader("Pragma")}} is a HTTP/1.0 header, is not speci
>fied for HTTP responses and is therefore not a reliable replaceme 
>nt for the general HTTP/1.1 <code>Cache-Control</code> header, al 
>though it does behave the same as <code>Cache-Control: no-cache</ 
>code>, if the <code>Cache-Control</code> header field is omitted  
>in a request. Use <code>Pragma</code> only for backwards compatib 
>ility with HTTP/1.0 clients. 
122    </p>
123    <h2 id="Freshness">
124      Freshness
125    </h2>
126    <p>
127      Once a resource is stored in a cache, it could theoreticall
>y be served by the cache forever. Caches have finite storage so i 
>tems are periodically removed from storage. This process is calle 
>d <em>cache eviction</em>. On the other side, some resources may  
>change on the server so the cache should be updated. As HTTP is a 
> client-server protocol, servers can't contact caches and clients 
> when a resource change; they have to communicate an expiration t 
>ime for the resource. Before this expiration time, the resource i 
>s <em>fresh</em>; after its expiration time, the resource if <em> 
>stale</em>. Eviction algorithms often privileges fresh resources  
>over stale resources. Note that a stale resource is not evicted o 
>r ignored; when the cache receives a request for a stale resource 
>, it forwards this requests with a {{HTTPHeader("If-None-Match")} 
>} to check if it isn't in fact still fresh. If so, the server ret 
>urns a {{HTTPStatus("304")}} (Not Modified) header without sendin 
>g the body of the requested resource, saving some bandwidth. 
128    </p>
129    <p>
130      Here is an example of this process with a shared cache prox
>y: 
131    </p>
132    <p>
133      <img alt="Show how a proxy cache acts when a doc is not cac
>he, in the cache and fresh, in the cache and stale." src="https:/ 
>/mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="heigh 
>t: 910px; width: 822px;"> 
134    </p>
135    <p>
136      The freshness lifetime is calculated based on several heade
>rs. If a "<code>Cache-control: max-age=N</code>" header is specif 
>ied, then the freshness lifetime is equal to N. If this header is 
> not present, which is very often the case, it is checked if an { 
>{HTTPHeader("Expires")}} header is present. If an <code>Expires</ 
>code> header exists, then its value minus the value of the {{HTTP 
>Header("Date")}} header determines the freshness lifetime. Finall 
>y, if neither header is present, look for a {{HTTPHeader("Last-Mo 
>dified")}} header. If this header is present, then the cache's fr 
>eshness lifetime is equal to the value of the <code>Date</code> h 
>eader minus the value of the <code>Last-modified</code> header di 
>vided by 10.<br> 
137      The expiration time is computed as follows:
138    </p>
139    <pre>
140expirationTime = responseTime + freshnessLifetime - currentAge
141</pre>
142    <p>
143      where <code>responseTime</code> is the time at which the re
>sponse was received according to the browser. 
144    </p>
145    <h3 id="Revved_resources">
146      Revved resources
147    </h3>
148    <p>
149      The more we use cached resources, the better the responsive
>ness and the performance of a Web site will be. To optimize this, 
> good practices recommend to set expiration times as far in the f 
>uture as possible. This is possible on resources that are regular 
>ly updated, or often, but is problematic for resources that are r 
>arely and infrequently updated. They are the resources that would 
> benefit the most from caching resources, yet this make them very 
> difficult to update. This is typical of the technical resources  
>included and linked from each Web pages: JavaScript and CSS files 
> change infrequently, but when they change you want them to be up 
>dated quickly. 
150    </p>
151    <p>
152      Web developers invented a technique that Steve Sounders cal
>led <em>revving</em><sup><a href="https://www.stevesouders.com/bl 
>og/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></s 
>up>. Infrequently updated files are named in specific way: in the 
>ir URL, usually in the filename, a revision (or version) number i 
>s added. That way each new revision of this resource is considere 
>d as a resource on its own that <em>never</em> changes and that c 
>an have an expiration time very far in the future, usually one ye 
>ar or even more. In order to have the new versions, all the links 
> to them must be changed, that is the drawback of this method: ad 
>ditional complexity that is usually taken care by the tool chain  
>used by Web developers. When the infrequently variable resources  
>change they induce an additional change to often variable resourc 
>es. When these are read, the new versions of the others are also  
>read. 
153    </p>
154    <p>
155      This technique has an additional benefit: updating two cach
>ed resources at the same time will not lead to the situation wher 
>e the out-dated version of one resource is used in combination wi 
>th the new version of the other one. This is very important when  
>web sites have CSS stylesheets or JS scripts that have mutual dep 
>endencies, i.e., they depend on each other because they refer to  
>the same HTML elements. 
156    </p>
157    <p>
158      <img alt="" src="https://mdn.mozillademos.org/files/13779/H
>TTPRevved.png"> 
159    </p>
160    <p>
161      The revision version added to revved resources doesn't need
> to be a classical revision string like 1.1.3, or even a monotono 
>usly growing suite of number. It can be anything that prevent col 
>lisions, like a hash or a date. 
162    </p>
163    <h2 id="Cache_validation">
164      Cache validation
165    </h2>
166    <p>
167      Revalidation is triggered when the user presses the reload 
>button. It is also triggered under normal browsing if the cached  
>response includes the "<code>Cache-control: must-revalidate</code 
>>" header. Another factor is the cache validation preferences in  
>the <code>Advanced-&gt;Cache</code> preferences panel. There is a 
>n option to force a validation each time a document is loaded. 
168    </p>
169    <p>
170      When a cached documents expiration time has been reached, i
>t is either validated or fetched again. Validation can only occur 
> if the server provided either a <em>strong validator</em> or a < 
>em>weak validator</em>. 
171    </p>
172    <h3 id="ETags">
173      ETags
174    </h3>
175    <p>
176      The {{HTTPHeader("ETag")}} response header is an <em>opaque
>-to-the-useragent</em> value that can be used as a strong validat 
>or. That means that a HTTP user-agent, such as the browser, does  
>not know what this string represents and can't predict what its v 
>alue would be. If the <code>ETag</code> header was part of respon 
>se for a resource, the client can issue an {{HTTPHeader("If-None- 
>Match")}} in the header of future requests – in order to validate 
> the cached resource. 
177    </p>
178    <p>
179      The {{HTTPHeader("Last-Modified")}} response header can be 
>used as a weak validator. It is considered weak because it only h 
>as 1-second resolution. If the <code>Last-Modified</code> header  
>is present in a response, then the client can issue an {{HTTPHead 
>er("If-Modified-Since")}} request header to validate the cached d 
>ocument. 
180    </p>
181    <p>
182      When a validation request is made, the server can either ig
>nore the validation request and response with a normal {{HTTPStat 
>us(200)}} <code>OK</code>, or it can return {{HTTPStatus(304)}} < 
>code>Not Modified</code> (with an empty body) to instruct the bro 
>wser to use its cached copy. The latter response can also include 
> headers that update the expiration time of the cached document. 
183    </p>
184    <h2 id="Varying_responses">
185      Varying responses
186    </h2>
187    <p>
188      The {{HTTPHeader("Vary")}} HTTP response header determines 
>how to match future request headers to decide whether a cached re 
>sponse can be used rather than requesting a fresh one from the or 
>igin server. 
189    </p>
190    <p>
191      When a cache receives a request that can be satisfied by a 
>cached response that has a <code>Vary</code> header field, it mus 
>t not use that cached response unless all header fields as nomina 
>ted by the <code>Vary</code> header match in both the original (c 
>ached) request and the new request. 
192    </p>
193    <p>
194      <img alt="The Vary header leads cache to use more HTTP head
>ers as key for the cache." src="https://mdn.mozillademos.org/file 
>s/13769/HTTPVary.png" style="height: 817px; width: 752px;"> 
195    </p>
196    <p>
197      This can be useful for serving content dynamically, for exa
>mple. When using the <code>Vary: User-Agent</code> header, cachin 
>g servers should consider the user agent when deciding whether to 
> serve the page from cache. If you are serving different content  
>to mobile users, it can help you to avoid that a cache may mistak 
>enly serve a desktop version of your site to your mobile users. I 
>n addition, it can help Google and other search engines to discov 
>er the mobile version of a page, and might also tell them that no 
> <a href="https://en.wikipedia.org/wiki/Cloaking">Cloaking</a> is 
> intended. 
198    </p>
199    <pre>
200Vary: User-Agent
201</pre>
202    <p>
203      Because the {{HTTPHeader("User-Agent")}} header value is di
>fferent ("varies") for mobile and desktop clients, caches will no 
>t be used to serve mobile content mistakenly to desktop users or  
>vice versa. 
204    </p>
205    <h2 id="See_also">
206      See also
207    </h2>
208    <ul>
209      <li>
210        <a href="https://tools.ietf.org/html/rfc7234">RFC 7234: H
>ypertext Transfer Protocol (HTTP/1.1): Caching</a> 
211      </li>
212      <li>
213        <a href="https://www.mnot.net/cache_docs">Caching Tutoria
>l – Mark Nottingham</a> 
214      </li>
215      <li>
216        <a href="https://developers.google.com/web/fundamentals/p
>erformance/optimizing-content-efficiency/http-caching">HTTP cachi 
>ng – Ilya Grigorik</a> 
217      </li>
218      <li>
219        <a href="https://redbot.org/">RedBot</a>, a tool to check
> your cache-related HTTP headers. 
220      </li>
221    </ul>

Back to History