Vor fünf Jahren habe ich eine Performance-Checkliste für ScipioERP geschrieben, die immer noch Traffic bekommt. Vieles davon gilt auch heute noch. Aber einiges hat sich geändert - INP hat FID abgelöst, AVIF lässt WebP alt aussehen, und Edge-first ist vom Konferenzvortrag zum Standard geworden. Hier also die aktualisierte Version, basierend auf dem, was bei unseren Kundenprojekten dieses Jahr tatsächlich etwas bewegt hat.
Wer die ganze Geschichte lesen will, wie wir Jewellerybox.co.uk zum schnellsten Fashion-Onlineshop in UK gemacht haben - der Beitrag lohnt sich immer noch. Hier geht es um die Kurzreferenz.
Server und Infrastruktur
Rendering an die Edge verschieben. Das ist die größte Änderung seit 2021. Cloudflare Workers, Vercel Edge Functions, Deno Deploy - eins davon nehmen. Wir haben bei einem Kunden das SSR von einem Frankfurter Rechenzentrum auf Edge Nodes verschoben und der TTFB fiel von 320ms auf unter 50ms für Besucher aus den USA. Allein diese Änderung brachte 15 Punkte mehr im PageSpeed Score.
HTTP/3 mit QUIC. Falls euer CDN das noch nicht unterstützt, CDN wechseln. Der Verbindungsaufbau allein spart 100-200ms beim ersten Besuch, und das merkt man auf Mobilgeräten mehr als die meisten denken.
Brotli, vorgepackt beim Build. Gzip reicht aus, aber Brotli spart nochmal 15-25% bei Text-Assets. In der Build-Pipeline vorkomprimieren, damit der Server nicht pro Request CPU dafür verbrennt.
DNS prüfen. Ich finde immer noch Kunden bei langsamen DNS-Anbietern. Zu Cloudflare oder Route 53 wechseln. Ein DNS-Lookup kostet 20-80ms pro nicht-gecachter Domain, und die meisten Seiten treffen drei oder vier Domains, bevor überhaupt etwas gerendert wird.
Bilder - immer noch der größte Hebel
AVIF zuerst, WebP als Fallback, JPEG als letzter Ausweg. AVIF komprimiert 30-50% besser als WebP bei Fotos. Ein <picture>-Element verwenden. Wir haben 2021 viel Zeit damit verbracht, und der Picture-Tag-Aufbau ist immer noch frickelig, aber der Gewinn ist real.
Kein 2400px Hero-Bild ans Handy schicken. Klingt offensichtlich. Sehe ich trotzdem jede Woche auf Kundenseiten. srcset und sizes verwenden. Tatsächlich setzen.
Das LCP-Bild nicht lazy-loaden. Das verwirrt viele. Alles unterhalb des sichtbaren Bereichs lazy-loaden, ja. Aber das LCP-Element - meistens das Hero-Bild - sollte sofort laden. Lazy-Loading macht das größte Bild auf der Seite zum letzten, das geladen wird. Der Score bricht ein.
Fonts
Variable Fonts. Eine Datei ersetzt vier oder fünf Weight-/Style-Dateien. Weniger Requests, kleinerer Download. Wir haben bei einem Kunden fünf separate woff2-Dateien durch einen Variable Font ersetzt und 120KB beim initialen Load gespart.
font-display: optional. Das ist besser als swap für CLS. Wenn der Font noch nicht gecacht ist, überspringt der Browser ihn komplett und nutzt den Fallback. Kein Flash, kein Shift. Der Nutzer sieht beim ersten Besuch den Fallback-Font und danach den richtigen. Die meisten merken den Unterschied nicht.
INP - der neue Schmerzpunkt
INP hat First Input Delay im März 2024 abgelöst und misst etwas deutlich Härteres. Nicht nur den ersten Klick, sondern die schlechteste Interaktion während der gesamten Session. Eine Seite kann sich beim Laden schnell anfühlen und trotzdem bei INP durchfallen, weil ein Dropdown-Menü den Main Thread für 200ms blockiert.
Lange Tasks aufbrechen. Alles über 50ms blockiert den Thread. scheduler.yield() verwenden, wenn möglich, oder die Arbeit einfach aufteilen. Wir hatten eine Produkt-Filter-Komponente, die einen einzelnen 180ms-Task ausführte. Die Aufteilung in drei 60ms-Chunks löste das INP-Problem, ohne dass der Nutzer etwas davon merkte.
Alles aufschieben, was nicht für den First Paint gebraucht wird. Analytics, Chat-Widgets, Social Embeds. Nichts davon muss laufen, bevor die Seite interaktiv ist. Ich habe diesen Fehler auf unserer eigenen Seite gemacht - Chatwoot lud synchron und fügte jeder Seite 400ms hinzu. Umgestellt auf Laden beim ersten Klick und das Problem war weg.
Lange Listen virtualisieren. Wer 500+ Elemente in einer scrollenden Liste rendert, sollte eine Virtual-Scroll-Bibliothek verwenden. Das DOM hat Grenzen und INP findet sie.
Was ich für 2027 beobachte
Die Speculation Rules API ist interessant. Chrome unterstützt sie, Firefox arbeitet daran. Seiten prerendern, die der Nutzer wahrscheinlich als nächstes besucht, und wenn es klappt, fühlt sich die Navigation sofort an - buchstäblich null Ladezeit auf der nächsten Seite.
Die View Transitions API ist die andere. Native Seitenübergänge ohne JavaScript. Macht Multi-Page-Apps so flüssig wie SPAs, ohne den SPA-Overhead. Wir haben sie noch nicht bei einem Kundenprojekt eingesetzt, aber ich vermute, innerhalb des Jahres wird es soweit sein.
Falls irgendwas davon auf eurer Liste steht und ihr Hilfe braucht - meldet euch. Wir machen das schon eine Weile und es ist einer der Teile des Jobs, der mir wirklich Spaß macht.