Warum ein guter PageSpeed-Score nicht beweist, dass Ihre Website schnell ist

«Das erste Prinzip lautet, dass man sich nicht selbst täuschen darf, und man selbst ist am leichtesten zu täuschen.»
— Richard Feynman, 1974

Der Screenshot kommt meist am Ende eines Projekts: ein grosser grüner Kreis, 98 von 100, verschickt als Beweis, dass die Website schnell ist. Alle sind zufrieden, die Agentur zuerst, und das Thema Performance landet bei den erledigten Punkten. Ich gebe es zu: Den Screenshot vom grünen Kreis habe ich auch schon gemacht.

Währenddessen öffnet ein potenzieller Kunde Ihre Seite auf dem Handy, im Zug zwischen Sitten und Brig. Er sieht einen weissen Bildschirm, dann ein Banner, das sich genau in dem Moment verschiebt, in dem er auf eine Schaltfläche tippen wollte. Kam er über eine Google-Anzeige, haben Sie diesen Klick bezahlt, ob er bleibt oder nicht.

Der Laborwert ist keine Lüge. Aber er misst nicht, worauf Google bei der Bewertung Ihrer Website achtet. Google schaut auf die Geschwindigkeit, die Ihre echten Besucher erleben, und genau die gilt es zu pflegen, auch wenn der Kreis schon grün ist.

Warum ein Laborwert nichts über Ihre echten Besucher verrät

PageSpeed Insights zeigt zwei verschiedene Dinge an, und oft schaut man nur auf eines. Oben stehen, sofern vorhanden, die Felddaten: was echte Chrome-Nutzer in den letzten 28 Tagen auf Ihrer Seite erlebt haben. Darunter folgt der Lighthouse-Score, eine Simulation auf einem fiktiven Gerät mit fiktiver Verbindung.

Das Labor simuliert einen einzigen Besucher

Der Labortest lädt Ihre Seite einmal, unter festen Bedingungen, ohne akzeptiertes Cookie-Banner, ohne Erweiterungen, ohne Verlauf. Für die Fehlersuche ist das sehr nützlich, weil sich das Ergebnis von Durchlauf zu Durchlauf wiederholen lässt. Über Ihre echten Besucher, ihre Handys und ihr Netz weiss er aber nichts.

Core Web Vitals werden im Feld gemessen

Die Core Web Vitals sind drei Messwerte für das tatsächliche Erlebnis, und jeder beantwortet eine einfache Frage: Wird etwas angezeigt, reagiert die Seite, bleibt alles an seinem Platz? Damit eine Seite als gut gilt, muss sie alle drei Schwellenwerte bei mindestens 75 % der echten Besuche einhalten:

• LCP: die Zeit bis zur Anzeige des grössten sichtbaren Elements, höchstens 2,5 Sekunden;
• INP: die Reaktionsfähigkeit auf Interaktionen, höchstens 200 Millisekunden;
• CLS: die Stabilität des Layouts während des Ladens, höchstens 0,1.

98 Punkte im Labor bei roten Felddaten bleiben eine langsame Website für die Menschen, auf die es ankommt.

1. Felddaten lesen, bevor Sie den Code anfassen

Beginnen Sie mit dem Bericht zu den Core Web Vitals in der Search Console. Er gruppiert Ihre Seiten nach Problem, trennt Mobilgerät und Desktop und zeigt, welcher der drei Messwerte Schwierigkeiten macht. Das ist die einzige seriöse Grundlage für die Entscheidung, wo Sie investieren, weil sie widerspiegelt, was Google tatsächlich sieht.

Wenn Ihre Website zu wenig Besuche hat

Hier gilt eine ehrliche Einschränkung: Eine Website mit wenig Traffic hat oft nicht genug Chrome-Besuche, damit Google Felddaten veröffentlicht. Der Bericht bleibt leer, und das ist normal. Dann wird das Labor wieder Ihr bester Anhaltspunkt, sofern Sie es als Schätzung lesen und auf einem echten Handy testen.

Deshalb gehört Performance auch zu einer SEO-Strategie und nicht auf eine Checkliste am Projektende: Sie wird über die Zeit verfolgt, Seite für Seite, wie Ihre Rankings, und sie verschlechtert sich unbemerkt mit jeder Ergänzung, wenn niemand darauf achtet.

2. Das Hauptbild leichter machen, das zuerst erscheint

Bei den meisten Unternehmenswebsites ist das Element, das den LCP bestimmt, ein Bild: das Headerfoto, das Startseitenvisual, manchmal ein Hintergrundvideo. Damit sollten Sie beginnen, denn es trägt oft den grössten Teil des Gewichts, auf das der Besucher wartet.

