website-performance

Was macht website-performance?

Lade brand-guide (damit Geschwindigkeitsoptimierungen das Markenbild nie verändern) und folge website-change-safety.

Methode

1. Ermittle die Baseline mit PageSpeed Insights (mobil, 2–3 Läufe pro Seite, plus Felddaten). Notiere das LCP-Element.
2. Finde die Ursache im Bericht: Lange Tasks, Bootzeit / Drittanbieter-Zusammenfassung, Render-blockierende Anfragen, LCP-Aufschlüsselung (Ladeverzögerung vs. Rendering-Verzögerung), DOM-Größe, erzwungenes Reflow.
3. Behebe jeweils eine Ursache, messe erneut und behalte nur, was hilft.
4. Teste möglichst lokal A/B, bevor du veröffentlichst: Serviere das neue JS/HTML/CSS durch Request-Interception gegen die Live-Seite und serviere BEIDE Versionen auf die gleiche Weise (eine unkomprimierte lokale Datei vs. eine gzippte Live-Datei verfälscht simulierte Timings). Vergleiche Hauptthread-Zeit, DOM-Größe, Style-/Layout-Zeit.

Die Optimierungen, die wirklich Punktzahlen verbessert haben (prüfe diese zuerst)

Drittanbieter- und Plattformgewicht (meist der größte Faktor)

• Deinstallierte Apps, die weiterhin laden. Entferne übrig gebliebene Page-Builder-Widgets und Skripteinträge. Manche Plattformen injizieren nach dem Entfernen einer App weiterhin eine Integration (z. B. eine Laufzeitumgebung eines visuellen Editors mit 50+ Dateien); suche nach einem „Deaktivieren“-Schalter auf Kanal-/Storefront-Ebene, sonst frage den Plattform-Support.
• Lade bei Bedarf, nicht auf jeder Seite: Videoplayer (zeige ein Posterbild + Play-Button, erstelle das Iframe erst bei Klick), Captchas (lade, wenn das Formular geöffnet wird), Chat-Widgets, Treue-/Prämien-Widgets (nur auf der Seite, die sie benötigt), Bewertungs-Widgets unterhalb der Falte.
• Eingebettete Videoblöcke, die über einen Page Builder hinzugefügt wurden, können vom Theme nicht verzögert werden; verschiebe diese Videos in den eigenen Videobereich des Themes, der eine Click-to-Load-Fassade verwendet.
• Duplikate: zwei Analytics-Bibliotheken, derselbe Tag zweimal, ein alter und ein neuer Pixel.
• Verzögere keine Anzeigen-/Analyse-Tags bis zur Interaktion ohne Zustimmung des Eigentümers; das verändert deren Daten.

JavaScript, das beim Laden zu viel tut

• Karussells/Slider: Desktop-First-Slider-Einstellungen erstellen oft das Desktop-Layout und bauen es dann für Smartphones neu auf; wechsle zu Mobile-First-Einstellungen. „Unendlich/Loop“-Modi klonen jedes Slide 2–3x (hunderte zusätzliche Elemente); schalte Looping dort aus, wo es nicht benötigt wird. Initialisiere Slider, die unterhalb des ersten Bildschirms starten, erst, wenn sie in die Nähe des Viewports kommen (IntersectionObserver), mit CSS, das die nicht initialisierte Reihe auf gleicher Höhe zeigt, damit nichts springt.
• Page Builder und Plugins (insbesondere WordPress/Wix/Squarespace): Jedes Plugin kann sein eigenes CSS/JS zu jeder Seite hinzufügen; deaktiviere, was nicht verwendet wird, und lade den Rest nur dort, wo er benötigt wird.
• Verstecktes doppeltes Markup: z. B. Auflistungsseiten, die ein Grid UND eine versteckte Listenansicht jedes Produkts rendern. Rendere nur eines.
• Entferne übrig gebliebenes Debug-Logging und tote Codepfade, die immer noch ausgeführt werden.

Largest Contentful Paint

• Identifiziere das tatsächliche LCP-Element. Wenn es sich um ein CSS-Hintergrundbild handelt, findet der Browser es spät; füge <link rel="preload" as="image" fetchpriority="high"> nur auf dieser Seite hinzu, mit der URL byte-identisch zu der, die das CSS auflöst (sonst wird es zweimal heruntergeladen).
• Nur die erste sichtbare Bildreihe erhält fetchpriority="high" (z. B. 2 bei einem zweispaltigen Smartphone-Grid); mehr hochpriorisierte Bilder teilen die Bandbreite mit dem eigentlichen LCP-Bild.
• Lade das LCP-Bild niemals lazy. Lazy-lade alles unterhalb der Falte.
• Prüfe, welches Format die Plattform bereits ausliefert (viele CDNs konvertieren automatisch zu WebP/AVIF); erneutes Speichern von Bildern bringt möglicherweise nichts. Große Gewinne erzielst du mit überdimensionierten Quellbildern und falschen sizes.

Erste Darstellung / Render-Blocking

• Das Hauptstylesheet des Themes ist meist der Engpass. Seitenspezifisches CSS kann ausgelagert oder kritisches CSS inline eingefügt werden, aber das ist ein größeres, riskanteres Projekt; schlage es vor, schleiche es nicht ein.
• Jedes zusätzliche render-blockierende Stylesheet oder synchrone Skript im <head> (oft von Apps injiziert) fügt Verzögerung hinzu.
• Schriftarten: Halte font-display-Entscheidungen absichtsvoll (Symbolschriften benötigen block; Textschriften können swap nur verwenden, wenn die Fallback-Metriken nahe genug sind, um Layoutverschiebungen zu vermeiden).

Layout-Verschiebung

• Reserviere Platz für Bilder (width/height), Embeds (aspect-ratio-Box), späte Banner und Widgets.
• Alles, was von JS initialisiert wird, muss vor der Initialisierung CSS mit derselben Größe haben.

Bericht

Vorher/Nachher-Zahlen pro Seite (als Bereiche), Felddaten-Status, was sich geändert hat und was mit Entscheidung des Eigentümers offen bleibt (Kompromisse bei Drittanbietern). Erinnere sie daran, dass Laborwerte variieren; Trends und Felddaten sind wichtiger als ein einzelner Durchlauf.