There's something I'm not clear about with respect to the stated problem. I have wrestled with the Django static dance myself, but the most obvious solution (to me at least) was to add a `location` section to my nginx config pointing to my static assets path.
I get all the same benefits named in the article; such as gzip, though I have to build my scripts locally ahead of time (which is trivial via Grunt).
But served this way, that route never touches the framework itself. At a glance, it seems that letting nginx deal with those assets would be much faster in terms of response time rather than the alternative of routing through Django.
There's a middle road here. Serve the assets via django, but have a reverse proxy sitting in front of your web server which caches all the subsequent requests for the same resource. (That's why getting the headers right is so important)
If you serve your static resources through S3, you can share the same static resources among multiple app servers. Also, a proper CDN will serve them a lot faster than your app server through nginx can.
CDNs aren't necessarily faster because you have to have a connection to a different server. However the idea is that say you have jQuery loaded for a CDN, and so do a bunch of other sites (so, same URL), they will already have the thing cached when they load up your site.
I just don't think I did a great job of reading the article. Re-reading it now, it seems that a similar assertion was made that was somehow lost on me.
I think the point of 'use your webserver, not Django' was likely not highlighted enough for my early-morning limited reading comprehension.
Have you measured the change from standalone to embedded images in the CSS? Is it really worth the increase in size (due to base64) and the lack of parallelization?
There is a "visit us @ SendHub" in the header of the page, just bellow "SendHub Blog" and their logo. I can see it Chromium in Linux though, haven't tried it in a mobile browser.
I get all the same benefits named in the article; such as gzip, though I have to build my scripts locally ahead of time (which is trivial via Grunt).
But served this way, that route never touches the framework itself. At a glance, it seems that letting nginx deal with those assets would be much faster in terms of response time rather than the alternative of routing through Django.
Am I missing something obvious here?