Manuel Alvarez

Low offload? Check your basics!

Blog Post created by Manuel Alvarez Employee on Aug 12, 2015

I have worked with many customers facing poor or sub-optimal offload. These are few checks you can perform to make sure you are fully leveraging the Akamai Platform and increase your offload:

  1. TTL time too short: The first step is making sure Akamai is caching static content for as long as possible. A common sign of short TTLs rules are large numbers of 304 responses from the origin (check the Responses report on the Luna Control Center). This indicates that Akamai is requesting a lot of content that has not changed.
    1. Recommendations on TTLs and caching practices are discussed in Pierre Lermant blog a practical guide to web resource caching
    2. You can leverage {OPEN} APIs to invalidate content when new one is published
  2. Downstream cache too short:  Offload requests to your origin by telling clients not to ask for the object again (for a certain time). Check that Cache-Control and Expire headers are present on client responses and their cache directive is not too short. Remember you can set downstream cache rules at Akamai
    1. You can check the Last-Modified of your static content against the Cache-Control max-age to check if the object can be cached for longer; e.g. if the max-age is 300s and the last modified is more than a year ago
    2. Another sign is large numbers of 304s from clients to Akamai.

TIP for #1 and #2  Use versioning when possible. That allows you to confidently cache objects for months or even a year because new content will have a different name.E.g., did you notice the jQuery version is part of the URL on Google Hosted Libraries?

  1. Response does not contains the Last-Modified header: Akamai will perform IMS (If-Modified-Since) requests when the object cache expires. That causes the origin to responds with a 304 not modified rather than a full object. For IMS to work, the object response from origin must contain the Last-Modified header
    1. Check also that your origin responds to IMS requests with a 304
  2. Vary response header is present: The Vary header instructs Akamai Servers that content may differ based on some characteristic and hence, Akamai will not cache content if the Origin Server response includes a Vary header. The exception is Vary: Accept-Encoding together with a Content-Encoding: gzip
    1. The steps on how to fix this are documented in this Luna KB article
    2. If you need the Vary header sent to clients for cacheable content, do so at the Akamai level rather than the origin
  3. Unnecessary Query Strings in the Cache Key: The cache key is the unique identifier of the content in the Akamai cache. It is common that this cache key includes all the query strings, but do you really need them all? Include only those query strings that makes the content unique. e.g. do not include parameters such as currentTime or promotion on
  4. Not matching ETags:  Entity Tags are not validated by default by Akamai. If you enable ETag validation, make sure all the servers in your datacenters respond with the same ETag value. I’ve seen many cases where one server is responding with the wrong ETag value, causing cache to be evicted and unnecessary requests to the origin
  5. Cache-Control: no-store on the response: That will evict browser cache. Additionally, if you enabled the Honor Cache Control feature, this will also evict Akamai cache
  6. Tiered Distribution is OFF: Tiered Distribution is a great offload feature and you should use it for cacheable content
    1. In certain cases midgress traffic (traffic within Akamai as requests to TD servers) could be billed. Talk with your account team to understand the implications on your case before enabling it
  7. Object set to no store in the configuration: Make sure the object was indeed marked as cacheable. For example, many customer miss the font file extensions in their TTL rules
    1. You might develop complex rules resulting in content marked as uncacheable. Review your configuration for corner cases and ask for support from Akamai if needed.
  8. Purging too Often: Are you purging too many URLs, purging by CP Code, or simply doing it too often? This can bring your offload down. Try invalidating rather than purging or use a short TTL as an alternative to purge
  9. Cache your Pages: YES! You can cache pages and increase offload. Even a short TTL will make the difference (see Akshay Ranganath’s blog Measuring Impact of Page Caching blog). With Dynamic Page Caching you can conditionally or dynamically cache pages
    1. Conditionally refers to cache the page IF certain condition is not met; e.g. cache the home page IF the login cookie is not present or cache the shopping cart IF the cart is empty
    2. Dynamic refers to add elements to the cache key to account for possible permutations; e.g. add the language cookie to the cache key or add the is_tablet and is_mobile device characteristics to the cache key

If your performance is not where you would like it to be after performing these checks, please reach out to your account team to discuss options. We will be glad to assess your site.

Note: I did not talk about what is a good offload number because that has already being covered in a previous post


Special thanks to Akshay Ranganath, Pierre Lermant, and Mark Adam for reviewing the draft