Blog
Zwei Sekunden entscheiden
Was Ladezeit mit Anfragen zu tun hat, wo sie tatsächlich verloren geht — und warum die Ursache fast immer bei den Bildern liegt.
Niemand wartet freiwillig. Wer über die Google-Suche auf einer Seite landet, hat den Zurück-Knopf immer in Reichweite — und benutzt ihn, lange bevor er sich über die Wartezeit ärgert. Der Absprung passiert unbewusst.
Das ist der unangenehme Teil an diesem Thema: Sie sehen ihn nicht. Ein Besucher, der eine Anfrage abbricht, hinterlässt eine Notiz im Kontaktformular. Ein Besucher, der nie ankommt, hinterlässt gar nichts. Ladezeit ist der einzige Mangel einer Website, über den sich niemand beschwert.
Wo die Zeit verloren geht
In den allermeisten Fällen an drei Stellen, und in dieser Reihenfolge:
- Bilder, die um ein Vielfaches größer geliefert werden, als sie dargestellt werden
- Schriften und Skripte von fremden Servern, auf deren Geschwindigkeit niemand Einfluss hat
- der Server selbst, der bei jedem Aufruf mehr Arbeit leistet als nötig
Die gute Nachricht: Der erste Punkt ist meist der größte und fast immer der billigste. Die Reihenfolge ist keine Rangliste der Wichtigkeit, sondern eine der Wirtschaftlichkeit — und am Ende dieses Beitrags steht sie noch einmal als Tabelle, mit Aufwand und Wirkung nebeneinander.
Messen statt schätzen
Ein Gefühl reicht nicht, denn die eigene Seite lädt beim zehnten Aufruf immer schnell. Ihr Browser hat die Bilder längst gespeichert, Ihr Rechner steht am schnellen Anschluss, und Ihre Erwartung kennt jede Zeile. Verlässlich ist nur eine Messung von außen, mit gedrosselter Verbindung und geleertem Zwischenspeicher.
Eine Seite, die sich auf Ihrem Rechner schnell anfühlt, sagt über Ihre Besucher genau nichts aus.
Dafür braucht es keine Agentur und keinen Vertrag. Vier Werkzeuge genügen, und alle vier sind kostenlos:
- PageSpeed Insights — Adresse eintragen, Knopf drücken. Der schnellste Einstieg, und der einzige, der Labor- und echte Nutzerdaten auf derselben Seite zeigt.
- WebPageTest — für den zweiten Blick. Hier wählen Sie Standort, Gerät und Verbindung und bekommen ein Wasserfalldiagramm: eine Zeile pro geladener Datei, chronologisch. Wer die langen Balken sucht, findet die Ursache in zwei Minuten.
- Lighthouse in den Chrome-Entwicklerwerkzeugen — dieselbe Prüfung wie PageSpeed Insights, aber auf Ihrem Rechner. Wichtig für Seiten, die noch nicht öffentlich sind, und für alle, die ihre Adresse ungern in ein fremdes Formular tippen.
- Der CrUX-Bericht — die Messwerte echter Chrome-Nutzer der letzten 28 Tage. Kein Test, sondern Beobachtung. Nur für Seiten mit genügend Verkehr verfügbar.
Labor und Wirklichkeit sind zwei Zahlen
Die beiden Arten von Messung werden regelmäßig verwechselt, und aus dieser Verwechslung entstehen die meisten sinnlosen Diskussionen. Labordaten sind eine Simulation: ein Rechenzentrum irgendwo, ein simuliertes Mittelklasse-Telefon, eine künstlich gedrosselte Leitung. Sie sind reproduzierbar und damit ideal, um eine Verbesserung nachzuweisen. Felddaten stammen von Ihren tatsächlichen Besuchern, mit deren Geräten, an deren Anschlüssen. Sie sind das ehrlichere Bild und reagieren erst nach Wochen auf eine Änderung.
Widersprechen sich beide, hat meistens das Feld recht.
Die Zahl 100 ist kein Ziel
Am Ende jeder Prüfung steht ein Wert zwischen 0 und 100, und dieser Wert ist der gefährlichste Teil des ganzen Berichts — weil er aussieht wie eine Schulnote. Er ist keine. Er ist eine gewichtete Zusammenfassung mehrerer Messungen, er schwankt zwischen zwei Durchläufen derselben Seite, und die letzten Punkte bis zur 100 kosten regelmäßig mehr als die ersten sechzig.
Ein realistischer Anspruch für eine Unternehmenswebsite: im grünen Bereich landen, mobil, im Feld. Wer stattdessen die 100 jagt, optimiert irgendwann Dinge weg, die der Seite gutgetan haben.
Drei Fragen, die Ihre Besucher stellen
Die Werkzeuge oben antworten in Abkürzungen — LCP, INP, CLS. Dahinter stehen drei Fragen, die jeder Besucher stellt, ohne sie je auszusprechen.
Wann sehe ich das Wichtigste? Das ist der Largest Contentful Paint: der Moment, in dem das größte Element im sichtbaren Bereich fertig ist — meist das Kopfbild oder die Überschrift. Nicht der erste Pixel, sondern der erste brauchbare Eindruck. Gut sind weniger als 2 Sekunden, exzellent wäre alles unter 1 Sekunde.
Reagiert die Seite, wenn ich etwas tue? Das ist die Interaction to Next Paint: die Zeit zwischen Ihrem Tippen und dem Moment, in dem sichtbar etwas passiert. Eine Seite kann fertig geladen aussehen und trotzdem taub sein, weil im Hintergrund noch gerechnet wird. Gut sind ~200 Millisekunden.
Springt mir der Inhalt weg? Das ist der Cumulative Layout Shift — der ärgerlichste der drei, weil ihn jeder kennt und niemand benennen kann. Sie wollen auf einen Link tippen, in derselben Zehntelsekunde lädt darüber ein Bild nach, alles rutscht nach unten, und Ihr Finger trifft etwas anderes. Diese Sprünge sind fast immer vermeidbar, und wie, steht im nächsten Abschnitt.
Der dritte Wert ist der, den ich zuerst prüfe. Die ersten beiden kosten Geduld. Der dritte kostet Vertrauen.
Das Bild, das viermal zu groß ist
Die häufigste Ursache ist zugleich die banalste. Ein Foto kommt aus der Kamera oder aus einer Bilddatenbank, ist 4000 Pixel breit und wiegt 4 Megabyte. Auf der Website steht es in einer Spalte von 600 Pixeln. Der Browser lädt trotzdem alle 4 Megabyte herunter und rechnet sie anschließend klein — die Arbeit ist getan, die Wartezeit ist verbraucht, sichtbar ist davon nichts.
Dasselbe Bild, richtig aufbereitet, wiegt rund 120 Kilobyte. Das ist kein Feinschliff, das ist der Faktor dreißig. Vier Handgriffe genügen:
- Auf die tatsächliche Anzeigegröße bringen. Ein Bild, das nie größer als 800 Pixel dargestellt wird, wird nicht in 4000 Pixeln ausgeliefert. Für scharfe Darstellung auf modernen Displays rechnet man das Doppelte — mehr nicht.
- Ein modernes Format wählen. WebP und AVIF liefern dieselbe sichtbare Qualität bei einem Bruchteil der Dateigröße. Beide werden seit Jahren von allen aktuellen Browsern verstanden.
- Höhe und Breite im HTML angeben. Damit weiß der Browser, wie viel Platz er freihalten muss, bevor das Bild da ist. Genau das verhindert die Sprünge aus der dritten Frage oben.
- Bilder unterhalb des sichtbaren Bereichs später laden. Ein Attribut, eine Zeile — und alles, was erst nach dem Scrollen sichtbar wird, hält den ersten Eindruck nicht mehr auf.
Zusammen sieht das so aus:
<img src="team.webp" width="1600" height="900" alt="Unser Team" loading="lazy">
Ein Fehler dabei ist so verbreitet, dass er eine eigene Warnung verdient: Das Kopfbild bekommt kein loading="lazy". Es ist das Bild, auf das die erste der drei Fragen wartet. Wer es absichtlich nach hinten stellt, macht genau den Wert schlechter, den er verbessern wollte — und tut das mit dem guten Gefühl, etwas optimiert zu haben.
Wer ein Redaktionssystem pflegt, sollte diese vier Punkte nicht bei jedem Bild neu erledigen müssen. Ein ordentlich eingerichtetes System nimmt das hochgeladene Original entgegen und erzeugt die Ausspielgrößen selbst. Passiert das nicht, ist nicht der Redakteur das Problem, sondern die Einrichtung.
Was Sie sich nachträglich einhandeln
Bilder sind ein Handwerksfehler. Externe Skripte sind eine Entscheidung — und deshalb der Punkt, an dem schnelle Websites am zuverlässigsten wieder langsam werden.
Die Seite ging schlank live. Dann kam der Consent-Banner. Dann das Chat-Fenster, das niemand benutzt. Dann die eingebettete Karte, das Bewertungs-Siegel, ein zweites Statistikwerkzeug, weil die Agentur eigene Zahlen wollte. Jedes einzelne Stück war „nur ein Snippet", und jedes lädt von einem fremden Server, dessen Geschwindigkeit niemand in Ihrem Haus beeinflussen kann.
Drei Dinge daran sind wichtig zu wissen:
- Ein Skript wiegt mehr als seine Dateigröße. Herunterladen ist die kleinere Hälfte; danach muss der Code ausgeführt werden, und währenddessen reagiert die Seite auf nichts. Das schlägt direkt auf die zweite Frage durch — die Seite sieht fertig aus und ist es nicht.
- Consent-Werkzeuge stehen ganz vorn in der Reihe. Sie müssen laden, bevor irgendetwas anderes laden darf, denn sie entscheiden ja, was überhaupt erlaubt ist. Ein langsames Consent-Werkzeug verzögert deshalb nicht sich selbst, sondern alles.
- Schriften von fremden Servern lohnen sich nicht mehr. Der Geschwindigkeitsvorteil, den Google Fonts einmal hatte, ist durch die Trennung der Browser-Zwischenspeicher entfallen. Geblieben ist der Umweg über einen zusätzlichen Server — und ein Datenschutzproblem, das deutsche Gerichte bereits beschäftigt hat. Schriften gehören auf den eigenen Server. Das ist der seltene Fall, in dem schneller und rechtssicherer dieselbe Maßnahme sind.
Der Umgang damit ist keine Technik, sondern eine Hausordnung: Jedes externe Skript hat einen Eigentümer und einen Zweck, den jemand benennen kann. Fragen Sie einmal im Jahr für jedes einzelne, wer die Zahlen daraus tatsächlich liest. Erfahrungsgemäß überlebt diese Frage etwa die Hälfte.
Lange Server-Antwortzeiten: Warum Caching oft die wichtigste Maßnahme ist
Bleibt die dritte Baustelle, und sie ist die, über die am meisten geredet und am seltensten sinnvoll entschieden wird. Wenn zwischen dem Aufruf und dem ersten Byte mehr als eine halbe Sekunde vergeht, arbeitet der Server bei jedem einzelnen Besuch die immer gleiche Seite neu aus. Ein Zwischenspeicher, der das fertige Ergebnis eine Weile aufhebt, ist dann die wirksamste Einzelmaßnahme überhaupt — und meist eine Einstellung, kein Umbau.
Der Standort zählt ebenfalls: Ein Server in Deutschland antwortet deutschen Besuchern schneller als einer in Übersee, und die Wege addieren sich über jede geladene Datei.
Trotzdem steht dieser Punkt zu Recht am Ende. Ein Umzug ist ein Projekt mit Risiko, Termin und Nacharbeit. Solange die Startseite 6 Megabyte Bilder ausliefert, ist er die teuerste Art, ein billiges Problem nicht zu lösen.
Was an einem Nachmittag geht
Nicht alles lohnt sich gleich schnell. Die ehrliche Reihenfolge:
| Maßnahme | Aufwand | Wirkung |
|---|---|---|
| Die zehn größten Bilder ersetzen | ein Nachmittag | am größten, fast immer |
| Höhe und Breite bei Bildern ergänzen | ein bis zwei Stunden | die Sprünge sind weg |
| Schriften selbst ausliefern | ein bis zwei Stunden | spürbar, plus Datenschutz |
| Nicht genutzte Skripte entfernen | eine Besprechung | oft überraschend groß |
| Zwischenspeicher einschalten | eine Einstellung | groß bei trägem Server |
| Umzug auf besseres Hosting | ein Projekt | zuletzt, wenn der Rest steht |
Die ersten beiden Zeilen erledigen in der Praxis den Großteil des Abstands zwischen Rot und Grün. Sie brauchen keinen Relaunch, keine neue Technik und niemanden, der die Website neu baut.
Sechs Fragen an Ihre eigene Website
| Prüfen Sie | Woran Sie es erkennen |
|---|---|
| Die Messung | liegt ein Ergebnis für mobil vor, nicht nur für die Desktop-Auflösung? |
| Das schwerste Bild | wie groß ist die größte Bilddatei Ihrer Startseite — und wie breit wird sie gezeigt? |
| Die Sprünge | bleibt beim Laden alles an seinem Platz, oder rutscht der Text nach unten? |
| Das Kopfbild | lädt es sofort — oder steht dort versehentlich loading="lazy"? |
| Fremde Server | wie viele Dienste lädt Ihre Seite, und wer liest deren Zahlen? |
| Die Antwortzeit | vergeht bis zum ersten Byte mehr als eine halbe Sekunde? |
Sechs Antworten, eine Viertelstunde. Wo dreimal ein Nein steht, liegt das Problem selten in der Technik und meistens in der Pflege — und das ist die gute Nachricht, denn Pflege lässt sich nachholen, ohne die Website neu zu bauen.
Der Maßstab bleibt derselbe
Schnelligkeit ist kein Selbstzweck und schon gar kein Wettbewerb um Punktzahlen. Sie ist die Bedingung dafür, dass alles andere überhaupt gelesen wird: der Text, das Angebot, die Referenz, der Weg zum Kontaktformular. Eine Seite, die niemand abwartet, hat kein Inhaltsproblem und kein Designproblem. Sie hat gar keins mehr, weil sie niemanden erreicht.
Wenn Sie wissen möchten, wo Ihre Seite tatsächlich steht, messen wir sie gemeinsam durch — das Erstgespräch kostet nichts.