Core Web Vitals verbessern bei einer bildlastigen Unternehmensseite

Stellen wir uns einen Betrieb vor, der seine Arbeit zeigen muss: ein Innenausbauer, ein Fotostudio, eine Praxis mit Räumen, die überzeugen sollen. Die Website enthält ein großflächiges Titelbild, zwölf Referenzfotos, ein eingebettetes Video, einen Kartenausschnitt, ein Buchungswidget und ein Cookie-Banner. Jedes dieser Elemente ist für sich nachvollziehbar. Zusammen ergeben sie eine Seite, die auf dem Entwicklerrechner flüssig wirkt und auf einem drei Jahre alten Mittelklasse-Smartphone im Mobilfunknetz spürbar hakt.

Das ist ein typisches Ausgangsbild, keine Einzelfallbeschreibung. Wer die Seite am Büro-PC mit Glasfaser prüft, sieht das Problem nicht. Wer sie in der Bahn öffnet, wartet auf das Titelbild, sieht Text springen, tippt auf ein Menü und erlebt eine Verzögerung. Dieses Erlebnis ist der eigentliche Gegenstand von Core Web Vitals: Google fasst es in drei Kennzahlen, die Laden, Reaktion und visuelle Stabilität beschreiben.

Die Fachanalyse beschreibt, wie wir ein solches Ausgangsbild untersuchen und ordnen würden. Sie enthält keine Messreihen eines Kunden und keine Versprechen über Platzierungen. Sie zeigt Mechanismen, Abwägungen und eine Reihenfolge, die sich auf viele bildlastige Seiten übertragen lässt.

Wichtig ist uns dabei eine nüchterne Haltung. Geschwindigkeit ist kein Selbstzweck, und nicht jede Seite muss jede Schwelle erreichen. Ein Betrieb mit zwanzig Besuchern am Tag hat andere Prioritäten als ein Portal mit Tausenden. Wir fragen zuerst, ob Besucher heute an der Ladezeit scheitern, und erst danach, wie viel Aufwand sich dafür lohnt. Manchmal lautet die Antwort, dass drei gezielte Eingriffe genügen und der Rest Geschmackssache ist.

Core Web Vitals bestehen aus drei Größen. Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element im Erstansichtsbereich fertig gezeichnet ist, meist das Titelbild oder eine große Überschrift; als gut gilt ein Wert bis 2,5 Sekunden. Die Interaction to Next Paint (INP) beschreibt, wie schnell die Seite nach einer Eingabe sichtbar reagiert; gut ist ein Wert bis 200 Millisekunden. Der Cumulative Layout Shift (CLS) addiert unerwartete Verschiebungen des Layouts; gut ist ein Wert bis 0,1.

Bei bildlastigen Seiten treffen mehrere Ursachen zusammen. Das Titelbild ist als Rohexport hochgeladen und wiegt mehrere Megabyte. Webfonts werden spät geladen, der Text erscheint zunächst in einer Ersatzschrift und springt dann. Third-Party-Skripte für Tracking, Karten, Chat und Buchung konkurrieren um dieselbe Leitung und denselben Hauptthread. Das Cookie-Banner schiebt nachträglich Inhalt nach unten oder verdeckt genau das Element, das als LCP zählt.

Dazu kommt die Frontend-Last: Wer ein Framework einsetzt, schickt oft mehr JavaScript, als die Seite zum Lesen braucht. Der Browser muss es laden, parsen und ausführen, bevor Menüs und Formulare zuverlässig reagieren. Diese Hydration-Phase ist eine häufige, aber selten erkannte Ursache für schlechte INP-Werte.

Hinzu kommt, dass sich die Ursachen gegenseitig verstärken. Ein schweres Titelbild belegt die Leitung, während Skripte parallel Bandbreite und Rechenzeit beanspruchen. Ein Schriftwechsel, der allein kaum auffiele, summiert sich mit einem nachladenden Banner zu einem spürbaren Sprung. Deshalb führt die Behebung eines einzelnen Punkts selten zum Durchbruch, während drei kleine Eingriffe an der richtigen Stelle oft mehr bewirken als ein großer Umbau.

Der häufigste Fehler beginnt mit einem einzelnen Lighthouse-Lauf. Lighthouse und der Laborteil von PageSpeed Insights simulieren einen Seitenaufruf unter festgelegten Bedingungen. Das ist wertvoll, weil man Änderungen reproduzierbar vergleichen kann. Es ist aber ein Modell: Gerät, Netz und Standort sind angenommen, und eine echte Interaktion findet nicht statt. Ein Laborwert für INP existiert deshalb nicht in derselben Weise, stellvertretend dient die Total Blocking Time.

