Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Http Caching for the Android Aficionado
Semelhante a Http Caching for the Android Aficionado (20)
Mais de Paul Blundell
Mais de Paul Blundell (16)
Último
Último (7)
Http Caching for the Android Aficionado
- 1. Http caching for the Android aficionado Paul Blundell
- 2. image
- 3. image
- 4. image
- 5. Api Response Server emits headers describing caching directives
- 6. etags
- 7. ETags are Validation Tokens
- 8. Local cache has previous responses
- 9. ETags
- 10. A request when you have an ETag
- 11. A request when you have an ETag
- 12. image
- 13. cache-control
- 14. image
- 15. Cache Control
- 16. Deprecation Cache-Control header defined in HTTP/1.1 spec supersedes Expires header Ref: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
- 17. Cache Control Possibilities no-cache the returned response cannot be used to satisfy a subsequent request to the same URL without first checking with the server if the response has changed. if ETag is present, no-cache will incur a roundtrip to validate the cached response, but can eliminate the download if the resource has not changed. no-store disallows the browser and all intermediate caches to store any version of the returned response - e.g. one containing private personal or banking data ETags would be ignored
- 18. Cache Control Possibilities public can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn’t normally cacheable Most of the time, “public” isn’t necessary, because explicit caching information (like “max-age”) indicates that the response is cacheable anyway private can be cached by the browser but are typically intended for a single user and hence are not allowed to be cached by any intermediate cache e.g. an HTML page with private user information can be cached by that user’s browser, but not by a CDN
- 19. Cache Control Possibilities max-age the maximum time in seconds that the fetched response is allowed to be reused for from the time of the request e.g. “max-age=60” indicates that the response can be cached and reused for the next 60 seconds.
- 20. Cache-Control examples cache-control=”max-age=86400” Response can be cached by browser and any intermediary caches (i.e. it is "public") For up to 1 day (60 seconds x 60 minutes x 24 hours) cache-control=”private, max-age=600” Response can be cached by the client’s browser only For up to 10 minutes (60 seconds x 10 minutes) cache-control=”no-store” Response is not allowed to be cached Must be fetched in full on every request
- 21. Decision Tree
- 22. Checklist Use consistent URLs Ensure the server provides a validation token Identify which resources can be cached by intermediaries: Determine the optimal cache lifetime for each resource Determine the best cache hierarchy for your site Minimize churn
- 23. Enable OkHttp Http Cache int cacheSize = 10 * 1024 * 1024; // 10 Mb File cacheDirectory = new File(context.getCacheDir().getAbsolutePath(), "HttpCache"); Cache cache = new Cache(cacheDirectory, cacheSize); new OkHttpClient.Builder() .cache(cache) .build(); Old but interesting link of Retrofit caching example: https://gist.github.com/swankjesse/5889518
- 24. Enable WebView Http Cache webView.getSettings().setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK); LOAD_DEFAULT LOAD_NO_CACHE LOAD_CACHE_ONLY ____ webView.getSettings().setAppCacheEnabled(true); webView.getSettings().setAppCachePath(context.getCacheDir()); webView.getSettings().setAppCacheMaxSize(10 * 1024*1024); This method was deprecated in API level 18. In future quota will be managed automatically. References: https://github.com/novoda/notils/blob/master/android/src/main/java/com/novoda/notils/widget/webview/ExternalUrlWebViewActivity.java http://www.html5rocks.com/en/tutorials/appcache/beginner/
- 25. Further Reading Invalidating cache responses with cache hierarchies - What if you want to force a change - Not having to update the app if the api endpoint changes - https://danpalmer.me/blog/your-api-is-not- restful - https://github.com/kevinswiber/siren - https://github.com/mikekelly/hal_specification
- 27. throw new SlideIndexOutOfBoundsException(); blundell_apps G what? blundell Questions?
Notas do Editor
- Fetching something over the network is both slow and expensive: large responses require many roundtrips between the client and server, which delays when they are available and can be processed by the browser, and also incurs data costs for the visitor.
- As a result, the ability to cache and reuse previously fetched resources is a critical aspect of optimizing for performance.
- Let’s talk about a typical exchange between server and client
- When the server returns a response it also emits a collection of HTTP headers, describing its content-type, length, caching directives, validation token, and more. For example, in the above exchange the server returns a 1024 byte response, instructs the client to cache it for up to 120 seconds, and provides a validation token (“x234dff”) that can be used after the response has expired to check if the resource has been modified.
- ETag HTTP header is a validation token Validation token enables efficient resource update checks: no data transfer if the resource has not changed. Etag is an arbitrary token generated by the server which is typically a hash or some other fingerprint of the contents of the file
- Let’s assume 120 seconds have passed since our initial fetch and the browser has initiated a new request for the same resource. First, the HttpClient checks the local cache and finds the previous response, unfortunately it cannot use it as the response has now “expired”. At this point it could simply dispatch a new request and fetch the new full response, but that’s inefficient because if the resource has not changed then there is no reason to download the exact same bytes that are already in cache!
- That’s the problem that validation tokens, as specified in the ETag header, are designed to solve: the server generates and returns an arbitrary token which is typically a hash or some other fingerprint of the contents of the file. The client does not need to know how the fingerprint is generated only needs to send it to the server on the next request: if the fingerprint is still the same then the resource has not changed and we can skip the download.
- HttpClient automatically provides the ETag token within the “If-None-Match” HTTP request header the server checks the token against the current resource
- if it has not changed returns a “304 Not Modified” response which tells the browser that the response it has in cache has not changed and can be renewed for another 120 seconds. Note that we do not have to download the response once more - this saves time and bandwidth.
- The best request is a request that does not need to communicate with the server: a local copy of the response allows us to eliminate all network latency and avoid data charges for the data transfer. You can think of it as getting a bottle of water from your local corner shop, or going to the moon to melt some ice
- Each resource can define its caching policy via Cache-Control HTTP header Cache-Control directives control who can cache the response (httpclient / intermediate caches) under which conditions for how long
- Cache-Control header was defined as part of the HTTP/1.1 specification supersedes previous headers (e.g. Expires) used to define response caching policies. All modern browsers support Cache-Control, hence that is all we will need.
- “no-cache” the returned response cannot be used to satisfy a subsequent request to the same URL without first checking with the server if the response has changed If ETag is present no-cache will incur a roundtrip to validate the cached response, but can eliminate the download if the resource has not changed. “no-store” disallows the browser and all intermediate caches to store any version of the returned response e.g. one containing private personal or banking data. Everytime the user requests this asset, a request is sent to the server and a full response is downloaded each and every time.
- “public” vs. “private” If the response is marked as “public” then it can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn’t normally cacheable. Most of the time, “public” isn’t necessary, because explicit caching information (like “max-age”) indicates that the response is cacheable anyway. By contrast, “private” responses can be cached by the browser but are typically intended for a single user and hence are not allowed to be cached by any intermediate cache - e.g. an HTML page with private user information can be cached by that user’s browser, but not by a CDN.
- “max-age” This directive specifies the maximum time in seconds that the fetched response is allowed to be reused for from the time of the request - e.g. “max-age=60” indicates that the response can be cached and reused for the next 60 seconds.
- max-age=86400 = Response can be cached by browser and any intermediary caches (i.e. it is "public") for up to 1 day (60 seconds x 60 minutes x 24 hours) private, max-age=600 = Response can be cached by the client’s browser only for up to 10 minutes (60 seconds x 10 minutes) No-store = Response is not allowed to be cached and must be fetched in full on every request.
- Determine the optimal caching policy for a particular resource, or a set of resources used by your application. You should aim to cache as many responses as possible on the client for the longest possible period, and provide validation tokens for each response to enable efficient revalidation. Some apps can cache 90%+ of their resources, while others may have a lot of private or time-sensitive data that can’t be cached at all. Audit your pages to identify which resources can be cached and ensure that they are returning appropriate Cache-Control and ETag headers.
- There is no one best cache policy. Depending on your traffic patterns, type of data served, and application-specific requirements for data freshness, you will have to define and configure the appropriate per-resource settings, as well as the overall “caching hierarchy”. Use consistent URLs: if you serve the same content on different URLs, then that content will be fetched and stored multiple times. Tip: note that URLs are case sensitive! Ensure the server provides a validation token (ETag): validation tokens eliminate the need to transfer the same bytes when a resource has not changed on the server. Identify which resources can be cached by intermediaries: those with responses that are identical for all users are great candidates to be cached by a CDN and other intermediaries. Determine the optimal cache lifetime for each resource: different resources may have different freshness requirements. Audit and determine the appropriate max-age for each one. Determine the best cache hierarchy for your site: the combination of resource URLs with content fingerprints, and short or no-cache lifetimes for HTML documents allows you to control how quickly updates are picked up by the client. Minimize churn: some resources are updated more frequently than others. If there is a particular part of resource (e.g. JavaScript function, or set of CSS styles) that are often updated, consider delivering that code as a separate file. Doing so allows the remainder of the content (e.g. library code that does not change very often), to be fetched from cache and minimizes the amount of downloaded content whenever an update is fetched.
- OkHttp ships with an implementation of an HTTP cache! All we have to do is turn it on and ensure that each server response provides correct HTTP header directives to instruct the browser on when and for how long the response can be cached by the browser.