Website-Geschwindigkeit für KMU: Warum Core Web Vitals über Anfragen entscheiden

10. Juli 20267 Min. Lesezeit

Eine langsame Website kostet Sie Anfragen, jeden Tag, und meistens unbemerkt. Der Besucher, der auf einen grauen Bildschirm wartet, beschwert sich nicht. Er drückt zurück und ruft den nächsten Anbieter aus den Suchergebnissen auf. Genau deshalb gehört die Ladezeit zu den wenigen Website-Themen, die sich direkt in Anfragen übersetzen.

In diesem Beitrag erklären wir, was hinter den Core Web Vitals steckt, ganz ohne Fachchinesisch, warum Google sie ernst nimmt, und welche Maßnahmen wirklich etwas bringen. Als Beleg nehmen wir unsere eigene Website: Die haben wir nach genau diesen Prinzipien gebaut, mit einem Lighthouse-Score von 100 und einer Desktop-Ladezeit (LCP) von 0,44 Sekunden im Labortest.

Warum Ladezeit über Anfragen entscheidet

Langsame Ladezeit als unsichtbarer Verlust an Anfragen und Umsatz

Die Wirkung einer langsamen Website ist doppelt. Zuerst beim Menschen: Wer über eine Google-Suche oder eine Anzeige kommt, hat noch keine Bindung zu Ihnen. Jede Sekunde Wartezeit ist eine Einladung, es woanders zu versuchen, besonders am Smartphone unterwegs im Mobilfunknetz. Die Besucher, die Sie so verlieren, tauchen in keiner Statistik als „verlorene Anfrage“ auf. Sie waren einfach nie richtig da.

Dann bei Google: Die Ladezeit und die Nutzererfahrung fließen in die Bewertung von Websites ein. Google misst dafür reale Nutzerdaten und stellt sie Website-Betreibern als Core Web Vitals zur Verfügung. Eine träge Website hat es damit doppelt schwer: Sie wird seltener gut platziert, und die Besucher, die trotzdem kommen, springen häufiger ab.

Für KMU ist das eine gute Nachricht, denn hier lässt sich mit überschaubarem Aufwand ein echter Vorsprung holen: Viele Websites im österreichischen Mittelstand sind über Jahre gewachsen, tragen Ballast aus Plugins und Baukästen mit sich und sind entsprechend langsam. Wer hier sauber arbeitet, hebt sich messbar ab.

Core Web Vitals ohne Fachchinesisch

Vergleich der Ladezeit einer Website zwischen Mobilgerät und Desktop

Die Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite in Zahlen fasst. Hinter den kryptischen Abkürzungen stecken drei einfache Fragen:

LCP (Largest Contentful Paint): Wie schnell sehe ich etwas? Gemessen wird, wann das größte Element im sichtbaren Bereich fertig geladen ist, meist das Hauptbild oder die Überschrift. Das ist der Moment, in dem die Seite „da“ wirkt.
INP (Interaction to Next Paint): Wie schnell reagiert die Seite? Gemessen wird, wie lange die Seite braucht, um auf Klicks und Eingaben sichtbar zu reagieren. Eine Seite, die nach dem Tippen gefühlt einfriert, hat hier ein Problem.
CLS (Cumulative Layout Shift): Springt der Inhalt? Gemessen wird, wie stark sich das Layout während des Ladens verschiebt. Jeder kennt es: Man will einen Button drücken, im letzten Moment rutscht ein Banner dazwischen, und man klickt daneben.

Wichtig ist der Unterschied zwischen Labor- und Felddaten. Labortests wie Lighthouse simulieren einen Seitenaufruf unter festgelegten Bedingungen, ideal zum Aufspüren von Problemen. Felddaten stammen von echten Besuchern und sind das, was Google für die Bewertung heranzieht. Beides gehört zusammen: Das Labor zeigt, was zu tun ist, das Feld zeigt, ob es gewirkt hat.

Unsere eigene Website als Praxisbeleg

