Türk SEM · SEO-Werkzeug

Site Speed Metrix: Website-Speed-Test

Wir laden Ihre Seite dreimal in einem echten Browser, jedes Mal von Grund auf neu. Sie sehen den Medianwert, welche Datei wie lange bremst und was Ihnen jede Maßnahme bringt.

Zu testende Website

Gerät

4G (170 ms Latenz, 9 Mbit/s), 2-fach gedrosselte CPU, Bildschirm 412×823

Wählen Sie das Gerät, geben Sie Ihre Adresse ein und klicken Sie auf Tempo messen. Eine Messung dauert 30 bis 90 Sekunden.

So funktioniert der Test

1
Website verbinden
Sie geben die Adresse einmal ein. Serverstandort, HTTP-Version und Komprimierung stammen aus demselben Scan; doppelt gemessen wird nichts.
2
Drei Seitenaufrufe
Jeder Aufruf läuft in einem frischen Chromium mit leerem Cache. Mobil messen wir mit 4G und einer doppelt verlangsamten CPU; damit liegen die Werte nah an dem, was echte Smartphone-Nutzer derselben Websites erleben. Am Desktop wird nicht gedrosselt. Gemessen wird von unserem Server in Istanbul.
3
Jede Anfrage im Protokoll
Für jede Datei halten wir DNS, Verbindungsaufbau, TLS, Wartezeit und Ladezeit fest, dazu die Größe und ob sie die Darstellung blockiert. Den Seitenaufbau zeichnen wir Bild für Bild auf.
4
Der Median zählt
Angezeigt wird der Median der drei Messungen samt Streuung. So entscheiden Sie nicht auf Grundlage eines einzelnen Ausreißers.

So entsteht die Note

Jede Kennzahl wird über eine logarithmische Normalverteilung in 0 bis 100 Punkte umgerechnet; Methode und Schwellen sind die von Lighthouse veröffentlichten (Chrome for Developers). Die Gewichtung legen wir fest: Total Blocking Time 30 %, Largest Contentful Paint 25 %, Cumulative Layout Shift 25 %, First Contentful Paint 10 % und Serverantwort 10 %. Die Serverantwort ersetzt den Speed Index, weil sie bei der Wahl des Hosters am meisten zählt. Wir messen sie selbst und ohne Drosselung.

A (90 bis 100): Die Seite lädt schnell. Viel ist hier nicht mehr zu holen.
B und C (70 bis 89): Im Großen und Ganzen in Ordnung, ein oder zwei Kennzahlen drücken aber den Wert. Beginnen Sie mit den ersten Punkten unter Maßnahmen.
D und E (50 bis 69): Besucher müssen warten. Meist steckt ein einzelnes großes Problem dahinter: ein schweres Bild, ein blockierendes Skript oder ein langsamer Server.
F (unter 50): Die Seite lädt vor allem mobil schleppend. Sehen Sie sich zuerst die Serverantwort und das größte Element an.

Welche Werte als gut gelten

Diese Schwellen legt Google für Daten echter Nutzer fest (web.dev). Maßgeblich ist, was 75 % der Seitenaufrufe erleben.

Kennzahl	Gut	Verbesserungswürdig	Schlecht
Largest Contentful Paint (LCP)	bis 2,5 s	2,5 bis 4 s	über 4 s
Interaction to Next Paint (INP)	bis 200 ms	200 bis 500 ms	über 500 ms
Cumulative Layout Shift (CLS)	bis 0,1	0,1 bis 0,25	über 0,25
First Contentful Paint (FCP)	bis 1,8 s	1,8 bis 3 s	über 3 s
Time to First Byte (TTFB)	bis 0,8 s	0,8 bis 1,8 s	über 1,8 s

Labormessung und echte Nutzer

Für das Ranking zieht Google heran, was echte Chrome-Nutzer in den letzten 28 Tagen erlebt haben (Chrome UX Report). Diese Daten verraten, ob es ein Problem gibt, aber nicht, wo es steckt. Site Speed Metrix lädt die Seite unter festen Bedingungen und zeigt deshalb, welche Datei bremst. Im Ergebnis stehen beide Werte nebeneinander.

Interaction to Next Paint lässt sich nur bei echten Nutzern messen, denn dafür muss jemand klicken. Im Labor dient stattdessen die Total Blocking Time als Maß (web.dev). Beide zeigen dasselbe Problem: JavaScript, das die Seite beschäftigt hält.

Für den SEO-Zustand der ganzen Website gibt es unseren SEO-Check, für den Wochenverlauf der Nutzerdaten das PageSpeed-Portal. Alle drei greifen auf denselben Scan zu.

Prüfungen, die PageSpeed nicht macht

Nach den drei Messungen öffnen wir die Seite noch einmal und führen die folgenden Prüfungen durch. Keine davon finden Sie in PageSpeed Insights. Im Ergebnis ist jede als Türk-SEM-Messung gekennzeichnet. Alle sind Labormessungen, keine Daten echter Nutzer.