Felddaten stammen von echten Besuchern. Der Chrome User Experience Report (CrUX) sammelt sie, die Search Console zeigt sie getrennt nach Mobil und Desktop und gruppiert URLs mit ähnlichem Aufbau. Für die Bewertung der Core Web Vitals zählt dieses Feldbild, und zwar über einen rollierenden Zeitraum von rund 28 Tagen. Das bedeutet auch: Eine Verbesserung ist nicht am nächsten Tag sichtbar.

Wir würden deshalb beide Quellen trennen. Das Feld sagt, ob ein Problem für echte Menschen existiert und auf welchen Seitentypen. Das Labor sagt, warum, und ob eine Änderung in die richtige Richtung wirkt. Kleine Seiten mit wenig Verkehr haben mitunter gar keine ausreichenden Felddaten; dann bleibt das Labor, ergänzt um eigene Messung im Browser, als vorläufige Orientierung.

Ein praktisches Beispiel: Die Startseite zeigt im Labor einen guten LCP, im Feld aber nicht. Mögliche Erklärungen sind Besucher mit langsamen Verbindungen, ein Cookie-Banner, das nur beim Erstbesuch erscheint und im Test fehlt, oder dynamische Inhalte je nach Standort. Solche Unterschiede erkennt man nur, wenn man beide Seiten ansieht und das Labor bewusst realistischer einstellt, etwa mit gedrosseltem Netz und leerem Cache.

Performance-Arbeit scheitert selten an fehlendem Wissen, sondern an fehlender Ordnung. Ein Audit liefert dreißig Hinweise, und alle wirken gleich dringend. Wir würden sie nach zwei Kriterien sortieren: Wie stark beeinflusst der Punkt eine der drei Kennzahlen auf den Seiten mit dem meisten Verkehr, und wie viel Aufwand und Risiko stecken in der Änderung?

Bilder und Auslieferung stehen fast immer vorn, weil sie große Wirkung bei überschaubarem Risiko bieten. Es folgen Fremdskripte, bei denen die Frage zählt, ob der Dienst überhaupt gebraucht wird. Danach kommen Schriften und Layout-Stabilität. Der Umbau der JavaScript-Architektur steht meist am Ende, weil er teuer ist und nur dann lohnt, wenn die günstigeren Schritte nicht ausreichen.

Als Alternative wird oft ein Plugin oder ein Performance-Dienst angeboten, der Optimierungen automatisch anwendet. Das kann bei einfachen Seiten helfen. Bei Seiten mit individuellem Aufbau fehlt es ihm allerdings an Wissen darüber, welches Bild der LCP ist und welches Skript verzichtbar. Wir würden Automatik als Werkzeug einsetzen, nicht als Strategie.

Ein Grundsatz hilft bei der Auswahl: Zuerst entfernen, dann verkleinern, dann verschieben, erst zuletzt beschleunigen. Ein Skript, das niemand braucht, verursacht keine Kosten mehr. Ein Bild, das kleiner sein darf, lädt schneller als jede Cache-Regel. Was nötig ist, aber nicht sofort, wandert hinter die erste Interaktion. Diese Reihenfolge spart Aufwand und führt zu Lösungen, die auch in zwei Jahren noch funktionieren.

Beim LCP geht es auf Bildseiten meist um ein einziges Element. Drei Fragen entscheiden: Wie groß ist die Datei, wann entdeckt der Browser sie, und wie lange dauert die Antwort des Servers? Ein Bild, das per CSS als Hintergrund eingebunden oder erst per JavaScript nachgeladen wird, findet der Browser spät. Als echtes Bildelement im Markup, mit hoher Priorität markiert, beginnt der Download früher.

Beim Format lohnt der Blick auf moderne Alternativen. WebP und AVIF komprimieren bei vergleichbarer Qualität deutlich besser als JPEG; AVIF braucht beim Kodieren mehr Rechenzeit, WebP ist breiter erprobt. Ein sinnvoller Weg ist, beide über ein picture-Element anzubieten und JPEG als Rückfall zu behalten. Entscheidend bleibt die Qualitätsstufe: Fotos müssen am Ende noch hochwertig wirken, und kein Metrikwert rechtfertigt matschige Referenzbilder.

Responsive Images sind der zweite Hebel. Mit srcset und sizes bekommt ein Smartphone eine Datei in passender Breite statt der Desktop-Variante. Alle Bilder unterhalb des sichtbaren Bereichs laden verzögert, das Titelbild gerade nicht: Es darf nie mit loading="lazy" versehen werden, sonst wird der LCP künstlich verzögert. Und jedes Bild erhält Breite und Höhe, damit der Browser den Platz freihält.