Das Bild verkleinern, bemassen und priorisieren

Drei Handgriffe lösen die meisten Fälle:

• das Bild in einem modernen Format wie AVIF oder WebP ausliefern, in der Grösse, in der es tatsächlich angezeigt wird;
• es mit Priorität laden, statt es hinter allem anderen warten zu lassen;
• Breite und Höhe im Code angeben, damit der Browser seinen Platz reserviert, bevor es überhaupt ankommt.

Der letzte Punkt löst auch den CLS, also jene Verschiebungen, durch die man die falsche Schaltfläche trifft. Auf meiner eigenen Website geben alle 739 Bilder ihre Abmessungen an, und keines verursacht eine Layoutverschiebung. Das ist kein Kunststück, sondern eine Regel, die beim Bau angewendet statt nachträglich korrigiert wird.

Vorsicht auch bei Karussells am Seitenanfang und automatisch startenden Hintergrundvideos. Sie werden oft zum LCP-Element, ohne dass es jemand entschieden hat, und zwingen das Handy, mehrere Visuals zu laden, bevor das erste erscheint. Ein einziges starkes, gut ausgeliefertes Bild wirkt fast immer besser, in der Wirkung wie im Tempo.

3. Skripte entfernen, die niemand bewusst gewählt hat

Das zweite Gewicht einer Website ist unsichtbar: die Skripte. Ein Chat-Widget, drei Tracking-Tools, ein Cookie-Banner, ein Karussell, ein Plugin, das für einen einmaligen Zweck installiert und nie entfernt wurde. Jedes schien leicht, und zusammen beschäftigen sie das Handy Ihres Besuchers genau dann, wenn er interagieren will.

Erst Inventur machen, dann optimieren

Listen Sie jedes Skript auf, das Ihre Website lädt, und fragen Sie, wer es hinzugefügt hat, warum und ob es noch etwas nützt. Viele kommen mit einem Theme, das gekauft wurde, um Zeit zu sparen . Diese Inventur allein bringt oft mehr als jede Feinoptimierung: Der schnellste Code ist der, den man gar nicht lädt.

Bei den Skripten, die bleiben, geht es um den Zeitpunkt. Ein Chat-Widget oder eine interaktive Karte hat keinen Grund, vor Ihrem Titel zu laden: Verschieben Sie sie auf nach der Hauptanzeige oder auf die erste Geste des Besuchers. Zuerst kommt der Inhalt, dann die Tools, und das Handy reagiert, wenn man es berührt.

Und keine Website ist perfekt. Das letzte Audit meiner eigenen fand noch strukturierte Daten, die rund 16 % des HTML ausmachen, und eine fehlende vorgezogene Verbindung zum Statistiktool. Das sind überzählige Kilos, bescheiden, aber real, und ich behandle sie wie jede andere Baustelle.

Geschwindigkeit entscheidet sich in der Architektur, nicht nach dem Launch

Geschwindigkeit im Nachhinein zu optimieren heisst, Gramm um Gramm an einer Struktur zu suchen, die ohne Waage gebaut wurde. Man komprimiert ein Bild, verzögert ein Skript, gewinnt ein paar Punkte, und die nächste Ergänzung macht den Gewinn wieder zunichte. Dauerhaft schnelle Websites sind schnell, weil jede Entscheidung beim Bau abgewogen wurde.

Ein Performance-Budget ab dem Entwurf festlegen

Ich arbeite von Anfang an mit dieser Vorgabe: welche Bilder in welchem Format, welche Skripte für welchen Zweck, welche Schrift in wie vielen Schnitten. Diese Entscheidungen gehören in die Webentwicklung , nicht in eine Optimierungsphase, für die man am Ende hoffentlich noch Zeit hat.

Eine Wahrheit sollten Sie im Kopf behalten: Geschwindigkeit gibt den Ausschlag, sie ersetzt nichts. Eine schnelle Seite, die die Frage des Besuchers nicht beantwortet, steigt nicht, und eine langsame, aber unverzichtbare Seite hält ihren Platz noch eine Weile. Performance ist eine Eintrittsbedingung, keine Strategie für sich.

Bereit, die Geschwindigkeit zu messen, die Ihre Besucher wirklich erleben?

Ein grüner Kreis freut, aber Ihre Besucher entscheiden, ob Ihre Website schnell ist. Schauen Sie, was sie erleben, kümmern Sie sich um das Hauptbild, misten Sie die Skripte aus, und der Score folgt von selbst. Umgekehrt hat das noch nie eine Website für irgendwen schneller gemacht.

👉 Sie möchten wissen, was Ihre Besucher wirklich erleben, wenn sie Ihre Website öffnen? Schreiben Sie mir