The first part of this series reminded our reader on the best practices for caching and emphasized the need to isolate personal data from any page view content.
In this second blog post, we will provide actual caching value recommendations for client browsers and edge servers. We categorize each resource by time sensitivity, list the main observed use cases for each of them, and propose TTL values for the client as well as for the edge server. When appropriate, we differentiate recommendations based on the edge invalidation policy.
Resource is not time sensitive, points to static content.
This is the best caching scenario. Always strive to make resources time-independent.
- Any versioned content: www.example.com/v13/js/main.js
Recommended TTLs: Edge and Client TTLs: 3 months
Resource has low time sensitivity ( Staleness > 1 hour)
- Search result listings
- User reviews
- Backward compatible resources, e.g. JS or CSS
- Search engine targeted pages
- Generic ads
- Edge TTL: 1 hour to 1 day if no invalidation, else 2x the refresh period, e.g. 2 days for content updated daily
- Client TTL: 2x median user session duration , or 15 min if unknown
Resource has medium time sensitivity (15 m. < Staleness < 1 h.).
- Social updates, user comments
- Category listings
- Flight and other schedules
- Weather forecasts
- Context sensitive ads
- Product prices or availability. (Upon purchase/reservation, non-cacheable requests to pricing/availability must be made to guarantee the transaction)
- Edge TTL: 15 min. to 1 hour if no invalidation, else 2x the refresh period, e.g. 2 hours for content updated hourly.
- Client TTL: 10 min. or less.
Resource has high time sensitivity (Staleness < 15 mins.).
- Breaking news
- Finance tickers
- Sports scores
- Edge TTL: 30 sec. to 15 min. Invalidation is discouraged
- Client TTL: 0. Validation with edge server must be performed for each request
Resource has personal information.
- Origin system generated: recommendations, messages
- User generated, e.g. personal settings, shopping cart
- Edge: Do not cache
- Client TTL: If origin generated: 2x median user session duration, else do not cache
Resource cannot be served stale, yet is cacheable
Non-personal, popular and time-critical large objects that change at unpredictable times
Recommended Edge and Client TTLs: 0. Resource can be cached, however validation with Edge (from client) and Origin server (from Edge) must be performed for each request
If you would like to understand how to best implement these recommendations or present a use case that is not covered here, please contact Akamai professional services.
Pierre Lermant is an Enterprise Architect at Akamai