When the browser finds an expired cached response, it can send a small token (usually a hash of the file's contents) to the server to check if the file has changed. The server can return a Cache-Control directive to specify how, and for how long, the browser and other intermediate caches should cache the individual response. The following headers all factor into effective caching behavior: The part of the HTTP caching setup that matters the most is the headers that your web server adds to each outgoing response. That's beyond the scope of this guide, though! Response headers: configure your web server # This is good news-it means that you can continue including tags like in your HTML, and the browser automatically takes care of HTTP caching for you, without extra effort.ĭevelopers who do need more control over the HTTP Cache in their web application have an alternative-you can "drop down" a level, and manually use the Fetch API, passing it Request objects with specific cache overrides set.
Request headers that affect checking for freshness, like If-None-Match and If-Modified-Since just appear based on the browser's understanding of the current values in the HTTP Cache. While there are a number of important headers that should be included in your web app's outgoing requests, the browser almost always takes care of setting them on your behalf when it makes requests. Request headers: stick with the defaults (usually) #
#ADDING PUBLIC PRIVATE CACHE HEADER CODE#
In an ideal scenario, you'll have control over both the code for your web application (which will determine the request headers) and your web server's configuration (which will determine the response headers).Ĭheck out MDN's HTTP Caching article for a more in-depth conceptual overview. The HTTP Cache's behavior is controlled by a combination of request headers and response headers. If there's a match, the response is read from the cache, which eliminates both the network latency and the data costs that the transfer incurs. Last-Modified How the HTTP Cache works #Īll HTTP requests that the browser makes are first routed to the browser cache to check whether there is a valid cached response that can be used to fulfill the request.Those APIs are supported in all browsers: It's the general name for a collection of web platform APIs. There isn't actually a single API called the HTTP Cache. This guide shows you the basics of an effective HTTP caching implementation. It's not necessarily the most powerful or flexible approach, and you have limited control over the lifetime of cached responses, but it's effective, it's supported in all browsers, and it doesn't require much work. How can you avoid unnecessary network requests? The browser's HTTP Cache is your first line of defense. If a person is accessing your site with a limited mobile data plan, every unnecessary network request is a waste of their money.Your page won't load until all of its critical resources have downloaded completely.Large responses require many roundtrips between the browser and the server.Server revalidation for unversioned URLsįetching resources over the network is both slow and expensive:.Which response header values should you use?.Response headers: configure your web server.Request headers: stick with the defaults (usually).
0 kommentar(er)
