Skip to content
Go to file
Cannot retrieve contributors at this time
119 lines (72 sloc) 7.31 KB

AMP Cache Guidelines


Provide guidelines to external parties for implementing their own AMP Caches.


In the AMP ecosystem, the platform that links to content may freely choose which AMP Cache (if any) to use. It is an inversion of the typical model where content delivery is the responsibility of the publisher.

This allows platforms to provide their users with predictable load performance and among other things allows them to ensure required security and privacy invariants during AMP’s pre-rendering phase.

AMP is an open ecosystem and actively encourages the development of more AMP Caches.

Guidelines: Core

  1. An AMP Cache only serves valid AMP input documents.

  2. It participates in the AMP validator release cycle.

  3. It participates in the AMP JS library release cycle and makes every effort to serve the latest version. It does not allow sites to perform version locking.

  4. It serves each site from a subdomain of the cache domain.

    1. See for example: the Google AMP Cache URL format.
  5. Pledges to maintain URL space forever (even beyond the lifetime of the cache itself):

    1. This can be achieved by donating the URL space to a trustworthy third party entity such as

    2. This means that, should a cache decide to no longer operate, URLs should redirect to the origin URL or be served by another cache.

  6. Uses HTTPS serving only.

  7. Serves a strong Content Security Policy (CSP) - a CSP defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.

    1. Implements separately documented security rewrites on served content.

    2. The CSP should be equivalent or stronger to what is being served on

    3. Caches must update their CSP in a timely fashion (within 7 days) at the request of the AMP.

  8. Supports a public Update Cache mechanism for document publishers to notify the AMP cache about new, updated or deleted documents:

    1. Equivalent to the Google AMP Update Cache API
  9. Supports a public AMP Cache URL API:

    1. Equivalent to the Google AMP Cache URL API
  10. Provides a faithful visual and UX reproduction of source document. E.g. changes in image resolution or compression rate may be acceptable if they provide strong benefits in terms of bandwidth usage and load time.

  11. No obstruction of the contents, branding or attribution of the original AMP document.

  12. No changes to ads, monetization, access (paywall monetization and similar), analytics, or similar.

  13. Respects all resource deletions within a reasonable timeframe.

  14. Uses a stale-while-revalidate caching model and reasonable min cache time (such as in the order of single digit minutes) is allowed. For example, as per Google AMP Cache updates, "[the cache] uses the origin's caching headers, such as Max-Age, as hints in deciding whether a particular document or resource is stale. When a user makes a request for something that is stale, that request causes a new copy to be fetched, so that the next user gets fresh content":

    1. The cache is allowed to serve stale content independent of HTTP caching headers. It must make reasonable efforts to keep the cache contents fresh and must revalidate content after serving stale responses.
  15. Follows AMP cache modifications best practices.

Guidelines: Crawling

Guidelines: Optional Extensions

Guidelines: Accepted MIME types

MIME types for images

Accepted MIME types for images include all image/ subtypes (e.g. image/gif).

MIME types for fonts

Accepted MIME types for fonts include the following prefixes:

Media type / subtype
font/ (e.g. font/opentype)
text/plain (not recommended)

Guidelines: Resource size limits

For resources (i.e., HTML, images, fonts) that are larger than 12 MB, you may not fetch the resource, and you may return a 404 error.

Guidelines: Adding a new cache to the AMP ecosystem


You can’t perform that action at this time.