Wir behaupten nicht nur, dass Performance planbar ist, wir haben es an der eigenen Website durchgezogen. Beim Rebuild von cnsolutions.at galt ein hartes Budget, und das Ergebnis im Labortest: Lighthouse-Score 100, Desktop-LCP von 0,44 Sekunden, und das größte JavaScript-Bundle der gesamten Website bleibt unter 9 Kilobyte. Zum Vergleich: Ein einziges durchschnittliches Foto in Originalgröße ist ein Vielfaches davon.

Erreicht haben wir das nicht mit Tricks, sondern mit drei Grundsatzentscheidungen, die sich auf die meisten KMU-Websites übertragen lassen:

Statisches HTML statt schwerem System. Jede Seite wird beim Veröffentlichen fertig gebaut und liegt als fertige Datei am Server. Beim Aufruf muss nichts mehr berechnet werden, der Browser bekommt sofort das Ergebnis. Kein träges Theme, kein Plugin-Stapel, keine Datenbankabfragen zwischen Besucher und Inhalt.
Bilder konsequent optimiert. Moderne Formate wie WebP, passende Größen für jede Bildschirmbreite, fest reservierter Platz im Layout (das verhindert das Springen, also CLS) und Laden erst, wenn ein Bild wirklich in den sichtbaren Bereich kommt.
JavaScript-Diät. Skripte sind der häufigste Grund für träge Reaktionen (INP). Wir laden nur, was eine Funktion hat, und alles Übrige gar nicht erst. Die Frage ist nicht „Was könnte man einbauen?“, sondern „Was rechtfertigt seinen Preis in Ladezeit?“.

Diese Zahlen sind Laborwerte unter definierten Bedingungen, keine Garantie für jede Verbindung und jedes Gerät. Aber sie zeigen, was möglich ist, wenn Performance von Anfang an ein Designkriterium ist und nicht nachträglich „optimiert“ wird. Nach diesem Prinzip bauen wir auch Kundenprojekte, mehr dazu auf unserer Webdesign-Seite.

Was wirklich hilft: die Maßnahmen mit Hebel

Warum immer mehr Plugins die Website-Geschwindigkeit nicht verbessern

Wenn wir fremde Websites analysieren, tauchen fast immer dieselben Bremsen auf, und damit auch dieselben Hebel:

Bilder verkleinern und modern ausliefern. Der Klassiker: Fotos direkt von der Kamera in die Website geladen. Richtig dimensionierte WebP-Bilder sind oft der größte Einzelhebel überhaupt.
Unnötige Skripte entfernen. Alte Chat-Widgets, doppelte Analytics-Einbindungen, Slider-Bibliotheken für einen einzigen Slider. Alles, was keine Aufgabe mehr hat, fliegt raus.
Oben sichtbaren Bereich priorisieren. Das Hauptbild früh und mit hoher Priorität laden, alles unterhalb später. Das verbessert direkt den LCP.
Platz für Inhalte reservieren. Bilder, Einbettungen und Banner brauchen feste Maße, damit beim Laden nichts springt (CLS).
Schnelles Hosting mit Caching und CDN. Auch die beste Seite wird langsam, wenn der Server trödelt. Kurze Serverantwortzeiten sind das Fundament, auf dem alles andere aufbaut. Worauf es dabei ankommt, beschreiben wir bei der Hosting-Betreuung.

Und was bringt wenig? Vor allem das Stapeln von „Optimierungs-Plugins“, die an einem überladenen Fundament herumdoktern. Ein Caching-Plugin kann einer langsamen Website helfen, aber fünf Performance-Plugins machen aus einem überfrachteten System kein schlankes. Genauso wenig zielführend: der Jagd nach dem perfekten Punktwert im Labortest, während echte Nutzer am Handy weiter warten. Der Score ist ein Werkzeug, das Ziel sind schnelle Seiten für echte Besucher.

So messen Sie richtig

Hohe Absprungrate und Ranking-Verlust als Folge einer langsamen Website

