Rewriting references to static CSS, JS, and image content

> Tuesday, January 26, 2010 |

For static content such as CSS, JavaScript, and image files, it is best practice to serve these items from a separate domain from the main content. Even if this secondary domain points to the same web farm initially, it opens up the possibility of serving the content from other servers at a later date.

Other benefits:

  1. Static content domain can be cookie-free.
  2. Cache settings can be adjusted specifically for the static content, based on host headers.
  3. Dedicated hardware could be set up to serve the static content.

In dev and QA environments, of course, it may not be possible to point to an external production domain. The CSS/JS/etc files may need to point to local content during dev/QA. Consequently, any solution should take into account configuration differences across environments.

A couple solutions to consider:

  1. Instrument IMG and SCRIPT links with a method call that substitutes the domain.
    Drawback: <%= %> block in ASPX page means that it cannot be declared CompileMode="never", which is needed for CMS-generated pages.
    Will a <%$ %> block work?
  2. Create an HttpModule to comb through the page output and substitute the domain in the proper locations.
  3. Implement an .ascx control to output SCRIPT and CSS references.
    Drawback: Will not address the issue of inline IMG tags.
  4. Use a dynamic #include file with some logic embedded.
    Drawback: Same as #3. Also, CMS user could possibly mangle code directives in #include. Finally, it is questionable if this will even work reliably with ASPX.
More to come...