Website auf dem Smartphone testen

Ob Ihre Website mobil funktioniert, prüfen Sie mit einem Leistungsbericht und einem praktischen Test des vorgesehenen Ablaufs. Eine schnelle Seite kann eine unerreichbare Absenden-Schaltfläche haben. Ein responsives Layout kann trotzdem Formulareingaben verlieren.

Google hat den Mobile-Friendly-Test samt API im Dezember 2023 eingestellt. PageSpeed Insights, Lighthouse, Browseremulation und ein echtes Smartphone prüfen unterschiedliche Aspekte. Keines davon bestätigt allein, dass eine Website bedienbar, barrierefrei oder für gute Rankings gerüstet ist.

Wählen Sie wichtige Seiten und Abläufe

Beginnen Sie mit Startseite, einer wichtigen Produkt- oder Leistungsseite und einem Artikel. Nehmen Sie den tatsächlichen Kontakt-, Buchungs- oder Kaufablauf dazu, auch wenn er auf eine andere Domain führt. Prüfen Sie relevante Sprachen und Zustände: Erstbesuch mit Einwilligungsbanner, erneuter Besuch, geöffnetes Menü und Formular mit Fehlermeldung.

Unser kostenloser Mobile-Friendly-Checker eignet sich als erste Vorprüfung. Er untersucht abgerufenes HTML und Antwortinformationen auf Hinweise wie ein fehlendes Viewport-Tag, feste Inline-Breiten oder sehr kleine Inline-Schrift. Er rendert die Seite nicht, führt kein JavaScript aus und berechnet kein Layout anhand externer Stylesheets. Die HTML-Größe ist nicht die gesamte Downloadmenge, die Abrufzeit keine Ladezeit auf einem Smartphone. Bestätigen Sie Hinweise im Browser.

Lesen Sie die beiden PageSpeed-Ergebnisse getrennt

Öffnen Sie PageSpeed Insights, geben Sie die öffentliche URL ein und wählen Sie Mobil.

Die Felddaten stammen aus dem Chrome UX Report und betreffen die vergangenen 28 Tage. Achten Sie auf „Diese URL“ oder „Ursprung“. Reichen die URL-Daten nicht, kann PageSpeed auf den Ursprung zurückgreifen: Seiten mit gleichem Protokoll, Hostnamen und Port. Eine bestandene Bewertung für den Ursprung belegt keine bestandene Bewertung der einzelnen Seite. Fehlen auf beiden Ebenen genügend Daten, ist eine fehlende Bewertung kein Durchfallen.

Der Laborbereich enthält einen neuen Lighthouse-Test unter simulierten Bedingungen. Er hilft, eine langsame Ressource oder ein blockierendes Skript zu untersuchen. Sein Leistungswert ist von der Feldbewertung getrennt. Ein einzelner Navigationstest misst nicht den INP Ihrer Besucher. Google erläutert die Unterschiede.

Gespeicherten Mobilbericht vom 4. August 2026 in voller Größe öffnen (Ursprung ausgewählt; Core Web Vitals bestanden)

Dieses gespeicherte Beispiel zeigt Felddaten des Ursprungs: LCP 2,4 Sekunden, INP 112 Millisekunden und CLS 0. Ein Lighthouse-Leistungswert ist nicht abgebildet. Es verdeutlicht den Geltungsbereich eines Berichts und ist keine aktuelle Messung unserer Startseite.

Was die Core-Web-Vitals-Grenzen bedeuten

Die Einstufung verwendet das 75. Perzentil der jeweiligen Feldmessungen, nicht den Durchschnitt:

Für eine vollständige bestandene Bewertung müssen alle drei Messwerte gut sein. Bei unzureichenden INP-Daten kann PageSpeed dennoch „bestanden“ anzeigen, wenn LCP und CLS gut sind. Unzureichende LCP- oder CLS-Daten verhindern eine Bewertung. Diese dokumentierte PageSpeed-Regel ersetzt keine Interaktionstests.

Vergleichen Sie denselben Geltungsbereich

Öffnen Sie in der Search Console Core Web Vitals und den Mobilbericht. Prüfen Sie die betroffene Gruppe, ihren schlechtesten Messwert und die Beispiel-URLs. Google gruppiert Seiten mit ähnlicher Nutzererfahrung. Diese Gruppen entsprechen nicht zwangsläufig Ihren Seitenvorlagen. Reproduzieren Sie das Problem, bevor Sie eine gemeinsame Komponente dafür verantwortlich machen.

