Den Hauptinhalt der Seite auf Mobilgeräten schnell anzeigen
Beschreibung
Dieses Kriterium misst die Geschwindigkeit der Seite unter den Bedingungen eines durchschnittlichen Smartphones: iPand lädt sie einmal, ohne Cache, auf einem simulierten Pixel 7, mit dem gedrosselten Netzwerk und Prozessor des Mobilprofils von Lighthouse. Es erfasst, wann das größte sichtbare Element angezeigt wird (LCP) und wie lange Skripte die Seite blockieren (TBT); die Antwortzeit des Servers (TTFB) wird beim direkten Abruf der Seite gemessen.
Es handelt sich um eine Labormessung, nicht um die Geschwindigkeit, die Ihre echten Besucher erleben (Chrome UX Report).
Warum es für KI-Assistenten zählt
Google empfiehlt eine gute Nutzererfahrung auf der Seite, um in seinen KI-Funktionen zu erscheinen, und die Ladegeschwindigkeit gehört dazu. Ein langsamer Server bremst auch das Crawling: Wenn die Antwortzeiten steigen, crawlt Google weniger Seiten Ihrer Website.
- LCP markiert den Moment, in dem der Hauptinhalt sichtbar wird: web.dev bewertet den Wert bis 2,5 s als gut.
- TTFB ist kein Core Web Vital, aber web.dev rät, 0,8 s nicht zu überschreiten: Der gesamte restliche Ladevorgang wartet auf die Antwort des Servers.
- Jede JavaScript-Aufgabe über 50 ms blockiert die Seite; TBT summiert diese Blockaden und weist auf eine Seite hin, die schlecht auf die Aktionen der Besucher reagiert.
So korrigieren Sie es
- 1 Beschleunigen Sie die Anzeige des Hauptelements LCP darf 2,5 s nicht überschreiten; diese Messung wiegt im Kriterium am schwersten. Finden Sie das Hauptelement, oft das Bild oben auf der Seite oder die erste Überschrift. Liefern Sie es in der richtigen Größe und in einem leichten Format aus, laden Sie es nicht verzögert (loading=lazy) und laden Sie es vorab (Preload), wenn der Browser es spät entdeckt.
- 2 Lassen Sie den Server schneller antworten Der Server muss die ersten Bytes der Seite in höchstens 0,8 s senden. Cachen Sie die Seiten auf dem Server oder in einem CDN, vermeiden Sie Weiterleitungen vor der Seite und verringern Sie die Verarbeitung bei jedem Aufruf, etwa Datenbankabfragen oder CMS-Plug-ins.
- 3 Verschieben Sie nicht wesentliche Skripte TBT darf 200 ms nicht überschreiten. Laden Sie Skripte mit defer oder async, entfernen Sie überflüssig gewordene Skripte von Drittanbietern (Widgets, doppelt eingebundenes Tracking) und teilen Sie lange Verarbeitungen auf. Der Anteil jeder Aufgabe, der über 50 ms hinausgeht, wird zu TBT addiert.
- 4 Halten Sie Abstand zu den Schwellenwerten Testen Sie die Seite mit Lighthouse oder PageSpeed Insights im Mobilmodus, unter Bedingungen, die denen von iPand vergleichbar sind. Liegt ein Wert innerhalb von ± 10 % um einen Schwellenwert, bleibt das Ergebnis der vorherigen Analyse bestehen, damit der Status nicht von einem Tag auf den anderen kippt: Bleiben Sie deutlich darunter.
Fazit
iPand bewertet die Seite so, wie ein durchschnittliches Smartphone sie sehen würde: Hauptinhalt in 2,5 s, Server in 0,8 s, Blockierung durch Skripte von höchstens 200 ms. Halten Sie Abstand zu diesen Schwellenwerten, damit das Ergebnis stabil bleibt.