Der erste Schritt ist immer eine ehrliche Messung, und die ist kostenlos. Unser Speed-Test ruft die offiziellen Google-PageSpeed-Daten für Ihre Website ab und zeigt Ihnen Performance-Score, Core Web Vitals und die größten Ladezeit-Bremsen, verständlich eingeordnet statt als Fehlerliste. Messen Sie dabei nicht nur die Startseite: Gerade Leistungsseiten und Landingpages, auf denen Anfragen entstehen sollen, verdienen einen eigenen Blick, denn dort entscheidet die Ladezeit unmittelbar über bezahlte Klicks und Anfragen.

Bei der Interpretation hilft eine einfache Faustregel: Erst die großen Bremsen lösen (Bilder, Skripte, Server), dann feinjustieren. Wer die Reihenfolge umdreht, verbrennt Zeit an Details, während die Hauptbremse weiter wirkt. Und dokumentieren Sie den Ausgangswert: Nur so können Sie nach jeder Maßnahme sehen, ob sie tatsächlich gewirkt hat, statt es zu vermuten.

Häufige Fragen zur Website-Geschwindigkeit

Muss ich meine Website neu bauen, um schnell zu werden?

Nicht zwingend. Bilder, überflüssige Skripte und Hosting lassen sich fast immer im Bestand verbessern, und oft liegt genau dort der größte Hebel. Ein Neubau lohnt sich, wenn das Fundament selbst die Bremse ist, etwa ein überladenes Theme mit Jahren an Plugin-Ballast, oder wenn ohnehin ein Relaunch ansteht. Dann sollte Performance von Anfang an ein Designkriterium sein.

Welcher der drei Core-Web-Vitals-Werte ist der wichtigste?

Für die meisten KMU-Websites ist es der LCP, also die Zeit, bis der Hauptinhalt sichtbar ist, denn hier entscheidet sich der erste Eindruck. CLS und INP werden wichtig, sobald sie schlecht sind: Eine springende Seite oder träge Buttons vertreiben Besucher genauso zuverlässig. Sinnvoll ist, alle drei im grünen Bereich zu halten und beim Optimieren mit dem schlechtesten Wert zu beginnen.

Warum zeigt mein Test am Handy schlechtere Werte als am Desktop?

Mobile Labortests simulieren bewusst ein langsames Mobilfunknetz und ein schwächeres Gerät, damit Probleme sichtbar werden, die am schnellen Büro-Rechner verborgen bleiben. Deshalb sind mobile Werte fast immer schlechter als Desktop-Werte. Entscheidend ist, dass die Seite auch unter diesen strengen Bedingungen gut abschneidet, denn ein relevanter Teil Ihrer Besucher kommt mobil.

Wie oft sollte ich die Ladezeit prüfen?

Nach jeder größeren Änderung an der Website, etwa neuen Plugins, neuen Bildern im Kopfbereich oder einem Theme-Update, und ansonsten in regelmäßigen Abständen. Websites werden selten schlagartig langsam, sie werden es schleichend. Wer quartalsweise misst, erkennt den Trend, bevor er Anfragen kostet.

Fazit

Website-Geschwindigkeit ist kein Technikthema für Perfektionisten, sondern ein Umsatzthema: Sie entscheidet mit, ob aus Besuchern Anfragen werden und wie gut Google Ihre Seiten platziert. Die Core Web Vitals machen das messbar, und die wirksamen Maßnahmen sind keine Zauberei: schlankes Fundament, optimierte Bilder, JavaScript-Diät, schnelles Hosting. Dass damit Bestwerte erreichbar sind, zeigt unsere eigene Website im Labortest mit Lighthouse 100 und 0,44 Sekunden Desktop-LCP.

Der beste erste Schritt: Messen Sie ehrlich, wo Sie stehen. Der kostenlose Speed-Test mit Live-Daten von Google zeigt es Ihnen in wenigen Sekunden, samt Ihren größten Hebeln.