Sharding 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, example.com and www.example.com are "tied" together via MapRewriteDomain. The origin-mapping to localhost propagates automatically to www.example.com, static1.example.com, and static2.example.com. So when PageSpeed cache-extends an HTML stylesheet reference http://www.example.com/styles.css, it will be:

1. Fetched by the server rewriting the HTML from localhost
2. Rewritten to http://example.com/styles.css.pagespeed.ce.HASH.css
3. Sharded to http://static1.example.com/styles.css.pagespeed.ce.HASH.css