Website-Geschwindigkeit optimieren: eine praktische Reihenfolge
Arbeit an der Website-Geschwindigkeit hat eine ausgeprägte Pareto-Form: Eine Handvoll Korrekturen macht auf den meisten Websites den Großteil der Verbesserung aus, und es sind fast immer Bilder, Serverantwort und Drittanbieterskripte.
Dieser Leitfaden behandelt die Reihenfolge, in der zu arbeiten ist, wie man misst, ob eine Änderung geholfen hat, und die Optimierungen, die den Aufwand meist nicht wert sind.
Messen Sie, bevor Sie irgendetwas ändern#
Ohne Messung optimiert man, was am einfachsten ist, statt was langsam ist. Zwei Messungen, dann Arbeit.
- Holen Sie Felddaten echter Besucher — den Core-Web-Vitals-Bericht in der Search Console oder Ihr eigenes Monitoring.
- Führen Sie einen Labortest auf den drei wichtigsten Templates durch, gedrosselt auf ein Mittelklasse-Handy im 4G-Netz.
- Notieren Sie die Zahlen, bevor Sie anfangen. Ohne Ausgangswert können Sie nicht sagen, ob eine Änderung geholfen hat.
- Bestimmen Sie je Template das größte einzelne Asset und die größte einzelne blockierende Anfrage.
- Notieren Sie die Time to First Byte gesondert: Liegt sie über 800 ms, rettet Sie keine Frontend-Arbeit.
Die Reihenfolge, die sich lohnt#
Grob nach Verbesserung je Arbeitsstunde, für eine typische Inhalts- oder Broschürenseite.
| Arbeit | Typischer Gewinn | Aufwand |
|---|---|---|
| Bilder optimieren und richtig dimensionieren | Groß | Niedrig |
| Ungenutzte Drittanbieterskripte entfernen | Groß | Niedrig — überwiegend eine politische Aufgabe |
| Caching und ein CDN aktivieren | Groß | Niedrig |
| Renderblockierendes CSS und JS beheben | Mittel bis groß | Mittel |
| JavaScript-Bundle verkleinern | Mittel bis groß | Mittel bis hoch |
| Langsame Datenbankabfragen beheben | Groß, wo zutreffend | Mittel |
| Schriftladen optimieren | Mittel | Niedrig |
| Textassets minimieren und komprimieren | Klein | Niedrig — meist schon aktiv |
| CSS-Selektoren mikro-optimieren | Vernachlässigbar | Nicht der Mühe wert |
Bilder: meist der größte Gewinn#
Auf den meisten Websites machen Bilder den Großteil des Seitengewichts aus, und die meisten werden um ein Vielfaches größer ausgeliefert, als sie angezeigt werden. Das ist die billigste große Verbesserung, die es gibt.
- Liefern Sie WebP oder AVIF; beide werden breit unterstützt und sind bei gleicher Qualität typischerweise 25–50 % kleiner als JPEG.
- Erzeugen Sie mehrere Größen und nutzen Sie srcset mit sizes, damit Handys handygroße Dateien laden.
- Liefern Sie nie ein 2000-px-Bild in einen 400-px-Platz — dieser eine Fehler ist außerordentlich verbreitet.
- Laden Sie alles unterhalb der Falz verzögert und nichts darüber.
- Automatisieren Sie es im Build oder im CMS. Von Hand optimierte Bilder hören auf, optimiert zu sein, sobald jemand anderes eines hochlädt.
- Entfernen Sie Metadaten; Kamera-EXIF kann zehner Kilobyte je Datei ausmachen.
Die Automatisierung ist der Punkt. Ein einmaliger Optimierungsdurchlauf verfällt binnen Monaten, wenn neue Inhalte dazukommen, und niemand merkt es, bis sich das Seitengewicht verdoppelt hat.
Drittanbieterskripte und der Server#
Das sind die zwei Bereiche, in denen das Problem meist organisatorisch statt technisch ist: Niemand verantwortet den Tag-Manager, und niemand verantwortet die Hosting-Entscheidung.
| Problem | Was zu tun ist |
|---|---|
| Tag-Manager mit unbekannten Tags | Jedes Tag prüfen; alles löschen, was niemand begründen kann |
| Chat-Widget lädt auf jeder Seite | Bei Interaktion laden, oder nur dort, wo Support gebraucht wird |
| Mehrere Analytics-Werkzeuge | Eines behalten; jedes ist ein vollständiges Skript und eine Verbindung |
| A/B-Test-Skript blockiert das Rendern | Serverseitig verlagern, oder ein Aufblitzen akzeptieren und async laden |
| Langsame TTFB auf Shared Hosting | Vollseiten-Caching ergänzen; Tarif anheben, wenn es bleibt |
| Ungecachte Datenbankabfragen | Die teuren cachen; für die häufigen Indizes anlegen |
| Kein CDN | Eines ergänzen — die billigste globale Latenzkorrektur, die es gibt |
Drittanbieterskripte sind die verlässlichste Quelle unerklärter Verlangsamungen, weil sie sich ändern, ohne es Ihnen zu sagen, und außerhalb Ihres Deployment-Prozesses stehen.
Häufige Fragen
Was ist eine gute Ladezeit?
Die nützlichen Ziele sind die Core-Web-Vitals-Schwellen statt einer einzelnen Ladezahl: LCP unter 2,5 Sekunden und Time to First Byte unter 800 ms. Die Gesamtladezeit ist ein schlechtes Maß, weil eine Seite lange nutzbar sein kann, bevor jedes Asset fertig ist — und auf einem langsamen Gerät weit davor unbenutzbar.
Erhöht eine schnellere Website die Konversion?
In der Regel ja, und der Effekt ist dort am größten, wo Seiten derzeit langsam sind und Besucher in Mobilfunknetzen unterwegs. Der Gewinn von drei auf zwei Sekunden ist weit größer als von anderthalb auf eine. Ist Ihre Website schon schnell, investieren Sie den Aufwand lieber in Inhalt und Klarheit — der Ertrag ist besser.
Lösen Caching-Plugins alles?
Sie lösen eine echte Sache gut — wiederholte Serverarbeit für dieselbe Seite — und können neue Probleme schaffen, besonders bei angemeldeten Nutzern, Warenkörben und Formularen. Gegen überdimensionierte Bilder und Drittanbieterskripte, meist die größeren Probleme, tun sie nichts. Nützlich, aber nicht ausreichend.
Lohnt sich serverseitiges Rendering fürs Tempo?
Wenn Ihre Seiten derzeit nur im Browser gerendert werden, ja: Server-Rendering oder statische Generierung beseitigt einen kompletten Umlauf, bevor Inhalt erscheint, und hilft zugleich der Indexierung. Sind Ihre Seiten bereits serverseitig geliefertes HTML, stellt sich die Frage nicht — Sie haben den Vorteil schon.
website geschwindigkeitseitengeschwindigkeitwebsite performancebildoptimierungcachingcdn