Auch die Motivwahl spielt hinein. Ein Foto mit viel feiner Struktur, etwa Holzmaserung oder Fliesenfugen, lässt sich schlechter komprimieren als eine ruhige Fläche. Manchmal bringt ein anderer Bildausschnitt mehr als jede Einstellung im Kodierprogramm. Für den Erstansichtsbereich lohnt es, ein Motiv zu wählen, das auf kleinen Bildschirmen wirkt und nicht nur im Breitformat; so entsteht kein Zwang, riesige Dateien mitzuschicken.

Ein optimiertes Bild nützt wenig, wenn der Server lange antwortet. Hier kommen Hosting, Caching und ein Content Delivery Network (CDN) ins Spiel. Ein CDN liefert statische Dateien von Standorten nahe am Besucher aus; für eine Seite, die vor allem Kunden im deutschsprachigen Raum erreicht, ist der Gewinn kleiner als bei internationalem Publikum, aber vorhanden. Wichtiger ist oft das Caching: Bilder, Schriften und Skripte mit Versionsnamen können lange im Browser liegen bleiben, während HTML kurz oder gar nicht zwischengespeichert wird.

Fremdskripte prüfen wir einzeln. Welche Funktion erfüllt das Skript, wer wertet die Daten aus, und geht es auch später oder auf Klick? Eine Karte lässt sich als statisches Vorschaubild darstellen, das erst nach dem Tippen die interaktive Version nachlädt. Ein Chat-Widget darf nach dem ersten Eingriff des Nutzers starten. Dieses Muster senkt die Last für Besucher, die den Dienst nie öffnen, und passt zugleich zu datenschutzfreundlicher Einwilligung.

Beim Code zählt, was der Browser beim Start ausführen muss. Seiten, die überwiegend aus Inhalt bestehen, brauchen kaum clientseitige Logik. Serverseitiges Rendering, kleinere Bundles, aufgeteilter Code und interaktive Bereiche, die erst bei Bedarf hydratisiert werden, verkürzen lange Aufgaben im Hauptthread. Das zahlt direkt auf INP ein, weil der Browser Eingaben nicht mehr hinter Berechnungen warten lässt.

Ein Prüfschritt, der sich bewährt: im Performance-Panel des Browsers eine Aufnahme starten, auf Menü oder Formular tippen und nach langen Aufgaben suchen. Zeigt sich dort ein Block über mehrere hundert Millisekunden, ist die Ursache meist ein einzelnes Skript oder eine Komponente, die beim Start zu viel erledigt. Solche Befunde sind konkret und lassen sich gezielt beheben, statt pauschal „weniger JavaScript“ zu fordern.

Das Cookie-Banner ist ein Sonderfall, weil es zwei Interessen vereint, die sich beißen: rechtliche Anforderungen und Ladeverhalten. Wird es nachträglich in den Textfluss eingefügt, verschiebt es alles und treibt den CLS. Besser reserviert man Platz oder legt es als überlagerte Fläche an, die den Inhalt nicht bewegt. Zudem sollte das Banner nicht das größte sichtbare Element sein, sonst misst der LCP das Banner statt des Titelbilds.

Bei Webfonts lässt sich der Schriftwechsel nie ganz verhindern, aber entschärfen. Wenige Schnitte, eigene Auslieferung vom selben Server und das Vorladen der wichtigsten Datei verkürzen die Wartezeit. Mit font-display kontrolliert man, was währenddessen sichtbar ist, und moderne Anpassungen der Ersatzschrift halten die Zeilenumbrüche nahezu identisch. Dann bleibt der Sprung unauffällig.

Karussells und automatisch wechselnde Bilder sind ein weiterer Fall: Sie laden oft mehrere große Bilder, obwohl nur eines sichtbar ist, und die Interaktion mit ihnen belastet den Hauptthread. Hier sollte man ehrlich fragen, ob die Galerie diese Mechanik braucht. Ein ruhiges Raster mit verzögert geladenen Vorschaubildern und einer Großansicht auf Klick erzählt dieselbe Geschichte mit weniger Last. Es ist ein Gestaltungsthema, kein reines Technikthema, und wir würden es gemeinsam entscheiden.

Ein letzter Sonderfall betrifft Videos. Ein eingebettetes Video von einer Plattform lädt beim Seitenaufruf oft mehrere hundert Kilobyte Skript, obwohl es kaum jemand abspielt. Ein Vorschaubild mit Abspielknopf, das den Player erst beim Klick holt, hält die Seite leicht und zeigt dasselbe Motiv. Das Video bleibt erhalten, nur der Zeitpunkt der Last ändert sich.