Die Serverantwort in vier Teilen: Wir zerlegen die Serverantwort in DNS, TCP-Verbindung, TLS und Wartezeit und messen sie fünfmal ohne Drosselung. Ziehen wir von der Wartezeit einen Netzwerk-Roundtrip ab, erhalten wir eine Schätzung, wie lange der Server für die Seite braucht. Für den Vergleich von Hostern ist das der aussagekräftigste Wert.
Reaktion auf Klicks (Labor-INP): Wir klicken echte Menüs und Schaltflächen auf dem ersten Bildschirm an und messen, wann die Seite reagiert. PageSpeed klickt nie und kann deshalb keinen INP liefern. Beim Klicken blockieren wir jede Anfrage, die Daten an Ihren Server schickt; der Test verändert auf Ihrer Website nichts.
Was die Seite blockiert: Mit den Long-Animation-Frames-Daten von Chrome ermitteln wir für jeden Frame, der die Seite länger als 50 ms beschäftigt hat, welches Skript wie viel Zeit verbraucht hat. Ihr eigener Code wird von Werbe- und Analyse-Skripten getrennt.
Verschiebung beim Scrollen: Wir scrollen die Seite herunter und messen, wie stark nachladende Werbung und Bilder den Inhalt verschieben. PageSpeed betrachtet nur den ersten Seitenaufbau.
Zweiter Besuch: Wir öffnen die Seite mit gefülltem Cache erneut. Sie sehen, wie viele Daten ein wiederkehrender Besucher lädt und wie schnell die Seite für ihn erscheint.
Zurück-Button: Wir prüfen, ob sich die Seite beim Zurück- und Vor-Button sofort aus dem Browser-Cache öffnet. Falls nicht, zeigen wir den Grund, den Chrome selbst meldet.
Cookie-Banner und LCP: Ist das größte Element im sichtbaren Bereich das Cookie-Banner, misst der LCP das Banner statt Ihrer Seite. Auf europäischen Websites kommt das häufig vor; wir weisen gesondert darauf hin.

Was die Tiefenanalyse zeigt

Wir pressen nicht alles, was wir messen, in eine einzige Note. Die Tiefenanalyse zeigt Schritt für Schritt, warum die Seite so lädt, wie sie lädt. Dafür ist kein zusätzlicher Seitenaufruf nötig; alles stammt aus derselben Messung.

Visueller Fortschritt: Wir vergleichen jedes Bild des Filmstreifens mit dem letzten und zeichnen, wie viel vom Bildschirm zu jedem Zeitpunkt fertig ist. Daraus ergeben sich der Speed Index sowie die Zeitpunkte, an denen der Bildschirm zu 85 % und vollständig aufgebaut ist. Der Speed Index dient zur Orientierung und fließt nicht in die Note ein.
Ungenutzter Code: Wir zählen Datei für Datei, wie viel vom beim Laden übertragenen JavaScript und CSS nie ausgeführt wurde. So sehen Sie, welche Dateien sich aufteilen oder später laden lassen und was das ungefähr spart.
Rechenzeit und Seitenaufbau: Wir schlüsseln die Arbeit des Browsers beim Laden nach JavaScript, Layout und Stilberechnung auf. Dazu kommen die Zahl der HTML-Elemente, die Verschachtelungstiefe und der JavaScript-Speicher.
Verbindungen: Für jede Domain, mit der sich die Seite verbindet, zeigen wir DNS-, TCP- und TLS-Zeit sowie das Protokoll. Jedes Skript eines Drittanbieters kostet einen Verbindungsaufbau; hier sehen Sie, wie viel.
Drittanbieter-Dienste: Im Reiter Aufteilung erscheinen externe Dienste mit ihrem Namen statt mit der Domain, etwa Google Tag Manager, Meta Pixel, Hotjar oder Live-Chat-Widgets. Zu jedem sehen Sie die Anfragen, die übertragene Datenmenge und wie lange er die Seite blockiert.
Server und Sicherheit: TLS-Version, Aussteller und Ablaufdatum des Zertifikats, CDN, Cache-Header und die Server-Timing-Werte, die der Server mitschickt. Läuft das Zertifikat in weniger als drei Wochen ab, erscheint das als Maßnahme.
Schriften: Wir zeigen die Webfonts der Seite und ihre font-display-Einstellung. Fehlt sie, blendet Chrome den Text bis zu 3 Sekunden aus, bis die Schrift geladen ist.
Alle drei Messungen: Die Note stammt aus der mittleren Messung. Wir zeigen trotzdem alle drei und die Streuung dazwischen. Ist sie groß, reagiert der Server bei jedem Aufruf anders.
CO₂-Schätzung: Aus der Datenmenge, die die Seite lädt, schätzen wir den CO₂-Ausstoß pro Aufruf nach dem Sustainable-Web-Design-Modell (v4). Das Modell rechnet mit dem weltweiten Durchschnitt des Strommixes. Bei einem Hoster mit Ökostrom liegt der echte Wert niedriger.

Woher die Schwellenwerte kommen

