The Google AMP Cache serves cached copies of valid AMP content published to the web. Serve content directly from the Google AMP Cache to provide a fast user experience.
To take advantage of the Google AMP Cache, an AMP URL must be accessed directly from the cache using the AMP Cache URL format. Each time a user accesses AMP content from the cache, the content is automatically updated, and the updated version is served to the next user once the content has been cached.
AMP Cache URL format
The AMP Cache URL format consists of the following components:
| Component | Description |
|---|---|
| Subdomain name | Subdomains created by the Google AMP Cache will be human-readable when character limits and technical specs allow, and will closely resemble the publisher's own domain. When possible, the Google AMP Cache will create each subdomain by:
For example, |
| Content type | The content type is one of the following: 'c' for an AMP HTML document, 'i' for an image, or 'r' for a resource such as a font. The Google AMP Cache returns a 404 error for resources that do not match these content types (see the core error). |
| Optional 's' | If present, requires that Google fetch the content from the origin using TLS (secure HTTPS). If the 's' is not present, then content gets fetched from the origin using plain HTTP. |
| URI | URI of the content to be fetched. The URI cannot contain a scheme; that is, no `http://` or `https://`. |
Finding the subdomain name
Typically, the subdomain name for a Google AMP Cache URL will be a human-readable conversion of the original URL using the steps outlined above. However, because there are circumstances where this may not be true, the best way to retrieve Google AMP Cache URLs for production-ready applications is to use the Google AMP Cache URL API.
For non-production situations, to determine what subdomain name the Google AMP Cache generates, try out the Using the Google AMP Cache interactive tool on amp.dev.
Example requesting document using TLS
Request for an AMP HTML document (specified with the /c prefix)
fetched from https://example.com/amp_document.html:
https://example-com.cdn.ampproject.org/c/s/example.com/amp_document.html
Because /s follows the /c prefix,
the document will be fetched from example.com using TLS.
Example requesting image using plain HTTP
Request for an image (specified with the /i prefix)
fetched from http://example.com/logo.png:
https://example-com.cdn.ampproject.org/i/example.com/logo.png
Because there's no /s following the /i prefix,
Google fetches the image from example.com using plain HTTP,
not HTTP over TLS.
Query parameter example
The AMP Cache URL format can also include parameters in the query string.
The following is an HTTPS example with parameters:
https://example-com.cdn.ampproject.org/c/s/example.com/g?value=Hello%20World
Google AMP Cache updates
When a user requests an AMP document from the Google AMP Cache, the cache automatically requests updates in order to be able to serve fresh content for the next user once the content has been cached. With this model, updates to AMP documents propagate automatically and quickly; few users will see the non-updated version after your update.
The cache follows a "stale-while-revalidate" model.
It 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.
To limit the amount of load it generates for publisher sites, the Google AMP Cache considers any document fresh for at least 15 seconds, and any resource fresh for at least 1 minute. Note that those numbers may change in the future, as we tune the cache for optimum balance between freshness and load on publisher sites.
Cache optimizations and modifications
The Google AMP Cache performs optimizations and modifications, such as the following:
- Validates content is truly in AMP format, meeting all AMP performance goals.
- Caches images and fonts in addition to AMP documents.
- Limits maximum image dimensions to prevent browser memory issues and poor responsiveness.
- Various transformations to improve the delivery efficiency of images
via the
amp-imgtag, such as:- Removal of data that is invisible or difficult to see, such as certain metadata.
- Conversion of images to smaller and mobile-friendlier image formats, such as converting GIF, PNG, and JPEG format images to WebP in browsers that support WebP.
- Transformation of the image to a lower quality if the request includes the Save-Data header.
- Generation of alternatively sized versions and adding
srcsetattributes to support delivery of responsively sized images.
- Serves over a secure channel (HTTPS) and uses the latest web protocols (SPDY, HTTP/2).
- Sanitizes AMP documents to prevent XSS attacks based on incorrectly closed HTML tags, comments, and more.
In making the above transformations, the Google AMP Cache disregards the “Cache-Control: no-transform” header.
HTML sanitization
The Google AMP Cache rewrites all documents to normalize parsing. Examples include:
- All HTML comments are stripped.
- Tag and attribute names are lowercased.
- Attribute values are consistently quoted and escaped.
- All tags are closed, except for HTML5 void elements.
- Whitespace inside tags is stripped.
- Text is escaped.
- Encoded text characters are simplified, using UTF-8 equivalent characters.
- Elements that can only be in the
bodyget moved into thebody. - Outbound links are made absolute so that they continue to work when the document is served from the Google AMP Cache origin instead of the publisher origin.
Insert prefetch tags
The Google AMP Cache adds various prefetch hint tags for browsers
to assist in loading resources earlier.
For example,
<link href='https://fonts.googleapis.com/css?family=Lato' rel='stylesheet’>
changes to:
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet"> <link href="https://fonts.gstatic.com" rel="dns-prefetch preconnect">