django-minify-html
Use minify-html, the extremely fast HTML + JS + CSS minifier, with Django.
Requirements
Python 3.8 to 3.10 supported.
Django 2.2 to 4.0 supported.
Are your tests slow? Check out my book Speed Up Your Django Tests which covers loads of best practices so you can write faster, more accurate tests.
Installation
Install with pip:
python -m pip install django-minify-html
Add django-minify-html to your
INSTALLED_APPS
:INSTALLED_APPS = [ ..., "django_minify_html", ..., ]
Add the middleware:
MIDDLEWARE = [ ..., "django_minify_html.middleware.MinifyHtmlMiddleware", ..., ]
The middleware should be below any other middleware that may encode your responses, such as Django’s
GZipMiddleware
. It should be above any that may modify your HTML, such as those of django-debug-toolbar or django-browser-reload.
Reference
For information about what minify-html does, refer to its documentation.
django_minify_html.middleware.MinifyHtmlMiddleware
The middleware runs minify_html.minify()
on the content of HTML responses. This function minifies HTML, and any inline JavaScript and CSS.
The middleware passes keyword arguments to minify()
from its minify_args
attribute, a dictionary of names to values. These correspond to the values in the Rust library’s Cfg structure, which have defaults in the Python library as visible in the source. By default the middleware overrides minify_css
and minify_js
to True
. If you need to change an argument, subclass the middleware, replace minify_args
, and use your subclass. For example, to preserve comments after minification:
from django_minify_html.middleware import MinifyHtmlMiddleware
class ProjectMinifyHtmlMiddleware:
minify_args = MinifyHtmlMiddleware.minify_args | {
"keep_comments": True,
}
(This example uses Python 3.9’s dictionary merge operator.)
The middleware applies to all non-streaming, non-encoded HTML responses. To restrict this logic, you can subclass, override the should_minify()
method, and use your subclass. The should_minify()
method accepts the request
and response
, and returns a bool
. For example, to avoid minification of URL’s with the URL prefix /admin/
:
from django.http import HttpRequest, HttpResponse
from django_minify_html.middleware import MinifyHtmlMiddleware
class ProjectMinifyHtmlMiddleware:
def should_minify(self, request: HttpRequest, response: HttpResponse) -> bool:
return super().should_minify(request, response) and not request.path.startswith(
"/admin/"
)
Note that responses are minified even when DEBUG
is True
. This is recommended because HTML minification can reveal bugs in your templates, so it’s best to always work with your HTML as it will appear in production. Minified HTML is hard to read with “View Source” - it’s best to rely on the inspector in your browser’s developer tools.
Motivation
HTML minification is an underappreciated techinque for web optimization. It can yield significant savings, even on top of other tools like compression with Brotli or Gzip.
There is an existing package for HTML minification in Django, django-htmlmin. But it is much slower, since it does the minification in Python. At time of writing, it is also unmaintained, with no release since March 2019.
There are other minifiers out there, but in benchmarks minify-html surpasses them all. It’s a really well optimized and tested Rust library, and seems to be the best available HTML minifier.
Some CDN’s provide automatic minification, such as CloudFlare. This can be convenient, since it requires no application changes. But it adds some overhead: non-minified HTML has to first be transferred to the CDN, and the CDN has to parse the response, and recombine it. It also means that you don’t get to see the potential side effects of minification until your code is live. Overall it should be faster and more predictable to minify within Django, at the point of HTML generation.