Proxying and optimizing resources from trusted domains
Authorizing and Mapping Urls and Domains
Proxying resources is desirable under several scenarios:
- The resources on the origin domain may benefit from optimizations done by PageSpeed.
- SPDY may work better if there are fewer domains on a page.
- The target domain running PageSpeed may have better serving infrastructure than the origin.
It is possible to proxy and optimize resources whose origin is a trusted domain that may not be running PageSpeed. This cannot be directly achieved with MapRewriteDomain because that is a declaration that the domains listed are functionally equivalent to one another, either because they are backed by the same storage, or because the target is acting as a proxy (e.g. a CDN).
MapProxyDomain makes it technically possible to proxy and optimize resources from any domain that you trust.
You must only proxy resources that are controlled by an organization you trust because it is possible for malicious content (e.g. GIFAR) proxied from an untrustworthy domain to gain access to private content on your domain, compromising your site or its viewers. You must never map directories that may contain files that may be controlled by a third party.
There may be legal issues restricting the optimization of resources you don't own. If in doubt consult a lawyer.
pagespeed MapProxyDomain target_domain/subdir origin_domain/subdir [rewrite_domain/subdir]
pagespeed MapProxyDomain http://www.mydomain.com/twitjs/ http://platform.twitter.com/
If the optional rewrite_domain/subdir argument is supplied then optimized resources will be rewritten to that location. This is useful for rewriting optimized resources proxied from an external origin to a CDN.
It is important to specify a subdirectory in the target domain, because PageSpeed will need to be able to unambiguously identify the origin domain given the target when fetching content. Thus each MapProxyDomain command should be given a distinct subdirectory of the target domain.
It is important to specify a subdirectory in the origin domain to limit the scope of the proxying.
Examples for pulling in Google Analytics, facebook, twitter, and disqus.
# Examples for pulling in Google Analytics, facebook, twitter, and disqus pagespeed MapProxyDomain http://www.mydomain.com/twitjs/ http://platform.twitter.com/ pagespeed MapProxyDomain http://www.mydomain.com/fbjs/ http://connect.facebook.net/ pagespeed MapProxyDomain http://www.mydomain.com/gajs/ http://www.google-analytics.com/ pagespeed MapProxyDomain http://www.mydomain.com/disq/ http://a.disquscdn.com/
Https is a little more involved, we don't think this is the preferred approach but the configuration that should be working seems to fail. This is what we use at PagespeedGuide.com for Google Analytics:
# pagespeed MapProxyDomain https://www.pagespeedguide.com/PageSpeed/JS/GoogleAnalytics/ https://www.google-analytics.com/ pagespeed MapOriginDomain http://www.google-analytics.com/ https://www.google-analytics.com/ pagespeed MapRewriteDomain https://www.pagespeedguide.com/PageSpeed/JS/GoogleAnalytics/ https://www.google-analytics.com/ pagespeed MapProxyDomain http://www.pagespeedguide.com/PageSpeed/JS/GoogleAnalytics/ http://www.google-analytics.com/ https://www.pagespeedguide.com/PageSpeed/JS/GoogleAnalytics/Wether doing so actually improves performance should be measured, as the CDN's used for serving those external assets might outperform the hosting of your website - next to that for some scripts there's a big chance that visitors will already have those in the browser cache.