Sharding domains

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,

Using this directive, PageSpeed will distribute roughly half the resources rewritten from into, and the rest to 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, pagespeed MapRewriteDomain pagespeed MapOriginDomain localhost

In this example, and are "tied" together via MapRewriteDomain. The origin-mapping to localhost propagates automatically to,, and So when PageSpeed cache-extends an HTML stylesheet reference, it will be:

  1. Fetched by the server rewriting the HTML from localhost
  2. Rewritten to
  3. Sharded to