PageSpeed und Search Console können selbst beim Vergleich von Felddaten abweichen. Kontrollieren Sie URL, Ursprung oder Gruppe, Gerät, Erhebungszeitraum und URL-Behandlung. Search Console unterscheidet URL-Parameter; PageSpeed-Felddaten werden ohne diese Parameter zusammengefasst. Nicht jeder Unterschied ist deshalb „Labor gegen echte Nutzer“. Die Berichtsdokumentation erklärt die Abgrenzungen.

Prüfen Sie eine veröffentlichte Korrektur sofort mit denselben Browserschritten und Laboreinstellungen. Feldergebnisse verändern sich mit neuen Besuchen im rollenden Zeitraum. „Überwachung starten“ beginnt eine 28-tägige Validierung und erzwingt weder Crawling noch Neuindexierung. Angezeigte Daten können sich vorher verändern; die Validierung braucht dennoch ihren Überwachungszeitraum und genügend Daten.

Halten Sie Lighthouse-Einstellungen fest

Öffnen Sie die Seite in Chrome und anschließend DevTools. Wählen Sie Lighthouse und vor dem Test Mobil. Lokales Lighthouse kann angemeldete Seiten prüfen, die ein öffentlicher PageSpeed-Aufruf nicht erreicht. Die Lighthouse-Dokumentation beschreibt die Möglichkeiten.

Speichern Sie Bericht, Datum, URL, Lighthouse-Version, Geräteprofil, Drosselung und getestete Seitenversion. Vergleichen Sie Änderungen unter gleichen Bedingungen und wiederholen Sie überraschende Ergebnisse. Rechner, Browser, Einwilligungszustand und Konfiguration können die Messung verändern. Eine manuelle CPU-Drosselung in DevTools bildet PageSpeeds Simulation nicht automatisch nach.

Labortests mit der PageSpeed-API automatisieren

Dieser Bash-Befehl fordert mobile Diagnosen für Leistung, Barrierefreiheit und SEO an. Ersetzen Sie die Beispiel-URL durch eine öffentliche Seite:

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Verwenden Sie unter Windows für diese mehrzeilige Syntax ein Bash-Terminal. Googles Einstiegsleitfaden dokumentiert den Zugang und empfiehlt für häufige automatische Abfragen einen Schlüssel. Prüfen Sie das Projektkontingent vor geplanten Serien. Ein HTTP-Fehler, etwa wegen eines Kontingents, bedeutet nicht, dass die Seite beim Audit durchgefallen ist.

Lesen Sie innerhalb von lighthouseResult die Felder categories und audits; ein Kategoriewert von 0.92 bedeutet 92 von 100. Speichern Sie fetchTime, lighthouseVersion, requestedUrl, finalUrl und configSettings. Behandeln Sie runtimeError, bevor Sie das Ergebnis akzeptieren. Die Antwortreferenz beschreibt die Felder. Für laufende Feldmessungen empfiehlt Google CrUX API oder CrUX History API, da CrUX-Daten künftig nicht mehr Teil der PageSpeed-API sein sollen.

Testen Sie die Aufgabe im Browser und am Smartphone

Aktivieren Sie die Geräteleiste in DevTools und beginnen Sie mit 360 × 800 und 390 × 844 CSS-Pixeln. Ändern Sie die Breite schrittweise und prüfen Sie das Querformat. Der Gerätemodus ist eine Annäherung. Testen Sie abschließend auf echten Geräten und relevanten Browsern, gegebenenfalls auch Safari auf dem iPhone.

