tactile

– thoughts on CSS, UIs and UX.

Static assets served separately

Posted: December 2nd, 2012 Author:

I want to know: why do most web application servers (Django, Rails, etc) serve static assets?
It seems wasteful to me (in terms of web performance) that a tied-up application server has to deal with the extra burden of serving static assets.

It also seems silly for designers and front-end developers to have to configure, install and use an app environment to do work on mostly static elements such as the CSS and JS.

A typical experience

Recently I was tasked with building out some HTML, CSS and JS for a web application.
The app setup for my local environment was painful and fraught with complications – I had to ask one of the engineers to help me out.

Once I finally had the app running locally, I noticed that I was spending 5-10 seconds each time I saved a Sass file, waiting for the application to respond (during asset pre-compilation) before I could see my changes.

Move static assets onto their own server

It got me thinking that during dev-time, maybe it would be better to serve all static assets from say: Apache, and all app-related requests could be served by the application.

e.g.
GET http://app.dev/ – App server
GET http://static.app.dev/css/app.css – Apache
GET http://static.app.dev/js/app.js – Apache
etc.

Benefits

  • Designers and FEDs don’t necessarily have to setup the app on their local environments. It’s much easier to setup Apache than most app servers.
  • The app server won’t get tied up with serving static content.
  • It’ll help speed up development of static HTML, CSS and JS by reducing the latency for your changes.
  • When you’re nearing release time, you could start simulating HTTP caching and compression of static assets.
  • The static server could contain HTML templates for cross-browser testing, prototyping, styleguides etc.
  • The static server could be optimised for HTTP performance.
  • Deploys to the static server could potentially not impact the app server – basic styling and image changes wouldn’t need an app deployment.

Drawbacks

  • Engineers would have to configure Apache to run on a separate subdomain or act as a reverse proxy for certain requests.
  • Environment setup would involve configuring and installing Apache over and above the app setup.
  • Front-end developers would still need to install the app server once they start working with the application views.

Questions

  1. Could such a setup work during dev time?
  2. How would CSS pre-compilers (such as LESS or Sass) and concatenation/compression scripts be affected by this change?
  3. What other benefits and drawbacks are there to such a setup?

One Comment on “Static assets served separately”

  1. 1 Steve said at 3:53 pm on December 8th, 2012:

    Hi Shaun.

    Thought-provoking post. I might be a bit confused (quite likely), but I thought asset compilation, compression, etc. mostly only happens on production environments: dev envs should have wide / fat assets with no waiting.

    Having just moved to Rails projects, I’m comparing everything to that, of course. Older version of Rails (which I’m a little more familiar with) has a public folder where all our stuff (as Front End Developers) goes. Newer versions have asset pipeline, which I’m still learning about, and does more crunching.

    I like the idea of moving static stuff to a separate server, but I suspect it would be fiddly and a pain to do this plus regular server plus CDN stuff.

    Please note that all this is written on a Saturday and therefore may be all wrong.
    :)