Zunächst die ehrliche Einordnung zum Ranking. Core Web Vitals sind ein Signal im Rahmen der Page Experience, also ein Faktor unter vielen. Inhalte, die zur Suchanfrage passen, Verlinkung und Vertrauen wiegen in aller Regel schwerer. Eine Seite mit schwacher Relevanz steigt nicht, weil sie schnell wird. Zwischen zwei ähnlich starken Seiten kann Geschwindigkeit dagegen den Ausschlag geben. Wer Rankingsprünge verspricht, verkauft mehr, als sich belegen lässt.

Der verlässlichere Nutzen liegt beim Besucher. Eine Seite, die schnell sichtbar wird, stabil bleibt und auf Antippen reagiert, verliert weniger Menschen vor dem ersten Kontakt. Das betrifft Anfragen, Anrufe und Terminbuchungen direkt. Wie groß der Effekt auf eine konkrete Seite ausfällt, hängt von Branche, Verkehrsquelle und Ausgangszustand ab, und wir nennen dafür keine Prozentwerte.

Gemessen würde so: Die Search Console zeigt im Bericht zu den Core Web Vitals, ob URL-Gruppen von „schlecht“ oder „verbesserungswürdig“ nach „gut“ wechseln, mit einigen Wochen Verzögerung. PageSpeed Insights liefert ergänzend CrUX-Werte pro URL. Geschäftlich zählt ein Vergleich von Absprungverhalten und Kontaktanfragen vor und nach den Änderungen, möglichst über mehrere Wochen, damit Saison und Kampagnen das Bild nicht verzerren.

Nicht garantieren lässt sich, dass alle Kennzahlen auf jeder Seite grün werden. Ein eingebundener Dienst, den der Betrieb braucht, kann einen Rest an Last mitbringen, und manche Zielgruppen nutzen schwache Geräte. Dann zählt, wo die größten Reibungen liegen und was sich dort beheben lässt. Eine ehrliche Zwischenbilanz mit offenen Punkten ist mehr wert als eine geschönte Gesamtnote.

Der häufigste Rückschritt kommt nach dem Projekt. Jemand lädt ein neues Titelbild im Rohformat hoch, das Marketing bindet ein weiteres Skript ein, ein Redakteur ergänzt eine Galerie mit fünfzig Bildern. Keine dieser Handlungen ist falsch gemeint, und jede kann die Kennzahlen verschlechtern. Verbesserungen ohne Absicherung sind deshalb nur eine Momentaufnahme.

Performance-Budgets machen die Grenzen sichtbar. Ein Budget legt fest, wie groß Bilder, Skripte und die gesamte Seitenlast höchstens sein dürfen oder welche Laborwerte nicht unterschritten werden sollen. In einer Build-Pipeline lassen sich solche Prüfungen automatisieren, sodass ein Deployment auffällt, bevor es live geht. Ergänzend sorgt eine Bildverarbeitung beim Upload dafür, dass Redakteure keine überdimensionierten Dateien ins System bringen.

Dazu kommt eine einfache Routine: ein Blick in die Search Console pro Monat, eine kurze Prüfung nach größeren Änderungen und eine Liste der erlaubten Fremdskripte mit Verantwortlichen. Diese Disziplin ist weniger spektakulär als ein Umbau, verhindert aber, dass nach einem Jahr dieselben Probleme zurückkehren.

Wer Core Web Vitals verbessern will, braucht zuerst eine ehrliche Bestandsaufnahme und erst danach Maßnahmen. Der erste Schritt kostet nichts: Search Console öffnen, den Bericht zu den Core Web Vitals ansehen und prüfen, welche Seitentypen auf Mobilgeräten auffallen. Danach bietet ein PageSpeed-Lauf pro auffälliger Seite die ersten Hinweise.

Bei bildlastigen Unternehmensseiten ist die Reihenfolge meist klar: Titelbild und Bildauslieferung, dann Fremdskripte, dann Schriften und Layout, zuletzt der Code. Jeder Schritt lässt sich einzeln prüfen, und jeder bringt auch dann etwas, wenn der nächste nie nötig wird. Das Ziel ist keine Bestnote im Testwerkzeug, sondern eine Seite, die Besucher ohne Reibung nutzen können.

Wenn Sie wissen möchten, wo Ihre Seite steht, schauen wir gemeinsam auf Ihre Felddaten und benennen die drei Hebel mit dem besten Verhältnis von Wirkung zu Aufwand. Auch das Ergebnis, dass nichts Dringendes zu tun ist, gehört dazu.