Django: Introducing django-http-compression

HTTP supports response compression, which can significantly reduce the size of responses, thereby decreasing bandwidth usage and load times for users. It’s a cheap and valuable technique for improving website performance.

Lighthouse, Google’s web performance auditing tool, recommends enabling compression where it is not enabled, presenting estimated bandwidth savings. For example, on one client site, it estimated a 64KiB (65%) saving on a dashboard page:

For Django projects, many deployment situations will let you enable response compression at the web server or CDN level. But there are still cases where you may not have that option or it’s inconvenient, such as with some PaaS providers. In such situations, you can use Django’s built-in GZipMiddleware to use Gzip compression—pop it in MIDDLEWARE, above any middleware that modifies the response content:

MIDDLEWARE = [
    ...,
    "django.middleware.gzip.GZipMiddleware",
    ...,
]

…and hey presto, instant site-wide compression! Browsers and HTTP clients have supported Gzip for decades, so practically all visitors will benefit.

Django’s Gzip support dates back to 2005, before its 1.0 release. Since then, two newer compression algorithms have been developed and achieved wide support: Brotli and Zstandard. Both offer better compression ratios than Gzip, with Zstandard even matching Gzip on speed.

Python 3.14, released this Tuesday, includes Zstandard support in the standard library (release note). To help Django projects take advantage of this, I have created django-http-compression, a drop-in replacement for GZipMiddleware that supports all three algorithms (where available). Brotli support requires the brotli package, and Zstandard support requires Python 3.14+.

Now you can support the best HTTP compression directly in Django through two settings changes:

INSTALLED_APPS = [
    ...,
    "django_http_compression",
    ...,
]
MIDDLEWARE = [
    ...,
    "django_http_compression.middleware.HttpCompressionMiddleware",
    # Remove GZipMiddleware or similar if present!
    ...,
]

The middleware selects the best coding supported by the client, respecting any quality values (q parameters) specified in the accept-encoding header.

My intention with this package is to provide an evolution of GZipMiddleware that can provide a base for adding (at least) Zstandard support to Django itself. It’s already helping, as during its development I found two bugs in GZipMiddleware, reported in Ticket #36655 and Ticket #36656.

Read my book Boost Your Git DX to Git better.

One summary email a week, no spam, I pinky promise.

Related posts:

• Django: Introducing django-watchfiles, for more efficient runserver autoreloading
• Django: Introducing inline-snapshot-django
• Django: introducing django-browser-reload, for automatically refreshing your browser during development

Tags: django