5. Serving Static Files

Overview

In this chapter, you will start by learning the difference between static and dynamic responses. You will then see how the Django staticfiles app helps manage static files. Continuing work on the Bookr app, you will enhance it with images and CSS. You'll learn the different ways you can lay out your static files for your project and examine how Django consolidates them for production deployment. Django includes tools to reference static files in templates and you'll see how these tools help reduce the amount of work needed when deploying an application to production. After this, you'll explore the findstatic command, which can be used to debug issues with your static files. Later, you'll get an overview of how to write code for storing static files on a remote service. Finally, you'll look at caching web assets and how Django can help with cache invalidation.

Introduction

A web application with just plain Hypertext Markup Language (HTML) is quite limiting. We can enhance the look of web pages with Cascading Style Sheets (CSS) and images, and we can add interaction with JavaScript. We call all these kinds of files "static files." They are developed and then deployed as part of the application. We can compare these to dynamic responses, which are generated in real time when a request is made. All the views you have written generate a dynamic response by rendering a template. Note that we will not consider templates to be static files as they are not sent verbatim to a client; instead, they are rendered first and sent as part of a dynamic response.

During development, the static files are created on the developer's machine, and they must then be moved to the production web server. If you have to move to production in a short timeframe (say, a few hours), then it can be time-consuming to collect all the static assets, move...

Static File Serving

In the introduction, we mentioned that Django includes a view function called static that serves static files. The first important point to make regarding the serving of static files is that Django is not intended to serve them in production. It is not Django's role, and in production, Django will refuse to serve static files. This is normal and intended behavior. If Django is just reading from the filesystem and sending out a file, then it has no advantage over a normal web server, which would probably be more performant at this task. Furthermore, if you serve static files with Django, you will keep the Python process busy for the duration of the request and it will be unable to serve the dynamic requests to which it is more suited.

For these reasons, the Django static view is designed only for use during development and will not work if your DEBUG setting is False. Since during development we only usually have one person accessing the site at a time (the...

Summary

In this chapter, we showed how to use Django's staticfiles app to find and serve static files. We used the built-in static view to serve these files with the Django dev server in DEBUG mode. We showed different places to store static files, using a directory that is global to the project or a specific directory for the application; global resources should be stored in the former while application-specific resources should be stored in the latter. We showed the importance of namespacing static file directories to prevent conflicts. After serving the assets, we used the static tag to include them in our template. We then demonstrated how the collectstatic command copies all the assets into the STATIC_ROOT directory, for production deployment. We showed how to use the findstatic command to debug the loading of static files. To invalidate caches automatically, we looked at using ManifestFilesStorage to add a hash of the file's content to the static file URL. Finally,...