![]() Here we could cache the root page using pattern 3, and the rest of the resources using pattern 2. const version = '2' self.addEventListener('install', event => ) The service worker & the HTTP cache goes hand in hand until we screw it up. This is because must-revalidate will revalidate the resource only after max-age expires. This pattern appears as good one at first but the trap is you cannot burst the cache before 10 minutes. Strategy 4: Mutable resources with max-age Cache-Control: must-revalidate, max-age=600 So Pattern 2 is quite better than this one. This pattern always involves a network call when compared to Pattern 2. Otherwise the server sends the full content. Next time the client fetches the resource, it echoes the value for the content it already has via If-None-Match and If-Modified-Since respectively, allowing the server to send "HTTP 304". Here you can add an ETag or Last-Modified date header to the response. In this pattern, browser doesn’t believe the local resource state and always validates with server to check its freshness. Strategy 3 : Mutable resources with always server-revalidated Cache-Control: no-cache This is commonly called as cache-busting. Developers will be using gulp, grunt task runners for revisioning the static resources for each release. The previous resource will be removed by the browser automatically when it expires. If the URL changes then it denotes a different resource. ![]() It could be a version number, the modified date, or a hash of the content or anything that differentiate them with the others. Įach URL contains something that changes along with its content. Cached content younger than max-age seconds can be used without consulting the server. The content at this URL never changes then the browser/caching servers can cache this resource for a 365 days without a problem. Strategy 2 : Immutable resources with a very long max-age Cache-Control: max-age=31536000 This directive is relative to the time of the request whereas Expires, specifies the expiration in GMT. Max-age Specifies the maximum amount of time a resource will be considered fresh. Must-revalidate doesn't mean "must revalidate", it means the local resource can be used if it's younger than the provided max-age, otherwise it must revalidate. No-cache doesn’t mean “don’t cache”, it means it must revalidate with the server before using the cached resource. No-store means do not store particular resource from the server anywhere (i.e browser or proxy caching ). This instructs the browser or an intermediate caching server not to store any static files. Cache-Control: no-cache, no-store, must-revalidate To turn off caching, send the following response header. Strategy 1 : Very Less Caching or No Caching Most of patterns found on the internet falls into one of the following. We will be dealing mostly with the above ones and I will be explaining these as we get deeper into patterns. The Pragma HTTP/1.0 general header is used for backwards compatibility with HTTP/1.0 caches where the Cache-Control HTTP/1.1 header is not yet present. I will only list most commonly used directives. The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. I am a freelance JavaScript Developer and I’ll be sharing few best practices based on my experience. Bitter truth is that most of the developers are giving very less importance to caching which results in race conditions resulting in interdependent resources getting out of sync. HTTP caching is a powerful method which yields huge performance benefits, saves bandwidth, reduces server traffic, etc. “A macro shot of a Macbook Pro screen with a few dozen lines of code” by Luca Bravo on Unsplash
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |