10 MB weniger im Portfolio: So konvertierst du Bilder mit einem Befehl zu WebP

Seit Wochen blinkt die Meldung von PageSpeed Insights unübersehbar: Während die Desktop-Version meines Portfolios noch mit 91 Punkten glänzt, kämpft die mobile Version mit nur 63 Punkten. Ich hatte bereits alles Nötige umgesetzt – Schriftarten asynchron laden, fetchpriority für das Hero-Bild setzen und Server-Push für kritische Ressourcen konfiguriert. Doch dann der nächste Hinweis:

Optimierung der Bildübertragung — Einsparpotenzial: 985 KiB

Fast ein ganzes Megabyte an unnötigem Datentransfer, verursacht durch nur sechs Screenshots. Und das waren nur die Bilder oberhalb der Faltlinie. Im gesamten Portfolio sah es noch schlimmer aus.

Der Grund? Jedes hochgeladene Bild war ein unkomprimiertes PNG – verlustfrei, in voller Auflösung und direkt vom Bildschirm gescreent. Niemand hatte es optimiert, denn im Django-Admin wurde es akzeptiert und im Browser korrekt angezeigt. Doch „korrekt angezeigt“ ist nicht gleichbedeutend mit „schnell geladen“.

Warum PNGs in Portfolios oft zu groß sind

Screenshots von Projekten landen schnell als PNG in Content-Management-Systemen wie Django. Das Format speichert jeden Pixel unverändert, was bei komplexen Grafiken oder Texten eine Dateigröße von über einem Megabyte zur Folge haben kann. Ein 1,4 MB schweres PNG einer Anwaltskanzlei-Website lässt sich jedoch als WebP bei einer Qualität von 85 mit nur 175 KB darstellen – bei identischem visuellen Ergebnis. Die Datei ist also achtmal kleiner.

Multipliziert man diese Einsparung mit 28 Projekten, summieren sich schnell mehrere Megabyte, die Nutzer auf langsamen 4G-Verbindungen unnötig herunterladen, nur um über Miniaturbilder zu scrollen. Die Performance leidet, und die Absprungrate steigt.

Alte Bilder konvertieren: Ein Management-Befehl für den Backlog

Um die bestehenden Bilder zu optimieren, brauchte ich eine Lösung, die direkt im Produktionssystem läuft und Zugriff auf das Django-Modell sowie den Speicherort (z. B. S3) hat. Ein Management-Befehl war dafür ideal, da er ohne externe Abhängigkeiten im Container ausgeführt werden kann.

# backend/projects/management/commands/convert_images_to_webp.py
from io import BytesIO
from django.core.files.base import ContentFile
from django.core.management.base import BaseCommand
from PIL import Image
from backend.projects.models import AudioWork, Project

def _to_webp(field_file, quality: int = 85) -> tuple[ContentFile, str] | None:
    try:
        with field_file.open("rb") as f:
            img = Image.open(f)
            img.load()
    except OSError as exc:
        return None, str(exc)

    mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
    img = img.convert(mode)

    buf = BytesIO()
    img.save(buf, format="WEBP", quality=quality, method=6)
    buf.seek(0)

    old_name = field_file.name
    new_name = old_name.rsplit(".", 1)[0] + ".webp"
    return ContentFile(buf.read(), name=new_name), new_name

Der Befehl durchläuft alle Projekte und Audioarbeiten, öffnet die Bilder aus dem Speicher, konvertiert sie zu WebP und speichert die neue Version unter dem ursprünglichen Namen mit der Endung .webp. Dabei wird die Transparenz beibehalten, sofern das Original sie unterstützt. Andernfalls wird das Bild in den RGB-Modus konvertiert, um Fehler zu vermeiden.

# Ausschnitt aus der Command-Klasse
class Command(BaseCommand):
    help = "Konvertiert Projekt- und Audiowork-Bilder in WebP-Format."

    def add_arguments(self, parser):
        parser.add_argument("--quality", type=int, default=85)
        parser.add_argument("--dry-run", action="store_true")
        parser.add_argument("--skip-existing", action="store_true", default=True)

Vor der eigentlichen Konvertierung empfiehlt sich ein Trockenlauf mit --dry-run, um die Einsparungen zu prüfen, ohne Daten zu verändern. Im Produktionssystem sieht die Ausgabe dann etwa so aus:

Project: Leagogo Law Firm
[dry-run] projects/LAA_Law.png → projects/LAA_Law.webp (1423 KiB → 175 KiB, spart 1247 KiB)
Project: Flower Head Events
[dry-run] projects/Flower_Head_Events.png → projects/Flower_Head_Events.webp (1187 KiB → 83 KiB, spart 1103 KiB)

Automatisierung für neue Uploads: Signal-Handler in Django

Der Management-Befehl löst das Problem für bestehende Bilder. Doch wie verhindert man, dass künftige Uploads erneut unoptimierte PNGs erzeugen? Die Lösung lag in einem Signal-Handler, der bei jedem neuen Bild-Upload automatisch die Konvertierung zu WebP auslöst.

Dazu wurde in der models.py des Projekts ein Signal definiert, das nach dem Speichern eines neuen Bildes eingreift. Der Handler prüft, ob die Datei bereits als WebP vorliegt, und konvertiert sie sonst im Hintergrund. So entfällt manuelles Eingreifen – das System übernimmt die Optimierung selbstständig.

Fazit: Nachhaltige Performance durch WebP

Die Kombination aus Backlog-Konvertierung und automatischer Optimierung hat mein Portfolio von einem Performance-Problem zu einer Musterschüler-Lösung verwandelt. Die Ladezeiten auf mobilen Geräten sanken deutlich, und die PageSpeed-Insights-Werte stiegen auf über 90 Punkte. Besonders wichtig war die Transparenz im Prozess: Ein einziger Befehl genügt, um alte Bilder zu optimieren, und ein Signal stellt sicher, dass neue Uploads direkt im optimalen Format vorliegen. Wer heute noch unkomprimierte PNGs in Portfolios oder Websites nutzt, sollte diese Schritte umgehend prüfen – der Aufwand lohnt sich für Nutzer und Suchmaschinenrankings gleichermaßen.