In der vorigen Lektion hast du gelernt, einen Messwert zu lesen. Jetzt geht es darum, ihn zu verändern. Wenn du deine Website optimieren willst, ist die schwierigste Frage nämlich nicht, welche Maßnahmen es gibt, sondern in welcher Reihenfolge du sie angehst und wo du selbst aufhören musst.
Um Texte, Keywords und die Frage, welche Variante mehr Anfragen bringt, geht es hier ausdrücklich nicht. Das ist Thema der Lektion zur Conversion-Optimierung. Diese Lektion beschäftigt sich mit der technischen Seite: Was macht die Seite schneller und sauberer, ohne dass sie dabei kaputtgeht.
Kurzantwort
Wie gehst du vor, wenn du deine Website optimieren willst?
In einer Reihenfolge, die sich am gemessenen Ausgangswert orientiert, nicht an der Gewohnheit. Fast jeder Ratgeber beginnt mit “Bilder komprimieren”, dabei entfällt in den Felddaten bei Seiten mit schlechtem Ladeerlebnis der größte Zeitblock auf die Server-Antwortzeit und der kleinste auf das eigentliche Laden des Bildes.
Das heißt nicht, dass Bilder egal wären. Es heißt, dass die übliche Startmaßnahme im Schnitt am kleinsten Block ansetzt.
📌 Für wen ist das relevant: Für alle, die eine Website betreiben, selbst nicht programmieren und wissen wollen, was sie selbst erledigen können und was sie beauftragen müssen.
- Eine begründete Reihenfolge in sieben Schritten, mit Angabe zu Aufwand und Risiko
- Bei jeder kursierenden Prozentzahl die Frage: Wer hat gemessen, und wovon lebt derjenige?
- Die Maßnahmen, die Schaden anrichten können, und der Punkt, an dem Nachoptimieren nicht mehr reicht
Das lernst du in dieser Lektion
Du kennst eine begründete Reihenfolge und weißt, warum sie so aussieht.
Du kannst trennen, was du selbst erledigst und was einen Dienstleister braucht.
Du prüfst jede Prozentzahl auf ihre Herkunft, bevor du eine Entscheidung darauf stützt.
Du weißt, welche Maßnahmen Schaden anrichten können und wie du ihn vermeidest.
Inhalt
01 ·
Wo die Zeit tatsächlich hingeht
Fast jede Anleitung beginnt an derselben Stelle: Bilder komprimieren. Das ist naheliegend, denn Bilder sind das, was man sieht. Googles Leitfaden zum Largest Contentful Paint nennt allerdings eine andere Bearbeitungsreihenfolge, im Wortlaut:
“1. Eliminate resource load delay
2. Eliminate element render delay
3. Reduce resource load duration
4. Reduce time to first byte”
Bildkomprimierung fällt unter den dritten Punkt, nicht den ersten. Die Begründung liefert derselbe Leitfaden:
“Our research shows that the load duration portion of LCP tends not to be a significant bottleneck for most sites. Whenever possible, consult your site’s real-user data for help deciding which LCP subpart to focus your efforts on.”
Darin stecken zwei Aussagen: Die Zeit, die ein Bild zum Laden braucht, ist bei den meisten Seiten nicht der Engpass. Und entscheiden sollen die eigenen Felddaten, nicht eine allgemeine Liste, auch nicht die aus dieser Lektion.
Die vier Bestandteile des LCP bei Seiten mit schlechtem Wert
Jeweils der Wert im 75. Perzentil, Web Almanac 2024 auf Basis von CrUX-Felddaten
Die Zeit bis zum ersten Byte vom Server, der größte der vier Blöcke. Bei Seiten mit gutem LCP: 600 ms.
Bis der Browser überhaupt erfährt, dass er das Bild laden soll. Bei gutem LCP: 350 ms.
Vom fertig geladenen Bild bis zur Darstellung. Bei gutem LCP: 230 ms.
Der kleinste Block, und genau der, an dem die üblichen Anleitungen zuerst ansetzen. Bei gutem LCP: 160 ms.
Eigenständige Perzentilwerte aus verschiedenen Verteilungen, keine Teile einer einzelnen Messung. Sie dürfen nicht addiert und nicht in Prozentanteile umgerechnet werden. Dass die Bild-Ladedauer den geringsten Einfluss hat, steht als Aussage im Kapitel selbst und folgt nicht aus dem Vergleich dieser vier Zahlen.
Quelle: The Web Almanac by HTTP Archive, Ausgabe 2024, Kapitel “Performance”, Abbildung 9.10, Datenbasis CrUX, abgerufen 16.08.2026 – unabhängige Branchenauswertung eines Open-Source-Projekts. Die Ausgabe 2025 wiederholt die Tabelle nicht, bestätigt die Richtung aber ausdrücklich. Stand 08/2026, eigene Darstellung, Ostend Digital.
Das Kapitel selbst schreibt, die Bild-Ladedauer habe “the least impact on LCP time”, und nennt die Server-Antwortzeit den größten Teil. Wichtig ist, was daraus nicht folgt: Das ist eine Verteilung über Millionen Websites, keine Diagnose deiner Seite. Eine Seite mit einem sechs Megabyte großen Titelbild hat sehr wohl ein Ladedauer-Problem.
Warum Bilder trotzdem das Thema bleiben
Zwei Befunde gelten gleichzeitig. Laut Web Almanac 2025 ist auf 76 Prozent der mobilen Seiten ein Bild das LCP-Element, auf dem Desktop sind es 85,3 Prozent. Trotzdem ist die Ladedauer dieses Bildes selten der Engpass.
Der Widerspruch löst sich über die zweite Zeile im Schaubild: Das Problem ist meist nicht, dass das Bild zu groß ist, sondern dass der Browser zu spät davon erfährt. Die typischen Gründe, hier aus mehreren Google-Leitfäden zusammengezogen und so in keiner einzelnen Quelle zu finden, sind ein Bild, das per CSS-Hintergrund oder JavaScript eingebunden ist statt als Bildelement im HTML, ein Slider davor oder ein fälschlich gesetztes verzögertes Laden.
Auch blockierende Stylesheets und Skripte halten den Browser auf. Dazu ist Google ungewöhnlich deutlich: Synchrone Skripte im Kopfbereich des Dokuments seien “almost never necessary”.
💡 Merke
Die übliche Reihenfolge ist nicht falsch, sie setzt nur am kleinsten Block an. Bildkomprimierung wirkt, sie ist nur selten dort, wo bei einer langsamen Seite die meiste Zeit liegt.
Belegt ist: Die Ladedauer der LCP-Ressource ist bei den meisten Seiten nicht der Engpass. Nicht belegt wäre: Bilder sind egal.
Und weil das eine Durchschnittsaussage ist, gilt Googles Zusatz: Sieh in deine eigenen Felddaten. Wie du sie liest, steht in Lektion zu den Core Web Vitals.
02 ·
Die Reihenfolge in sieben Schritten
Die folgende Reihenfolge ist eine Empfehlung dieser Lektion, keine Google-Vorgabe. Sie leitet sich aus den Quellen oben ab und ist zusätzlich danach sortiert, was ohne Entwicklerteam machbar ist. Sie ersetzt den Blick in die eigenen Werte nicht, sie sagt nur, wo du anfängst, wenn du keinen anderen Anhaltspunkt hast.
| Schritt | Was du tust | Selbst machbar? | Risiko |
|---|---|---|---|
| 0 | Messen, bevor du anfängst | ja | keins |
| 1 | Offensichtliche Schwergewichte entfernen: Slider im Kopfbereich, Autoplay-Video, ungenutzte Plugins | ja | gering |
| 2 | Bilder in Ordnung bringen: richtige Maße, modernes Format, Maßangaben gesetzt | weitgehend ja | gering |
| 3 | Lazy Loading richtig setzen: nicht auf das Titelbild, ja auf alles weiter unten | teilweise | gering |
| 4 | Schriften und Drittanbieter-Skripte reduzieren | teilweise | mittel |
| 5 | Caching und Hosting prüfen | entscheidbar, nicht ausführbar | mittel |
| 6 | Blockierende Ressourcen entflechten, kritisches CSS, Preload | nein | hoch |
| 7 | Neu bauen, wenn der Engpass in der Bauweise steckt | nein | hoch |
Zwei Stellen widersprechen der Erwartung und brauchen eine Erklärung.
Warum Schritt 1 vor der Bildarbeit steht. Ein gelöschter Slider ist ein sicherer Gewinn ohne Nebenwirkung, eine Bildoptimierung ein Gewinn mit Qualitätsabwägung. Wer zuerst entfernt, was ohnehin niemand vermisst, muss danach weniger optimieren.
Warum das Hosting trotz größtem Zeitblock erst auf Platz 5 steht. Auch Google führt es zuletzt. Der Grund ist nicht geringe Wirkung, sondern geringe Handhabbarkeit: Ein Hostingwechsel ist ein Projekt mit Migrationsrisiko, kein Handgriff am Nachmittag.
Nicht verhandelbar ist allein Schritt 0. Ohne Ausgangswert wird jede spätere Aussage über die Wirkung deiner Arbeit zur Behauptung.
03 ·
Bilder: dein größter eigener Hebel
Bilder sind der einzige Bereich, in dem du ohne Dienstleister substanziell etwas bewegen kannst. Googles Bild-Leitfaden nennt mehrere Ansätze nebeneinander, ausdrücklich ohne Rangfolge. Für die Praxis lassen sich daraus vier Baustellen trennen, die ständig verwechselt werden.
| Baustelle | Worum es geht | Selbst machbar? |
|---|---|---|
| Maße | Ein Bild, das 600 Pixel breit angezeigt wird, muss nicht 4.000 Pixel breit hochgeladen werden | ja, vor dem Hochladen |
| Format | Moderne Formate wie WebP oder AVIF statt JPEG und PNG | ja, meist eine Einstellung |
| Kompression | Dieselben Maße, weniger Dateigröße | ja, mit einem Werkzeug im Browser |
| Maßangaben | Breite und Höhe im Code, damit der Platz reserviert ist | im Editor ja, im Theme nein |
Die letzte Zeile wird am häufigsten übersehen, weil sie nichts mit Dateigröße zu tun hat. Laut Web Almanac 2025 setzen 62 Prozent der mobilen Seiten bei mindestens einem Bild keine Maßangaben, 2024 waren es 66 Prozent. Ein perfekt komprimiertes Bild ohne Größenangabe lässt die Seite genauso springen wie ein vier Megabyte großes.
Als Werkzeuge für die Kompression nennt Chrome in seiner Dokumentation Squoosh, ImageOptim und Imagemin. Squoosh ist ein Google-Projekt, läuft im Browser und kostet nichts, das ist also keine Blog-Empfehlung, sondern eine Nennung aus der Herstellerdokumentation.
Die Format-Frage und was hinter der bekanntesten Zahl steckt
Über moderne Bildformate kursiert eine Zahl, die in fast jedem Ratgeber steht. Sie ist ein Musterfall dafür, warum du bei jeder Prozentangabe fragen solltest, wer gemessen hat und wovon derjenige lebt.
“WebP ist 25 bis 35 Prozent kleiner als JPEG”
Zwei Parteien, zwei Ergebnisse, dieselbe Frage
Wer die Zahl liefert
Googles WebP Compression Study
Ergebnis: 25 bis 34 Prozent kleinere Dateien bei gleichem Ähnlichkeitsindex, auf web.dev als “25 bis 35 Prozent” wiedergegeben. Verglichen wurde gegen cjpeg aus libjpeg 6b, den Referenzencoder aus den 1990er Jahren. Google entwickelt WebP.
Wer widerspricht
Mozilla Research, 2013
Ergebnis wörtlich “inconclusive”: besser nach einigen Bewertungsalgorithmen, ähnlich oder schlechter nach anderen. Mozilla entwickelte zeitgleich den Konkurrenz-Encoder mozjpeg, war also ebenfalls Partei.
Moderne Formate liefern dasselbe Bild in einer kleineren Datei. Wie viel kleiner, hängt vom Bild und vom Werkzeug ab. Rechne mit einer Verbesserung, nicht mit einer festen Zahl.
Quellen: Google for Developers, “WebP Compression Study” (Vergleichsencoder libjpeg 6b) und web.dev, “Use WebP images” (Seitenstand 05.11.2018); Mozilla Research, “Studying Lossy Image Compression Efficiency” (17.10.2013). Beide abgerufen 16.08.2026. Stand 08/2026, eigene Darstellung, Ostend Digital.
Beim jüngeren Format AVIF ist die Belegkette noch dünner. Für den Vergleich mit JPEG und WebP nennt Google keine eigenen Messwerte, sondern Zahlen eines kommerziellen Bild-CDN-Anbieters, der genau diese Formatumwandlung verkauft, ohne Testparameter. Für dich ist die Debatte ohnehin zweitrangig: Der Unterschied zwischen beiden Formaten ist kleiner als der zu dem, was heute auf deiner Seite liegt.
Auch beim Optimieren gibt es übrigens ein Zuviel. Google warnt davor, immer mehr Bildvarianten auszuliefern: “every additional image variant comes at a cost and makes less efficient use of the browser cache”.
WordPress: was das System selbst kann und was nicht
Seit WordPress 5.8 lassen sich WebP-Dateien hochladen, seit Version 6.5 auch AVIF, laut Core-Team “just like you would a JPEG or PNG image today”. Entscheidend ist, was der Kern ausdrücklich nicht tut: Bestehende JPEG- und PNG-Dateien werden nicht automatisch umgewandelt.
Wer glaubt, ein System-Update habe seinen Bildbestand modernisiert, irrt sich. Nur neue Uploads können im neuen Format liegen, für den Bestand braucht es ein Plugin. Und AVIF funktioniert überhaupt nur, wenn die Bildbibliothek deines Servers es unterstützt, nachzusehen unter Werkzeuge und dann Website-Zustand.
Diese Prüfung kostet 30 Sekunden. Was WordPress sonst ausmacht, steht in Lektion zu den WordPress-Grundlagen.
04 ·
Lazy Loading: Maßnahme und Schaden zugleich
Lazy Loading heißt, dass Bilder erst geladen werden, wenn sie in den sichtbaren Bereich kommen. Unterhalb des ersten Bildschirmausschnitts ist das der von Google empfohlene Weg, und es funktioniert gut: Nach Chrome-Messungen waren im 4G-Netz auf Android 97,5 Prozent dieser Bilder innerhalb von 10 Millisekunden nach dem Sichtbarwerden da, im langsamen 2G-Netz 92,6 Prozent.
Für das Bild ganz oben gilt das Gegenteil, und Google formuliert es ungewöhnlich absolut:
“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay”
Deshalb bekommt diese Maßnahme einen eigenen Schritt. Wer “Lazy Loading aktivieren” liest und es global einschaltet, verzögert genau das Bild, auf das die wichtigste Metrik schaut. Laut Web Almanac 2025 laden rund 16 bis 17 Prozent aller Seiten ihr LCP-Bild verzögert, dort verschlechtert die Maßnahme den Wert, den sie verbessern sollte.
Der Teil, den Performance-Ratgeber fast nie erwähnen
Falsch umgesetztes Lazy Loading kann Inhalte vor Google verstecken. Das steht nicht in der Performance-, sondern in der Suchdokumentation, dort wörtlich: “if not implemented correctly, this technique can inadvertently hide content from Google”.
Die Begründung ist schlicht: “Google Search does not interact with your page.” Der Crawler scrollt nicht und klickt nicht. Was erst auf eine Nutzeraktion hin nachgeladen wird, etwa über “Mehr laden” oder endloses Nachladen beim Scrollen, sieht er nicht.
💡 Praxis-Tipp
Die Gegenprobe kostet nichts und braucht keinen Dienstleister. Öffne das URL-Prüfwerkzeug in der Search Console, lass dir das gerenderte HTML anzeigen und suche nach deinen Bildern.
Google beschreibt die Prüfung so: Die Bild- oder Video-Adressen müssen im src-Attribut der jeweiligen Elemente im gerenderten HTML stehen. Fehlen sie dort, sieht der Crawler sie nicht.
Betroffen ist dabei die fehlerhafte Umsetzung, nicht das native Lazy Loading auf Bildern. Das bleibt der empfohlene Weg, nur eben nicht für das oberste Bild.
05 ·
Was die Seite lädt, ohne gebraucht zu werden
Die häufigste Frage lautet: Liegt es an WordPress? Das CMS-Kapitel des Web Almanac beantwortet sie in einem Satz:
“Even within a single CMS, sites range from highly optimized to severely bloated, underscoring that performance is an ongoing practice, not a built-in guarantee.”
Dieselbe Passage fasst zusammen, dass “implementation decisions often matter more than platform defaults”. Praktisch heißt das: Der Abstand zwischen der bestgepflegten und der verwahrlosesten Seite innerhalb eines Systems fällt stärker ins Gewicht als die Systemwahl selbst. So liest das Kapitel seine eigenen Zahlen.
Damit ist auch die zweite häufige Frage beantwortet, ob ein Wechsel zu einem geschlossenen Baukasten die Lösung wäre: Aus einer Verteilung über Millionen Websites lässt sich für den Einzelfall nichts ableiten.
Plugins, Themes und Seitenbaukästen
Zu Seitenbaukästen ordnen die Kapitelautoren ein, sie erzeugten “often more complex DOM structures and larger CSS and JavaScript bundles”. Das ist eine Einschätzung, kein Messergebnis: In der abgerufenen Fassung standen weder Core-Web-Vitals-Werte noch Strukturgrößen je Baukasten. Belegt ist daneben, dass Google große DOM-Strukturen als Ursache für schlechte Reaktionsfähigkeit nennt.
Zur Plugin-Anzahl kursiert die These, nicht die Menge zähle, sondern die Qualität. Sie ist plausibel, denn ein Plugin, das im Frontend nichts lädt, kann die Ladezeit nicht beeinflussen.
Belegt ist die These nicht. In der Recherche zu dieser Lektion fand sich keine unabhängige Untersuchung, die sie stützt, und keine, die eine Obergrenze nennt. Alle Fundstellen waren Hoster, Plugin-Anbieter oder Ratgeberseiten mit Provisionsmodell.
Für dich heißt das: deaktivierte Plugins löschen und prüfen, welche Erweiterungen auf jeder Seite laden, obwohl sie nur auf einer gebraucht werden. Ein Formular-Plugin, das seine Skripte überall einbindet, ist der Standardfall.
Schriften
87 Prozent der mobilen Seiten nutzen mindestens eine Web-Schrift. Googles Leitfaden zu Schriften, Stand Oktober 2022 und damit keine frische Empfehlung, beschreibt drei Ladestrategien und nennt bei jeder den Preis: Die schnellste zeigt die Wunschschrift gar nicht, wenn sie zu spät kommt, die ausgewogene erzeugt einen sichtbaren Umsprung, die dritte hält den Text bis dahin unsichtbar.
Zwei verbreitete Aussagen deckt Googles Dokumentation nicht. Lokales Hosten ist nicht automatisch schneller, der Unterschied sei “less clear cut”. Der datenschutzrechtliche Grund, Schriften in Deutschland selbst auszuliefern, bleibt davon unberührt und gültig, das sind zwei verschiedene Fragen.
Eine Höchstzahl an Schriftarten nennt die Seite ebenfalls nicht. Wer “maximal zwei Schriften” empfiehlt, gibt eine Designempfehlung, und die gehört ins Designsystem für Websites statt in eine Performance-Liste.
Consent-Banner und Tracking
Beim Einwilligungs-Banner lautet die verbreitete Behauptung, es ruiniere die Ladezeit. Google sagt wörtlich das Gegenteil: “Most cookie consent notices are fairly small and therefore typically don’t contain a page’s LCP element.” Bei textlastigen Bannern auf Mobilgeräten kann es vorkommen, der Regelfall ist es nicht.
Für die beiden anderen Metriken bestätigt Google den Einfluss sehr wohl. Banner seien oft eine Ursache für schlechte Reaktionsfähigkeit, weil der Klick auf “Akzeptieren” viele fremde Skripte auf einmal nachlädt. Zu den Layoutsprüngen heißt es: “Cookie consent notices are a very common source of layout shifts.”
Daraus folgt keine technische, sondern eine Einkaufsentscheidung. Fremd eingebundene Banner haben laut Google in der Regel mehr Einfluss auf die Performance als selbst gebaute. Google ordnet das ausdrücklich ein: Ursache sind Drittanbieter-Skripte allgemein, nicht etwas, das nur Consent-Banner beträfe.
Wie viel Skript dein Anbieter lädt und ob sein Banner den Inhalt verschiebt oder überlagert, kannst du selbst prüfen.
Für Tracking gilt dasselbe Muster.
Mindestens 90 Prozent aller Seiten binden mindestens eine Drittanbieter-Ressource ein, am häufigsten Google-Dienste und Facebook. Wie viel ein einzelnes Tracking-Werkzeug kostet, ließ sich auf keine Quelle mit nachvollziehbarer Methodik zurückführen, deshalb steht hier keine Zahl. Ein Tag Manager mit vierzig Tags, von denen fünf noch benutzt werden, bleibt trotzdem ein Problem, das du ohne Entwickler löst.
06 ·
Server, Caching und die Hosting-Frage
Der größte Zeitblock aus Sektion 01 ist die Server-Antwortzeit, gemessen als Time to First Byte. Gut sind laut Google 0,8 Sekunden oder weniger, schlecht mehr als 1,8 Sekunden. Dann folgt ein Satz, den fast niemand mitzitiert:
“Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold”
Die Server-Antwortzeit ist also ein Diagnosewert, keine Zielgröße, ähnlich wie der Punktwert aus dem Labortest. Sie sagt dir, wo du suchen musst, sie ist nichts, was du grün bekommen musst.
Die Verteilung relativiert zusätzlich. Laut Web Almanac 2025 haben auf Mobilgeräten 44 Prozent der Seiten einen guten Wert, 40 Prozent einen verbesserungswürdigen und 17 Prozent einen schlechten.
Wer ein Server-Problem hat, gehört zu den unteren 17 Prozent, und genau dann lohnt ein Wechsel. Für alle anderen ist er, das ist unsere Einordnung und keine Aussage des Web Almanac, die teuerste Maßnahme mit dem geringsten Ertrag.
Dazu eine Vorbemerkung zur Quellenlage: Praktisch alles zu Hosting stammt von Hostern, von Anbietern von Caching-Plugins oder von Seiten mit Hosting-Provisionen. Selbst der seriöseste verfügbare Vergleichstest legt offen, dass er von einigen getesteten Firmen für vermittelte Kunden vergütet wird. Deshalb steht hier kein Anbietername und keine Rangliste, sondern eine Diagnose, die du selbst führen kannst.
| Beobachtung | Spricht eher für |
|---|---|
| Antwortzeit dauerhaft über 1,8 Sekunden, auch auf einer schlichten Seite wie dem Impressum | Hosting oder Server |
| Startseite langsam, Impressum schnell | die Seite selbst: Plugins, Abfragen, Baukasten |
| Werte zu Stoßzeiten deutlich schlechter | Ressourcengrenze beim Anbieter |
| Aus dem Ausland viel schlechter als aus Deutschland | fehlendes CDN |
| Ladeerlebnis schlecht, Antwortzeit aber gut | Bilder, Skripte, Ladereihenfolge, nicht das Hosting |
Die letzte Zeile verhindert die teuerste Fehlentscheidung in diesem Feld: einen Umzug gegen ein Problem, das gar nicht beim Anbieter liegt.
Googles Reihenfolge für die Server-Antwortzeit beginnt mit dem Hosting, dann CDN, gecachte Inhalte und die Vermeidung mehrfacher Weiterleitungen. Der letzte Punkt wird am häufigsten übersehen: Jede Kette aus alter Adresse, HTTPS- und www-Variante kostet Zeit und ist ein typisches Relikt aus einem früheren Relaunch.
Zum Caching hat Google zwei Sätze, die zusammengehören. Der erste lobt es: Schon kurze Cache-Zeiten brächten spürbare Gewinne, weil nur der erste Besucher die volle Wartezeit erlebt. Der zweite schränkt ein:
“Caching is great, but it can mask a slow backend making diagnosing long TTFBs harder.”
Damit ist ein Phänomen erklärt, das viele erleben und selten einordnen können: Nach der Installation eines Caching-Plugins wird der Messwert schlagartig besser, obwohl sich am eigentlichen Problem nichts geändert hat. Für eine Unternehmenswebsite ist ein solches Plugin trotzdem meist die günstigste wirksame Maßnahme, nur eben kein Ersatz für die Diagnose. Für eingeloggte Nutzer, Warenkörbe und Formularseiten greift es ohnehin meist nicht.
Im Gespräch mit dem Anbieter reichen drei Fragen:
- Welche PHP-Version läuft auf meinem Paket, und ist ein Objekt-Cache aktiv?
- Liegt mein Server in Deutschland oder der EU, und liefert ihr über HTTP/2 oder HTTP/3 aus?
- Ab welcher Besucherzahl greifen Ressourcengrenzen, und was passiert dann?
Die Antworten musst du technisch nicht bewerten können. Schon ob und wie geantwortet wird, ist die Information.
07 ·
Was beim Optimieren kaputtgehen kann
Fast jede Anleitung sagt, was man tun soll. Kaum eine sagt, was dabei kaputtgehen kann: Die Seite ist nach dem Optimierungs-Wochenende schneller, und das Kontaktformular geht nicht mehr.
Der erste Fall steht schon in Sektion 04, das falsch gesetzte Lazy Loading. Drei weitere kommen hinzu, bei zwei davon warnt Google selbst.
Aggressive Minifizierung. Leerzeichen und Kommentare zu entfernen, ist harmlos. Für die weitergehenden Varianten schreibt Google: “such advanced CSS optimizations can be risky, and may not work or scale well with all CSS approaches or design systems.” Das Problem: In den Plugins sitzen beide Stufen hinter demselben Schalter, und den Unterschied siehst du nicht.
Ungenutztes CSS entfernen. Auch hier dämpft Google deutlich: “it may not be possible to completely eliminate unused CSS—nor should you expect to.” Ein bleibender roter Punkt in der Prüfliste ist also kein Versagen. Der eigentliche Fallstrick ist als Einordnung zu lesen: Solche Werkzeuge sehen nur den gerade geladenen Zustand der Seite. Regeln für ein aufgeklapptes Menü, eine Fehlermeldung im Formular oder einen gefüllten Warenkorb gelten dann als ungenutzt und fliegen raus.
Alles auf asynchron stellen. Asynchron geladene Skripte können laut Google “execute out-of-order”, während die aufgeschobene Variante die Reihenfolge aus dem Dokument beibehält. Viele Skripte bauen aufeinander auf. Kippt die Reihenfolge, funktioniert der Slider, das Menü oder das Formular nicht mehr, und niemand verbindet das mit der Optimierung von vorletzter Woche.
Der beste Beleg für das Schadenspotenzial steht in der Dokumentation eines Optimierungs-Plugins selbst. Der Hersteller warnt davor, sein Produkt parallel zu anderen Minifizierungs-Plugins zu betreiben, und seine Hilfeseite hat zwei Einträge, die für sich sprechen: einen zur weißen Seite nach der Aktivierung, einen dazu, dass Seitenbaukästen danach kaputt sind. Eine Warnung gegen das eigene Verkaufsinteresse ist ungewöhnlich glaubwürdig.
💡 Praxis-Tipp
Sechs Regeln für einen Optimierungsdurchgang. Erstens: vorher ein Backup, nicht verhandelbar. Zweitens: eine Einstellung nach der anderen einschalten, sonst weißt du im Schadensfall nicht, welche es war.
Drittens: nach jeder Änderung die drei wichtigsten Wege durchklicken, also Formular absenden, Menü auf dem Handy öffnen, eine Unterseite aufrufen. Viertens: im privaten Fenster testen, denn viele dieser Plugins sind für eingeloggte Nutzer abgeschaltet, sodass gerade du den Schaden nicht siehst.
Fünftens: eine Woche später noch einmal hinsehen. Sechstens: nicht messen, während du arbeitest, die Felddaten brauchen bis zu vier Wochen. Was danach als Dauerthema bleibt, steht in Lektion zur Website-Wartung.
08 ·
Der ehrliche Erwartungshorizont
Bleibt die Frage, die dich am meisten interessiert: Was bringt das alles? Die ehrliche Antwort ist unbefriedigend, und sie ist selbst ein Lerninhalt.
Wie viel ein vertretbarer Optimierungsdurchgang bei einer typischen Website insgesamt bringt, ist nicht belegt. Was kursiert, sind Einzelfälle von Agenturen, Plugin-Anbietern und Hostern nach dem Muster “von acht auf 1,2 Sekunden”, durchgehend ohne Ausgangslage und ohne Auskunft darüber, ob die Seite danach noch dasselbe konnte wie vorher.
Deshalb steht hier keine Prozentzahl und keine Sekundenangabe. Wer eine nennt, ohne die Ausgangslage seiner Referenzseite zu kennen, verkauft eine Erwartung, die er nicht decken kann.
Was es stattdessen gibt, ist ein Maßstab. Laut Web Almanac 2025 bestehen 48 Prozent der Ursprünge auf Mobilgeräten alle drei Core Web Vitals, auf dem Desktop 56 Prozent, bei WordPress-Ursprüngen sind es 45 Prozent auf Mobil.
Gezählt wird dabei je Website-Ursprung, nicht je Seite: eine große und eine kleine Website zählen gleich. Und der Abstand zwischen den Systemen sagt nichts über Ursache und Wirkung.
Der WordPress-Wert hat sich gegenüber 2024 um rund vier Prozentpunkte verbessert. Und das Performance-Kapitel derselben Ausgabe beschreibt die mobile Entwicklung als stetige Verbesserung von Jahr zu Jahr.
Das Web bewegt sich also in Prozentpunkten, nicht in Sprüngen. Eine Seite im grünen Bereich ist keine Selbstverständlichkeit, sondern gehört zur besseren Hälfte.
Ein Teil dieser Verbesserung ist außerdem nicht deine Arbeit.
Geräte werden schneller, Mobilfunknetze besser, Browser effizienter. Was du nach einem Optimierungsdurchgang in den Felddaten siehst, wäre in Teilen auch ohne dich passiert, denn eine Kontrollgruppe gibt es nicht.
Das ist eine Einordnung, kein gemessener Befund. Derselbe methodische Punkt kommt bei Vorher-Nachher-Vergleichen in der Conversion-Optimierung wieder.
Experten-Tipp aus der Agentur
Wenn dir jemand eine Optimierung mit einer Zahl verkauft, stell drei Rückfragen: Wie sah die Referenzseite vorher aus, was genau wurde gemacht, und sind das Feld- oder Labordaten?
Wer darauf keine Antwort hat, hat eine Anekdote verkauft und keine Erfahrung. Und wer eine schnelle Komplettlösung per Plugin verspricht, verspricht etwas, das Google selbst für selten hält: “It’s rare that a quick fix to a single part of a page will result in a meaningful improvement to LCP.”
Lass dir außerdem sagen, welcher der drei Werte verbessert werden soll und auf welchem Gerätetyp. Ohne diese Angabe ist ein Angebot nicht vergleichbar.
Pascal Cabitza
Geschäftsführer Ostend Digital
Wo ohne Umbau Schluss ist
Manche Engpässe lassen sich nicht nachoptimieren, weil sie die Bauweise selbst sind.
Eine tief verschachtelte Seitenstruktur aus einem Baukasten ist kein Ballast, den man abräumt. Ein Theme, das sein gesamtes CSS und JavaScript auf jeder Seite lädt, lässt sich nicht per Plugin entflechten. Und ein Bildbestand aus zehn Jahren ist zwar lösbar, aber der Aufwand wächst mit jedem Bild.
Daraus folgt eine Entscheidungsregel, und die Bedingung davor ist der wichtige Teil: Wenn nach den Schritten 1 bis 5 aus Sektion 02, also nach allem, was ohne Umbau geht, die Werte immer noch deutlich im roten Bereich liegen, ist die nächste sinnvolle Ausgabe kein weiteres Optimierungs-Budget, sondern ein Gespräch über die Bauweise. Dauerhaft dafür zu bezahlen, ein strukturelles Problem zu verwalten, ist die teuerste aller Varianten.
💡 Merke
Ein realistisches Ziel sind grüne Felddaten, keine perfekte Punktzahl. Und auch nicht “überall grün um jeden Preis”: Wenn dafür das Formular kaputtgeht oder Inhalte vor Google verschwinden, war es keine Verbesserung.
Das schnellere Zwischenziel ist ein anderer Blick. Weg von “wie schnell bin ich”, hin zu “was lädt diese Seite, was sie nicht braucht”.
Diese Frage beantwortest du ohne Werkzeug und ohne Dienstleister, und sie führt fast immer zu einer Maßnahme aus Schritt 1.
09 ·
💡 Recap
Website optimieren in 30 Sekunden:
- Die übliche Startmaßnahme setzt am kleinsten Block an. Google schreibt, die Ladedauer der LCP-Ressource sei bei den meisten Seiten nicht der Engpass, und in den Felddaten ist sie der kleinste der vier Blöcke. Bilder bleiben trotzdem wichtig, auf 76 Prozent der mobilen Seiten sind sie das größte Element
- Die Reihenfolge in dieser Lektion ist eine Empfehlung, keine Google-Vorgabe. Google selbst rät, in die eigenen Felddaten zu sehen, bevor man entscheidet
- Prüf bei jeder Prozentzahl die Herkunft. Die verbreitete WebP-Angabe stammt aus einer Google-Studie gegen einen Referenzencoder aus den 1990er Jahren, Mozilla kam mit dem eigenen Encoder zu einem “inconclusive” Ergebnis. Beide Seiten sind Partei
- Lazy Loading gehört unter den Falz, nie auf das Titelbild. Falsch umgesetzt kann es außerdem Inhalte vor Google verstecken, weil der Crawler nicht scrollt und nicht klickt
- Beim Consent-Banner bleibt Google differenziert: belegt ist der Einfluss auf Reaktionsfähigkeit und Layoutsprünge, beim Ladeerlebnis seien Banner typischerweise nicht das größte Element
- Für den Gesamtertrag eines Optimierungsdurchgangs gibt es keine belastbare Untersuchung. Als Maßstab bleibt die Verteilung im Web. Und weil es keine Kontrollgruppe gibt, lässt sich ein Teil der Verbesserung ohnehin nicht sauber der eigenen Arbeit zuschreiben: Geräte, Netze und Browser werden auch ohne dich schneller. Das ist eine Einordnung, kein gemessener Befund
10 ·
Selbstcheck: kannst du das beantworten?
Ein Dienstleister schlägt als erste Maßnahme vor, alle Bilder zu komprimieren. Was fragst du zurück?
Wie die Ausgangswerte aussehen, und zwar getrennt nach Server-Antwortzeit und Bildern. Google schreibt, die Ladedauer der LCP-Ressource sei bei den meisten Seiten nicht der Engpass, und empfiehlt unmittelbar danach den Blick in die eigenen Felddaten.
Das heißt nicht, dass der Vorschlag falsch ist. Es heißt, dass er ohne Messung an der Stelle ansetzt, die im Schnitt am wenigsten ausmacht.
Nach dem Einschalten eines Caching-Plugins ist der Wert schlagartig gut. Ist das Problem gelöst?
Nicht zwingend. Google schreibt selbst, Caching könne ein langsames Backend verdecken und die Diagnose erschweren.
Ein Caching-Plugin ist für eine Unternehmenswebsite trotzdem meist sinnvoll und günstig. Für eingeloggte Nutzer, Warenkörbe und Formularseiten greift es aber oft nicht, und dort merkst du, ob darunter noch ein Problem liegt.
Du willst Lazy Loading aktivieren. Worauf achtest du?
Dass das oberste Bild ausgenommen bleibt. Google formuliert das ungewöhnlich absolut: Das LCP-Bild niemals verzögert laden, weil das immer eine unnötige Verzögerung erzeugt. Rund 16 bis 17 Prozent aller Seiten machen genau diesen Fehler.
Und darauf, dass Inhalte nicht erst auf Klick oder Wischen nachgeladen werden. Solche Inhalte sieht der Crawler nicht. Die Gegenprobe läuft über das URL-Prüfwerkzeug in der Search Console.
Ein Angebot verspricht “Website-Optimierung, alles inklusive” zum Festpreis. Welche zwei Dinge trennst du, bevor du zusagst?
Erstens: Welche Schritte davon hättest du selbst gehen können? Ungenutzte Plugins löschen, Bilder in der richtigen Größe hochladen, einen Slider entfernen und einen Tag Manager aufräumen brauchen keinen Dienstleister.
Zweitens: Ist der Engpass überhaupt nachoptimierbar? Wenn nach allem, was ohne Umbau geht, die Werte noch deutlich rot sind, ist das nächste Budget kein Optimierungsbudget, sondern ein Gespräch über die Bauweise.
Alle Lektionen des Webdesign- und CRO-Kurses im Überblick →
Quellen und Stand (13 Einträge)
- web.dev, “Optimize Largest Contentful Paint” (Stand 31.03.2025, abgerufen 16.08.2026) – die vierstufige Bearbeitungsreihenfolge im Wortlaut; das Zitat “tends not to be a significant bottleneck for most sites” samt Empfehlung, die eigenen Felddaten heranzuziehen; “never lazy-load your LCP image”; Warnung vor synchronen Skripten im Head; “It’s rare that a quick fix …”. Quellentyp: Herstellerdokumentation (Chrome-Team)
- The Web Almanac by HTTP Archive, Ausgabe 2024, Kapitel “Performance” (abgerufen 16.08.2026) – die vier LCP-Bestandteile im 75. Perzentil, Abbildung 9.10, Datenbasis CrUX. Quellentyp: unabhängige Branchenauswertung. Einschränkung: eigenständige Perzentilwerte verschiedener Verteilungen, nicht addierbar. Die Werte sind als Stand 2024 gekennzeichnet, weil die Ausgabe 2025 die Tabelle nicht wiederholt, die Richtung aber bestätigt
- The Web Almanac by HTTP Archive, Ausgabe 2025, Kapitel “Performance” (Messmonat Juli 2025, abgerufen 16.08.2026) – Bildanteil am LCP-Element (76,0 Prozent mobil, 85,3 Prozent Desktop); 16 bis 17 Prozent der Seiten mit verzögert geladenem LCP-Bild; 62 Prozent der mobilen Seiten ohne Maßangaben bei mindestens einem Bild; 87 Prozent mit mindestens einer Web-Schrift; TTFB-Verteilung mobil 44 / 40 / 17 Prozent; 48 Prozent mobil und 56 Prozent Desktop mit guten Core Web Vitals
- The Web Almanac by HTTP Archive, Ausgabe 2025, Kapitel “CMS” (veröffentlicht 15.01.2026, abgerufen 16.08.2026) – 45 Prozent der WordPress-Ursprünge mit guten Core Web Vitals auf Mobil, Verbesserung um rund vier Prozentpunkte; die Zitate “Even within a single CMS …” und “implementation decisions often matter more than platform defaults”; die Einschätzung zu Seitenbaukästen. Einschränkung: Origin-Anteile, kein Kausalzusammenhang; die Baukasten-Aussage ist eine Einschätzung der Kapitelautoren, kein ausgewiesenes Messergebnis
- web.dev, “Optimize Interaction to Next Paint” (Stand 02.09.2025, abgerufen 16.08.2026): große DOM-Strukturen als Ursache schlechter Reaktionsfähigkeit. Quellentyp: Herstellerdokumentation.
- The Web Almanac by HTTP Archive, Ausgabe 2025, Kapitel “Third Parties” (abgerufen 16.08.2026) – mindestens 90 Prozent der Seiten mit mindestens einer Drittanbieter-Ressource, häufigste Hosts. Einschränkung: das Kapitel weist keine Messung des Einflusses auf die Core Web Vitals aus, nur Verbreitung
- Google for Developers, “WebP Compression Study” (abgerufen 16.08.2026) und web.dev, “Use WebP images” (Seitenstand 05.11.2018) – die Angabe von 25 bis 34 beziehungsweise 25 bis 35 Prozent kleineren Dateien; Vergleichsencoder cjpeg aus libjpeg 6b. Quellentyp: Herstellerdokumentation des Formatanbieters, Google ist Entwickler von WebP und damit Partei
- Mozilla Research, “Studying Lossy Image Compression Efficiency” (17.10.2013, abgerufen 16.08.2026) – Ergebnis “inconclusive”, besser nach einigen Bewertungsalgorithmen, ähnlich oder schlechter nach anderen. Quellentyp: Gegenpartei mit Eigeninteresse, Mozilla entwickelte zeitgleich den konkurrierenden Encoder mozjpeg
- web.dev, “Image performance” (Stand 01.11.2023) und Chrome for Developers, “Improve image delivery” (Stand 08.10.2025), beide abgerufen 16.08.2026 – die Ansätze zu Maßen, Formaten, Kompression und Lazy Loading ohne ausdrückliche Rangfolge; Zitat zu den Kosten zusätzlicher Bildvarianten; Nennung von Squoosh, ImageOptim und Imagemin
- web.dev, “Browser-level image lazy loading” (Stand 13.08.2024) und Google Search Central, “Fix lazy-loaded content” (Stand 10.12.2025 UTC), beide abgerufen 16.08.2026 – Chrome-Messwerte 97,5 Prozent und 92,6 Prozent; “this technique can inadvertently hide content from Google”; “Google Search does not interact with your page”; die Prüfung über das URL-Prüfwerkzeug
- web.dev, “Best practices for cookie notices” (Stand 13.06.2024) und “Best practices for fonts” (Stand 04.10.2022), beide abgerufen 16.08.2026 – die Zitate zu Consent-Bannern bei Ladeerlebnis, Reaktionsfähigkeit, Layoutsprüngen und Drittanbieter-Bannern; die drei Schriftstrategien mit ihrem jeweiligen Preis; “less clear cut” zum lokalen Hosten. Altershinweis: die Schriftenseite ist von 2022 und nicht als aktuelle Empfehlung 2026 zu lesen. Zur Höchstzahl an Schriftarten trifft sie keine Aussage
- web.dev, “Time to First Byte” und “Optimize Time to First Byte” (beide Stand 28.11.2025, abgerufen 16.08.2026) – Schwellen 0,8 und 1,8 Sekunden; das Zitat “Because TTFB isn’t a Core Web Vitals metric …”; die siebenstufige Reihenfolge beginnend mit Hosting; die beiden Caching-Zitate
- web.dev, “Optimize resource loading” (Stand 01.11.2023, abgerufen 16.08.2026) – Warnung vor fortgeschrittener CSS-Optimierung; “nor should you expect to” zu ungenutztem CSS; Unterschied zwischen asynchroner und aufgeschobener Skriptausführung. Sowie: Make WordPress Core, “WordPress 6.5 adds AVIF support” (23.02.2024) zum Upload ab Version 5.8 beziehungsweise 6.5, zur fehlenden Umwandlung des Bestands und zur Abhängigkeit von der Bildbibliothek des Servers; WordPress.org Plugin-Verzeichnis, “Autoptimize” (abgerufen 16.08.2026) mit den Warnungen des Herstellers vor dem Parallelbetrieb und den beiden Hilfe-Einträgen. Nicht verwendet wurden sämtliche Vorher-Nachher-Fallstudien, Baukasten-Vergleichstests von Anbietern und die kursierenden Ladezeit-gegen-Conversion-Prozentwerte, weil keiner davon auf eine Originalstudie mit Methodik zurückführbar war
Optimiert, und trotzdem bleibt der Wert rot?
Wir messen zuerst, sagen dir dann, welcher Block bei dir die Zeit frisst, und trennen ehrlich zwischen dem, was du selbst erledigst, und dem, wofür sich ein Auftrag lohnt.