An den Schwellen der Core Web Vitals ändern wir nichts, denn genau sie zählen für das Ranking. Sie stützen sich auf zwei Dinge: Forschung zur menschlichen Wahrnehmung und die Frage, ob Websites sie realistisch erreichen können (web.dev). Laut der Forschung wirkt eine Reaktion innerhalb von etwa 100 ms unmittelbar (Nielsen; Card, Robertson und Mackinlay, 1991; Miller, 1968). Die meisten mobilen Websites schaffen das nicht, deshalb hat Google die INP-Grenze auf 200 ms gelegt.

Die Wahrnehmungsforschung zeigt außerdem, dass eine einzelne Zahl nicht reicht. In einer Studie von Kelton und Kollegen lag das Load-Ereignis des Browsers im Schnitt 6,4 Sekunden nach oder 2,1 Sekunden vor dem Moment, in dem die Nutzer die Seite als geladen empfanden (NSDI 2017). In den Eyeorg-Studien mit jeweils tausend Teilnehmern deckte sich selbst keine der ausgefeilten Kennzahlen ganz mit der Wahrnehmung (Varvello u. a.). Deshalb liefern wir statt einer einzigen Punktzahl mehrere Messungen, die einander ergänzen.

Die Serverzeit wirkt klein, verändert aber das Verhalten. In einem Experiment von Google senkten 100 bis 400 ms zusätzliche Verzögerung bei den Suchergebnissen die Zahl der Suchen pro Nutzer um 0,2 bis 0,6 %; der Effekt hielt noch Wochen an, nachdem die Verzögerung entfernt worden war (Google Research).

Häufige Fragen

Warum weicht mein Ergebnis von PageSpeed Insights ab?

PageSpeed Insights geht im Mobiltest bewusst von einer sehr langsamen Verbindung aus; seine Werte fallen deshalb meist schlechter aus als unsere. Wir messen mit einer 4G-Verbindung, die nah an der Erfahrung echter Nutzer liegt, und laden die Seite dreimal. Die Zahlen decken sich nicht genau, die Probleme schon.

Warum schneidet Mobil so viel schlechter ab als Desktop?

Der Mobiltest bildet ein Mittelklasse-Smartphone mit 4G nach. Schwere Bilder und lange Skripte, die am Laptop nicht auffallen, kosten hier ganze Sekunden. Kommen die meisten Besucher übers Handy, ist das der entscheidende Wert.

Welche Werte zählen für das Google-Ranking?

Google liest die Core Web Vitals, also LCP, INP und CLS, aus den Daten echter Nutzer. Unsere Labormessung erklärt, warum diese Daten so aussehen, wie sie aussehen. Ins Ranking fließt sie selbst nicht ein.

Warum wird dreimal gemessen?

Dieselbe Seite lädt je nach Netzauslastung und Serverlast mal schneller, mal langsamer. Wir nehmen den Median aus drei Messungen und zeigen die Streuung. Ist sie groß, schwankt meist die Antwortzeit Ihres Servers.

Von wo aus wird gemessen?

Von unserem Server in Istanbul. Steht Ihr Server in Deutschland, kostet schon der Verbindungsaufbau einige Dutzend Millisekunden mehr als bei einer Messung aus Frankfurt. Für den Vergleich mehrerer Websites spielt das keine Rolle, weil alle denselben Weg nehmen. Im Ergebnis sehen Sie zudem den Standort Ihres Servers.

Wie viele Tests kann ich machen?

Ohne Konto drei am Tag, mit einem kostenlosen Konto 20. Ergebnisse bleiben 24 Stunden gespeichert; ein gespeichertes Ergebnis erneut aufzurufen, zählt nicht als Test.

Wie senke ich die Serverantwortzeit (TTFB)?

Am schnellsten hilft ein Seiten-Cache: Der Server baut die Seite dann nicht bei jedem Aufruf neu. Danach lohnt der Blick auf Datenbankabfragen, die Leistung des Servers und die Entfernung zu den Besuchern. Sitzt Ihr Publikum in einem anderen Land, verkürzt ein CDN diese Zeit spürbar.

Ist der Labor-INP derselbe wie der echte INP?

Nein. Der echte INP ergibt sich aus allen Interaktionen der Besucher während des gesamten Besuchs, und Google erhebt ihn bei Chrome-Nutzern. Wir klicken in einem Browser auf unserem Server einige Menüs und Schaltflächen auf dem ersten Bildschirm an. Das Ergebnis zeigt, ob es ein Problem gibt und welches Element es verursacht; für das Ranking zählt weiterhin der Wert echter Nutzer.

Wie wird die Verarbeitungszeit am Server geschätzt?

Der Aufbau der TCP-Verbindung kostet einen Roundtrip zum Server und spiegelt damit die Entfernung im Netz. Auch in der Wartezeit am Server steckt ein Roundtrip. Zieht man die TCP-Zeit von der Wartezeit ab, erhält man eine gute Schätzung, wie lange der Server für die Seite braucht. Es bleibt eine Schätzung; sendet Ihr Server einen Server-Timing-Header, steht dort der genaue Wert.

Site Speed Metrix: Website-Speed-Test

So funktioniert der Test

Website verbinden

Drei Seitenaufrufe

Jede Anfrage im Protokoll

Der Median zählt