Simple solution for a static-ressources domain

A well understood pattern of increasing frontend performance of a web application is to deliver static ressources from a different domain. Preferably free of any cookies to save additional bandwidth, the browser can download more of these files in parallel. (This mechanism is often refered to as “cookieless domain”.)

Sometimes the adjustments in the application required to achieve this are complicated and have a deep impact on the codebase.

Much handier is a solution that is transparent to the application. This solution needs to

  • manipulate the ressource paths of the applications response
  • redirect the requests to the static-domain back to the original application

As of Apache 2.2.7, the module mod_substitute is available. Mod_substitutes job description is to “Perform search and replace operations on response bodies”. Apaches Mod_rewrite is available for a very long time now, and “Provides a rule-based rewriting engine to rewrite requested URLs on the fly”.

If these two modules are combined, it’s possible to do the required tasks within Apache. In this example, two virtual hosts are used (app.localhost and static.localhost). All items in the /static/ folder are downloaded from the static domain.

Adjust the response to use the static domain for all elements in /static instead of the original applications domain.

1
2
3
4
5
6
<VirtualHost app.localhost>
  DocumentRoot "your_docroot"
  ServerName app.localhost
  AddOutputFilterByType SUBSTITUTE text/html
  Substitute "s|/static/|http://static.localhost/static/|nq"
</VirtualHost>

Rewrite the requests to the static domain back to the regular domain:

1
2
3
4
5
<VirtualHost static.localhost>
  ServerName static.localhost
  RewriteEngine On
  RewriteRule ^http://static\.localhost/ http://app.localhost/ [L]
</VirtualHost>

To test these settings with your application, it’s possible to combine them with the reverse proxy of mod_proxy and directly access your application from a local installation of Apache httpd without touching anything of your configuration. Happy benchmarking!

Downside

  • Every response needs to be changed, which is a waste of ressources compared to an application where an image domain is automatically set in the response.
  • SSL may take more effort to handle MITM situations
  • Expressions to transform static paths are more complicated in real life. Think of absolute and relative paths, unorganised folder structures and items referenced in css and js code.
  • mod_substitute may cause some headaches, as it doesn’t always work as expected from a regular expression.
Share