Authorizing and Mapping Urls and Domains
Best practices suggest minimizing round-trip times by parallelizing downloads across hostnames. PageSpeed can partially automate this for resources that it rewrites, using the directive:
pagespeed ShardDomain domain_to_shard shard1,shard2,shard3...
Wildcards cannot be used in this directive.
This will distribute the domains for rewritten URLs among the specified shards. The shard selected for a particular URL is computed from the original URL.
pagespeed ShardDomain example.com static1.example.com,static2.example.com
Using this directive, PageSpeed will distribute roughly half the resources rewritten from example.com into
static1.example.com, and the rest to
static2.example.com. You can specify as many shards as you like. The optimum number of shards is a topic of active research, and is browser-dependent. Configuring between 2 and 4 shards should yield good results. Changing the number of shards will cause PageSpeed to choose different names for resources, resulting in a partial cache flush.
When used in combination with
RewriteDomain, the Rewrite mappings will be done first. Then the shard selection occurs. Origin domains are always tracked so that when a browser sends a sharded URL back to the server, PageSpeed can find it.
Let's look at an example:
pagespeed ShardDomain example.com static1.example.com,static2.example.com pagespeed MapRewriteDomain example.com www.example.com pagespeed MapOriginDomain localhost example.com
In this example,
www.example.com are "tied" together via
MapRewriteDomain. The origin-mapping to
localhost propagates automatically to
static2.example.com. So when PageSpeed cache-extends an HTML stylesheet reference
http://www.example.com/styles.css, it will be:
- Fetched by the server rewriting the HTML from
- Rewritten to
- Sharded to