Wie wir die Ladezeit einer site auf unter eine Sekunde verkürzt haben
Geschwindigkeit ist keine Eitelkeitskennzahl — sie beeinflusst Rankings und Umsatz. Hier ist die genaue Performance-Arbeit, die wir bei jedem Build durchführen, in der Reihenfolge, in der sie am wichtigsten ist.
Die meisten langsamen Websites sind nicht aus mysteriösen Gründen langsam. Sie sind langsam, weil sich eine Handvoll vorhersehbarer Probleme übereinander stapeln — und sie werden in einer vorhersehbaren Reihenfolge behoben. Wenn ein Kunde mit einer Ladezeit von drei Sekunden zu uns kommt, brauchen wir selten exotische Tricks. Wir brauchen Disziplin.
Dies ist dieselbe Checkliste, die wir bei jedem Performance-Projekt abarbeiten, grob in der Reihenfolge ihrer Priorität. Jeder Schritt ist im Verhältnis zu seiner Wirkung kostengünstig, und die meisten sites fühlen sich nach den ersten drei Schritten drastisch schneller an.
Messen, bevor Sie irgendetwas anfassen
Man kann nicht verbessern, was man nicht misst, und man kann eine Verbesserung ohne eine Baseline definitiv nicht nachweisen. Wir beginnen jedes Projekt mit Felddaten, nicht nur mit Laborwerten.
- Labor — Lighthouse und WebPageTest für eine kontrollierte, wiederholbare Momentaufnahme.
- Feld — Metriken echter Nutzer (CrUX / RUM) für das, was Menschen tatsächlich erleben.
- Budget — eine feste Obergrenze pro Route, damit Regressionen in der CI und nicht in der Produktion abgefangen werden.
Ein Laborwert von 100 bedeutet nichts, wenn Ihre echten Nutzer auf Smartphones der Mittelklasse und in unzuverlässigen Netzwerken unterwegs sind. Optimieren Sie für das Feld.
Renderblockierende Ressourcen eliminieren
Der größte Hebel auf den meisten sites besteht darin, CSS und JavaScript aus dem kritischen Pfad zu entfernen. Der Browser kann erst rendern, wenn er das Parsen der renderblockierenden Ressourcen abgeschlossen hat — je weniger es also gibt, desto schneller wird etwas angezeigt.
// defer everything that isn't critical
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Fügen Sie die geringe Menge an CSS, die für den ersten Viewport benötigt wird, inline ein und laden Sie den Rest asynchron. Verzögern Sie nicht kritische Skripte. Das Ziel ist ein First Paint, der auf nichts wartet, was nicht absolut notwendig ist.
Bilder als Budget betrachten
Bilder sind meist das Schwerste auf einer Seite und am leichtesten falsch zu machen. Drei Regeln decken neunzig Prozent der Fälle ab:
- Moderne Formate bereitstellen — AVIF oder WebP — mit einem Fallback.
- Bilder auf ihre gerenderten Abmessungen zuschneiden; senden Sie niemals ein 3000px großes Hero-Bild in einen 600px großen Slot.
- Alles unter dem Falz (below the fold) per Lazy-Load laden und Platz reservieren, um Layoutverschiebungen zu vermeiden.
Am Edge cachen
Sobald die Seite schlank ist, stellt sich als Nächstes die Frage, wie schnell die Bytes den Nutzer erreichen. Ein CDN mit sinnvollen Cache-Headern verwandelt eine 600-ms-Abfrage beim Origin-Server in einen 30-ms-Treffer am Edge. Für dynamische Inhalte sorgt stale-while-revalidate für sofortige Antworten, während im Hintergrund aktualisiert wird.
Performance ist ein Feature. Wir budgetieren sie genauso wie jeden anderen Teil des Builds.
Das Ergebnis
Bei dem Projekt, das diesen Artikel inspiriert hat, sank der Largest Contentful Paint auf der Startseite von 3,1 s auf 0,9 s, und die organischen Conversions stiegen innerhalb des Monats messbar an. Nichts davon war Magie — nur die obige Checkliste, der Reihe nach angewendet.
Wenn sich Ihre site träge anfühlt und Sie nicht sicher sind, wo Sie anfangen sollen, nehmen Sie Kontakt auf — ein kurzes Audit deckt meist die zwei oder drei Änderungen auf, auf die es am meisten ankommt.