When Best Practices Aren't Best

Post by Saul Shanabrook

If you hosting your Django site on Heroku, you most likely have had to
deal with static assets.

I have always thought that the Right was to use Amazon S3, through
django-storages. This means that any static requests do not impact performance on your
Heroku dyno. And that is how I have been doing it for the year or so,
but I have never liked it. Recently I had been having trouble getting
django-storages to recognize updated files on collecstatic, so I would
delete the whole S3 static folder and re-upload it every time. Which is
not only inefficient but also damaging to the end user, because it means
that for a few minutes no static files exist and the page won’t load
correctly.

Even if this bug was addressed, I still had to deal with the headache of
possibly out of sync static. I didn’t want to run collectstatic on every
heroku push, simply because it took so long

So I finally came upon
whitenoise, which seems to be a good solution to serving static assets alongside Django.

Since swapping out django storage backends in so easy, implementing it
was a
snap.

I did a test with the http testing library
boom and found the response times to very similar between S3 and a Heroku dyno running Django with
Whitenoise.\

It is important for me to remember practicality is just as important as
the Right Way. Until I start getting performance issues with hosting my
static files on Heroku, it seems a whole lot simpler. In this case, that
simplicity is worth the scalability and (future) performance costs.