• Öffnen und schließen Sie Navigation, Einwilligungseinstellungen und Dialoge. Fixierte Kopfzeilen und Banner dürfen Inhalte oder Bedienelemente nicht verdecken.
• Lesen Sie lange Überschriften, Tabellen und Übersetzungen. Prüfen Sie Zoom und schmale Ansichten. Das Umbruchkriterium der Richtlinien für barrierefreie Webinhalte (WCAG) verwendet für vertikal scrollende Inhalte 320 CSS-Pixel, entsprechend einem 1280-Pixel-Viewport bei 400 % Zoom. Echte zweidimensionale Tabellen haben eine Ausnahme: Erhalten Sie lesbare Inhalte und bedienbares Scrollen, statt Überlauf zu verstecken.
• Tippen Sie benachbarte Bedienelemente an und verwenden Sie, soweit unterstützt, eine Tastatur. Das WCAG-2.2-AA-Kriterium zur Zielgröße nennt 24 × 24 CSS-Pixel mit Abstands- und weiteren Ausnahmen. Größere Flächen, etwa 48 × 48, können angenehmer sein. Keine dieser Zahlen belegt allein die Erfüllung der Barrierefreiheitsanforderungen.
• Füllen Sie Formulare bei geöffneter Bildschirmtastatur aus. Prüfen Sie Beschriftung, Fokus, Fehler, erhaltene Eingaben, Versand und Bestätigung. Verwenden Sie für Käufe oder Buchungen eine freigegebene Testumgebung und kontrollieren Sie den zugehörigen Beleg oder Datensatz.
• Wiederholen Sie den Ablauf über eine relevante Mobilfunkverbindung. Bei Verzögerungen oder fehlgeschlagenen Anfragen muss ein klarer Weg zum Fortsetzen bleiben.

Ein hilfreicher Fehlerbericht ist konkret. Hypothetisches Beispiel: „Auf der Buchungsseite bei 390 × 844 verdecken Tastatur und Einwilligungsbanner die Absenden-Schaltfläche. Die Seite scrollt, der Button bleibt aber unerreichbar.“ Ergänzen Sie URL, Browser, Gerät, Zustand, Schritte, Screenshot, erwartetes Ergebnis und zuständige Person. Eine blockierte Buchung verdient Aufmerksamkeit, auch bei grünem Leistungswert.

Beheben Sie die gemessene Ursache

Ermitteln Sie bei langsamem LCP das tatsächliche größte Element und die Ursache seiner Verzögerung. Ist es ein Bild, machen Sie es früh auffindbar und laden Sie es nicht verzögert. Nutzen Sie Preload nur, wenn eine Ressource früher entdeckt werden muss, nicht pauschal für alle Bilder und Schriften. Googles LCP-Leitfaden erklärt den Unterschied.

Zeichnen Sie langsame Interaktionen auf und untersuchen Sie blockierende Arbeit. Reduzieren Sie unnötige Skriptausführung oder teilen Sie lange Aufgaben auf, während nötige Funktionen und Einwilligung erhalten bleiben. Reservieren Sie gegen Layoutverschiebungen Platz für Bilder, Einbettungen und eingefügte Inhalte. Die Leitfäden zu INP und CLS helfen bei diesen unterschiedlichen Problemen.

Testen Sie in WordPress oder Shopify Änderungen an Theme oder App in einer Testumgebung mit gleichem Inhalt und Ablauf. Messen Sie die Wirkung, bevor Sie jedes Plugin verantwortlich machen oder einen Neuaufbau vorschlagen. Manche Lösungen sind Einstellungen, andere betreffen Komponenten. Unsere Website-Optimierung hilft bei Diagnose und Umsetzung, ergänzt durch Website-Entwicklung, wenn Codeänderungen nötig sind.

Trennen Sie Indexierung und Bedienbarkeit

Google empfiehlt responsives Design für Mobile-First-Indexierung, unterstützt aber auch andere mobile Konfigurationen. Stellen Sie sicher, dass Googlebot mobile Inhalte, Bilder und Metadaten erreicht. Eine bedienbare Seite kann trotzdem ein Indexierungsproblem haben, das eine eigene SEO-Untersuchung erfordert.

Core Web Vitals fließen in Googles Rankingsysteme ein. Gute Werte garantieren jedoch keine hohen Positionen, und ein schlechter Wert belegt allein keine Abstrafung. Googles Hinweise zur Seitenerfahrung ordnen sie in den gesamten Nutzen einer Seite ein.

Halten Sie fest, welches Problem gefunden, welche Änderung veröffentlicht und welche Aufgabe erfolgreich nachgetestet wurde. Kennzeichnen Sie ausstehende Feldvalidierung. Prüfen Sie betroffene Abläufe nach Änderungen an Theme, App, Formular oder Tags erneut. Eine bestandene automatische Prüfung und eine erfolgreich erledigte Nutzeraufgabe sind getrennte Nachweise.