Warum deine Website langsam ist
Langsame Websites haben fast immer dieselben Grundursachen. Die Werkzeuge unterscheiden sich, die Symptome sind identisch. Dieses Muster sehe ich bei Magento-Shops, WordPress-Blogs, Wix-Seiten und Custom Builds:
- ▸Zu grose JavaScript-Bundles, die der Browser parsen muss, bevor etwas sichtbar wird. Jede unnotige Library zahlt.
- ▸Render-blockierende Ressourcen: CSS oder Skripte im <head>, die das Zeichnen der Seite blockieren.
- ▸Bilder ohne Kompression, ohne WebP-Konvertierung, ohne korrektes Sizing pro Viewport.
- ▸Hohe TTFB (Time to First Byte) durch einen langsamen Server, fehlende Cache-Schichten oder eine Datenbankabfrage bei jeder Anfrage.
- ▸Third-Party-Skripte, die asynchron laden, aber trotzdem den Main Thread belegen: Google Tag Manager, Chat-Widgets, Consent-Banner, Social Embeds.
Die meisten Websites haben drei oder vier davon gleichzeitig. Das ist kein Zufall. Plattformen wie Wix und fruhe WordPress-Themes wurden fur Funktionalitat gebaut, nicht fur Geschwindigkeit. Die technische Schuld wachst, solange niemand sie aktiv im Blick hat.
Was Core Web Vitals wirklich messen
Google misst drei Signale fur Nutzererfahrung. LCP (Largest Contentful Paint) misst, wie schnell das groste sichtbare Element geladen ist. Das ist fast immer ein Hero-Bild oder eine grose Uberschrift. Alles uber 2,5 Sekunden ist schlecht. Alles uber 4 Sekunden ist sehr schlecht.
INP (Interaction to Next Paint) misst, wie schnell die Seite auf einen Klick oder Tastenanschlag reagiert. Es ersetzte 2024 definitiv den First Input Delay und ist jetzt das wichtigste Reaktivitats-Signal. CLS (Cumulative Layout Shift) misst, wie stabil die Seite wahrend des Ladens ist. Schaltflachen, die verschieben, Text, der durch spat ladende Werbung hochrutscht: das sind CLS-Quellen.
Google nutzt diese drei als Ranking-Signale in den Suchergebnissen. Aber abseits von SEO: Eine Seite mit 4 Sekunden LCP verliert durchschnittlich 7% Conversion pro zusatzlicher Sekunde Verzogerung. Das sind keine abstrakten Statistiken. Das sind Bestellungen, Anfragen und Kontaktformulare, die nie ankommen.
Mein Audit-Ansatz
Ein Performance-Audit ohne Daten ist Raten. Ich messe immer zwei Dinge gleichzeitig: Lab-Daten und Field-Daten. Lab-Daten kommen aus Lighthouse und der PSI API, ausgefuhrt gegen deine URL unter kontrollierten Bedingungen. Field-Daten kommen aus dem Chrome User Experience Report (CrUX), den echten Messwerten deiner Besucher uber die letzten 28 Tage.
- ▸PSI-API-Lauf auf allen kritischen Seiten: Homepage, Kategorienseite, Produktseite, Kontaktseite. Jede Seite separat, da Probleme selten einheitlich sind.
- ▸Network-Waterfall-Analyse in Chrome DevTools: welche Ressource was blockiert, welche Anfragen sequenziell sind, die parallel laufen konnten.
- ▸Treeshake-Check auf JavaScript-Bundles: welche Abhangigkeiten geladen, aber teilweise oder gar nicht genutzt werden.
- ▸Bild-Audit: Format, Kompressionsverhaltnis, Dimensionen versus Anzeigegrosse, Lazyload-Implementierung.
- ▸Third-Party-Impact-Messung: wie viel Main-Thread-Zeit Skripte ausserhalb deiner Domain beanspruchen.
Das Ergebnis ist eine priorisierte Liste von Engpassen, sortiert nach Auswirkung. Nicht alle Probleme sind gleich schwer. Ich beginne dort, wo der groste Gewinn liegt.
Was ich typischerweise behebe
Nach dem Audit implementiere ich die Fixes. Auf den meisten Websites handelt es sich um eine Kombination folgender Eingriffe:
- ▸Next.js Image-Komponente: automatische WebP-Konvertierung, korrektes Sizing via srcset, Lazy Load fur Elemente ausserhalb des Viewports, Eager Load fur das LCP-Bild.
- ▸ISR-Cache-Konfiguration: Seiten werden gerendert und als statische Dateien gecacht, sodass der Server pro Besucher nichts berechnen muss.
- ▸Font-display: swap auf Webfonts setzen, damit die Seite Text anzeigt, wahrend die Schrift ladt, statt eines unsichtbaren Flackerns.
- ▸CSS-Blocking entfernen: kritisches CSS inline, nicht-kritisches CSS deferred oder via Preload mit Media Queries.
- ▸Third-Party-Skripte deferred laden: Google Analytics, GTM und Consent-Banner nach dem First Contentful Paint, nicht davor.
- ▸Kritische Bilder vorladen: die LCP-Ressource im <head> anmelden, damit der Browser sie fruher abruft.
Welche Fixes zutreffen, hangt von deinem Stack ab. Bei einer Magento-Installation ziehe ich andere Hebel als bei einer WordPress-Seite oder einer Next.js-Anwendung. Der Ansatz ist immer spezifisch fur das, was die Daten zeigen.
-- Kunden-Case
CarCare24: LCP von 14 Sekunden auf 6,8s Lab, 2,14s echte Besucher
CarCare24 ist ein Magento 2 Shop mit rund 3.400 Produkten auf Hypernode mit Cloudflare Free. Vor den Performance-Waves lag der PSI-Lab-LCP auf Mobil bei 14 bis 16 Sekunden.
Das Audit offenbarte drei primaire Engpasse:
Nach neun Waves mit Hero-Image-Optimierung, WebP-Konvertierung, Deferred Third-Party-Scripts und einem eigenen CSP-Modul liegt der PSI-Lab-LCP auf Mobil bei 6,8 Sekunden. Der mobile Performance-Score im Lab variiert zwischen 38 und 65 am selben Tag, abhaengig von der CPU-Throttle-Varianz. Das ist normal fuer Lab-Messungen. Was zaehlt: CrUX-Daten echter Besucher ueber 28 Tage zeigen LCP 2,14 Sekunden, INP 111ms, CLS 0,05. Alle Core Web Vitals sind im gruenen Bereich. Accessibility stieg von 90 auf 100, Best Practices von 88 auf 96, SEO 100. PSI Lab simuliert 4x CPU-Throttling und Slow 4G. Das ist ein Worst-Case-Szenario, nicht repraesentativ. CrUX ist das, was Ihre Kunden erleben. Ich optimiere fuer das Zweite.
Was ich nicht mache
Es gibt Abkurzungen, die einen Lighthouse-Score nach oben treiben, ohne die Nutzererfahrung zu verbessern. Ich verwende sie nicht.
- ✕Ressourcen vorladen, die nicht auf dem kritischen Pfad liegen, nur um den Score zu erhohen.
- ✕Font-display: optional setzen, damit Fonts weggelassen werden, wenn sie nicht schnell genug laden. Scored besser, sieht schlechter aus.
- ✕Bilder entfernen oder verbergen, um CLS zu senken, ohne die Grundursache zu beheben.
- ✕Content Security Policy Header so anpassen, dass Third-Party-Skripte kaputtgehen, um ihre Auswirkungen zu verbergen.
- ✕Lighthouse-Bots eine leichtere Seite anzeigen als echten Besuchern. Google erkennt das.
Ein Score von 100 auf einer Seite, die niemand besucht, ist wertlos. Ich optimiere die Seiten, die Traffic bringen, mit Fixes, die unter echten Nutzern auf echten Netzwerken standhalten.
Tools, die ich verwende
Der Kern meines Werkzeugkastens: die PSI API fur reproduzierbare Lab-Scores auf jeder URL, Chrome DevTools fur Network Waterfall und Main-Thread-Profiling, WebPageTest fur Multi-Step- und geographisches Testing, sowie Lighthouse CI in der Build-Pipeline, damit Regressionen fruh erkannt werden. Fur Field-Daten verwende ich das CrUX-Dashboard und den Google Search Console Core Web Vitals-Bericht.
Bei Magento-spezifischer Arbeit nutze ich zudem Blackfire fur PHP-Profiling langsamer Backend-Prozesse sowie das Magento Performance Toolkit fur Lastmuster. Auf Next.js-Stacks analysiere ich Bundle-Output via @next/bundle-analyzer und trace Server-Side-Rendering-Engpasse mit dem integrierten Next.js Trace Viewer.
Audit- und Optimierungs-Engagements
Ein Performance-Engagement lauft in zwei Phasen. Erst das Audit: messen, analysieren, Engpasse priorisieren. Dann optional die Implementierung: Fixes durchfuhren, erneut messen, iterieren. Du kannst nur fur das Audit oder fur das vollstandige Engagement buchen.
Auditpreis abhangig von der Anzahl der Seiten und dem Stack. Magento und Custom Builds erfordern mehr Messpunkte als eine einzelne Next.js-Seite. Der Preis wird nach einem ersten Kennenlernen festgelegt.