Der Ist-Zustand
Ein PageSpeed-Score von 66 klingt erstmal nach “geht so”. Der zweite Blick zeigt, wie irreführend das ist: Auf dem Handy lag der Largest Contentful Paint – also der Moment, in dem der wichtigste Inhalt der Seite sichtbar wird – bei über 70 Sekunden. Kein Tippfehler. Über eine Minute, bis auf einem gedrosselten Mobilfunknetz überhaupt etwas Sinnvolles zu sehen war. Die Ursache war schnell eingegrenzt: Der Bericht listet jedes einzelne Bild mit seiner Downloadgröße auf. Und die Liste war eindeutig.
Der größte Hebel
Zwei animierte GIFs im Header – das VYZION-Logo für Light- und Darkmode – waren zusammen für 12,5 MB verantwortlich. Über zwei Drittel des gesamten Ladegewichts der Startseite, für ein Element, das mit 112×42 Pixel angezeigt wird. GIF ist für sowas schlicht das falsche Format. Jedes Bewegtbild wird als eigenständiges Vollbild gespeichert, ohne die Kompressionstricks, die Video-Codecs längst beherrschen. Die Lösung: dieselbe Animation als WebM/MP4 exportieren, dazu gleich auf die tatsächliche Anzeigegröße skaliert statt auf die 800×300 Pixel der Ursprungsdatei. Aus 12,5 MB wurden ein paar hundert KB – bei identischer Optik.
Bilder richtig optimiert
Der Rest der Liste folgte dem gleichen Muster, nur kleiner: PNG-Dateien, die in der Originalauflösung der Kamera oder des Design-Tools abgelegt waren, aber nur als kleine Vorschaukachel angezeigt wurden. Ein Homeoffice-Foto lag mit 1536×959 Pixeln vor, gebraucht wurden 586×390. Zwei Projekt-Vorschaubilder waren im vollen 1200×1200-Format eingebunden, obwohl sie nur als 343×343-Pixel-Kachel erscheinen.
BEISPIEL — Das Muster wiederholt sich fast immer gleich: Ein Bild wird einmal in hoher Auflösung hochgeladen und danach einfach per CSS auf die richtige Größe “heruntergequetscht”. Der Browser lädt trotzdem die volle Datei. Die Lösung ist immer dieselbe: auf die tatsächliche Zielgröße skalieren und als WebP statt PNG ausliefern – das spart in der Regel 60–80 % der Dateigröße, ohne sichtbaren Qualitätsverlust.
Fünf Service-Icons rundeten die Liste ab – jedes für sich klein, aber in Summe ein weiterer, unnötiger Batzen an Ladezeit.
Eine kleine Stolperfalle
Nicht alles lief beim ersten Versuch glatt. Bei der GIF-zu-Video-Konvertierung ging beim WebM-Export der transparente Hintergrund verloren – aus dem durchsichtigen Logo wurde plötzlich ein Logo mit weißem Kasten drumherum, sowohl im Light- als auch im Dark-Mode sichtbar. Der Grund: Das für die Kompression genutzte Pixelformat unterstützt standardmäßig keinen Alphakanal. Die Lösung bestand aus zwei Teilen – WebM neu kodieren mit echter Transparenz (funktioniert in den meisten modernen Browsern), und für MP4, das technisch gar keine Transparenz unterstützen kann, stattdessen den Hintergrund exakt auf die Theme-Farbe legen, damit es dort wenigstens nahtlos wirkt statt sichtbar falsch. Ein kleiner Umweg, der zeigt: Auch bei einer klaren Lösung lohnt sich die Kontrolle danach.
Das Ergebnis
Nach allen Anpassungen: Desktop 100 von 100 Punkten, Mobil 97. Die mobile Ladezeit des wichtigsten Inhalts fiel von über 70 Sekunden auf 2,3 Sekunden.
Das ist kein Selbstzweck. Eine langsame Website kostet doppelt: Google bewertet Ladezeit als Rankingfaktor, und jede Sekunde Wartezeit erhöht messbar die Absprungrate – bevor ein Interessent überhaupt gesehen hat, was du anbietest. Performance-Optimierung ist deshalb fester Bestandteil jedes Projekts, das ich baue, nicht ein optionaler Zusatzschritt am Ende.