Mapping rewrite domains

Rewrite domains

When PageSpeed rewrites a resource, it updates the HTML to refer to the resource by its new name. Generally PageSpeed leaves the resource at the same origin and path that was originally found in the HTML. However, it is possible to map the domain of rewritten resources.

Examples of why this might be desirable include:

• Cookieless domains Serving static content from cookieless domains, to reduce the size of HTTP requests from the browser.
• CDN To move content to a Content Delivery Network

This is done using the configuration file directive:

pagespeed MapRewriteDomain domain_to_write_into_html domain_specified_in_html

Wildcards can also be used in the domain_specified_in_html:

pagespeed MapRewriteDomain domain.com *.example.com

The domain_to_write_into_html can include a path after the domain name:

pagespeed MapRewriteDomain domain.com/example www.example.com

When a path is specified, the source domain is rewritten to the destination domain and the source path is rewritten to the concatenation of the path from domain_to_write_into_html and the source path. For example, given the above mapping, http://www.example.com/index.html will be rewritten to http://domain.com/example/index.html.

Note: It is the responsibility of the site administrator to ensure that PageSpeed is installed on the domain_to_write_into_html. This might be a separate server, or there may be a single server with multiple domains mapped into it. The files must be accessible via the same path on the destination server as was specified in the HTML file. No other files should be stored on the domain_to_write_into_html -- it should be functionally equivalent to domain_specified_in_html. See also MapProxyDomain which enables proxying content from a different server.
For example, if PageSpeed cache_extends http://www.example.com/styles/style.css to http://cdn.example.com/styles/style.css.pagespeed.ce.HASH.css, then cdn.example.com will have to have a mechanism in place to either rewrite that file in place, or refer back to the origin server to pull the rewritten content.

Note: It is the responsibility of the site administrator to ensure that moving resources onto domains does not create a security vulnerability. In particular, if the target domain has cookies, then any JavaScript loaded from a resource moved to a domain with cookies will gain access to those cookies. In general, moving resources to a cookieless domain is a great way to improve security. Be aware that CSS can load JavaScript in certain environments.

By specifying a domain in this directive, either as source or destination, you are authorizing PageSpeed to rewrite resources found in this domain. See Domain.

These directives can be used in location-specific configuration sections.

CDN + Google Page Speed Optimization

Enable rewriting of all css, js, and images and route them via the CDN:

pagespeed MapRewriteDomain cdn.example.com www.example.com

The CDN will forward all requests that it does not have in cache to the origin server.

Common problems when using a CDN are twofold:

• First, the CDN will only cache assets that broadcast that they are cacheable in the first place.
• Second, when the CDN has cached something, a manual purge has to be done to be able to propagate updates to the website. These purges are often limited to a fixed amount per period, and no guarantees are given to the speed at which they are processed.

This is where Page Speed comes to the rescue. The cache extending filter will embed a fingerprint of the content into the url, and serve the asset with a one year expiry.
So now, the CDN will keep the asset in cache for a year. If Page Speed detects a content changed, a completely new url will be generated - which makes content updates immediately visible to all end-users.

Multiple domains using a single CDN

Consider a scenario where an installation serving multiple domains uses a single CDN for caching and delivery of all content. The origin fetches need to be routed to the correct VirtualHost on the server. This can be achieved by using a subdirectory per domain in the CDN, and then using that subdirectory to map to the correct VirtualHost at origin. The host-header control offered by the third argument to MapOriginDomain makes this feasible.

In the example below, resources with a domain of origin.example.com and path starting with /domain1 will be fetched from localhost but with a Host: header value of www.domain1.com. Without the third argument to MapOriginDomain, the Host: header would be origin.example.com.

pagespeed MapRewriteDomain cdn.example.com/domain1 www.domain1.com pagespeed MapRewriteDomain cdn.example.com/domain2 www.domain2.com pagespeed MapOriginDomain localhost origin.example.com/domain1 www.domain1.com pagespeed MapOriginDomain localhost origin.example.com/domain2 www.domain2.com

This would be used in conjunction with a VirtualHost setup for www.domain1.com, and a single CDN setup for multple hosts segregated by subdirectory.