Mobile Website-Probleme: Warum Anfragen fehlen

Ihre Kunden suchen unterwegs, vergleichen am Smartphone und öffnen Angebote oft mit einer anderen Verbindung als Sie im Büro. Ein schneller Desktop-Test reicht deshalb nicht, um die mobile Erfahrung zu beurteilen.

Was «zu langsam» wirklich bedeutet

Ladezeit ist kein einzelner Zeitpunkt. Kunden müssen den Hauptinhalt sehen, Bedienelemente nutzen und ein stabiles Layout vorfinden. Die Core Web Vitals beschreiben diese drei Aspekte. Ihre Grenzwerte sind Orientierung für die Nutzererfahrung, keine Formel für garantierte Anfragen.

— web.dev: Core Web Vitals

Ein Labortest unter festgelegten Bedingungen hilft bei der Fehlersuche. Felddaten beschreiben dagegen tatsächlich erfasste Nutzung. Bei wenig Traffic können öffentliche Felddaten fehlen. Das bedeutet weder, dass Ihre Website schnell ist, noch dass sie langsam ist.

— Chrome: Voraussetzungen für CrUX-Felddaten

Welche Ursachen Sie zuerst prüfen sollten

Grosse Bilder, externe Einbettungen, schlecht ausgelieferte Schriftarten und umfangreiche Skripte können den Seitenaufbau verzögern. Plugins sind ein möglicher Verursacher, aber ihre Anzahl allein ist keine Diagnose. Entscheidend ist, welche Dateien und Aufgaben die konkrete Seite tatsächlich benötigt.

JavaScript-Aufgaben über 50 Millisekunden gelten als lange Aufgaben. Solange der Hauptthread mit einer solchen Aufgabe beschäftigt ist, kann er andere Arbeit nicht gleichzeitig erledigen. Im Performance-Profil lässt sich erkennen, welches Skript die Bedienung verzögert. Eine pauschale Aussage, eine Website drossele den Smartphone-Prozessor um einen festen Prozentsatz, wäre daraus nicht ableitbar.

— web.dev: lange Aufgaben aufteilen

Was die CMS-Vergleiche tatsächlich zeigen

Der Web Almanac 2024 vergleicht in Abbildung 12.7 mobile Core-Web-Vitals-Ergebnisse verschiedener CMS. Die folgende Auswahl zeigt gerundete Bestehensquoten aus dieser historischen Auswertung. Sie beschreibt erfasste Websites der jeweiligen Technologie, keinen repräsentativen Schweizer KMU-Durchschnitt und keine Messung aus 2026.

Die Daten beruhen auf CrUX und dem Core Web Vitals Technology Report. Sie belegen Unterschiede zwischen den erfassten Gruppen, aber keinen garantierten Effekt eines Systemwechsels. Diese Abbildung enthält keine Vergleichsquote für statische Generatoren. Für eine konkrete Entscheidung zählt die geprüfte Umsetzung Ihrer Website.

— HTTP Archive: Web Almanac, Kapitel CMS, Abbildung 12.7, 2024

Springende Layouts gezielt vermeiden

Wenn sich ein Button kurz vor dem Tippen verschiebt, kann ein Kunde das falsche Ziel treffen. Häufige Ursachen sind Bilder ohne reservierte Fläche, nachgeladene Schriften oder verspätet eingeblendete Widgets. Bilder brauchen definierte Abmessungen; dynamische Elemente sollten ihren Platz erhalten, bevor sie sichtbar werden.

— web.dev: Layoutverschiebungen reduzieren

Eine sauber entwickelte Website berücksichtigt diese Anforderungen bereits beim Aufbau. Dennoch bleibt die Prüfung auf echten Geräten nötig: Neue Bilder, eingebettete Dienste und spätere Inhaltsänderungen können die Erfahrung verändern.

Weniger unnötiger Code erleichtert die Pflege

Individuelle Entwicklung erlaubt, Funktionen und geladene Dateien eng auf den Bedarf abzustimmen. Sie ist aber kein automatischer Performance-Nachweis. Auch eigener Code muss gemessen werden. Umgekehrt kann eine sorgfältig konfigurierte CMS-Seite gut funktionieren.

Ein umfangreicher DOM-Baum kann Layout- und Darstellungsarbeit verteuern. Die früher verbreiteten Lighthouse-Grenzen von ungefähr 800 beziehungsweise 1’400 Elementen gehören zum älteren Audit. Seit Lighthouse 13 wird das Thema im Insight zur DOM-Grösse behandelt. Eine feste Elementzahl allein beschreibt deshalb nicht die heutige Gesamtbewertung.

— Chrome: DOM-Grösse und Ablösung des bisherigen Audits

Sicherheit gehört zur technischen Qualität

Patchstack dokumentiert im Bericht von 2025 für das Jahr 2024 insgesamt 7’966 neue Schwachstellen im WordPress-Ökosystem; laut Bericht entfielen rund 96 Prozent auf Plugins. Das ist eine Verteilung gemeldeter Schwachstellen, keine Wahrscheinlichkeit dafür, dass Ihre Website gehackt wird. Auswahl, Updates und Betrieb bleiben wichtig.

— Patchstack: State of WordPress Security in 2025, Datenjahr 2024, 2025

Eine rein statische Auslieferung braucht kein öffentliches CMS-Login und keine Datenbank für die Seitenanzeige. Hostingzugänge, Abhängigkeiten, eingebundene Dienste und Formular-Endpunkte bleiben trotzdem schutzbedürftig. Statisch bedeutet nicht unangreifbar. Die laufenden Kosten der Website sollten diese Pflege berücksichtigen.

So priorisieren Sie Verbesserungen

Prüfen Sie zuerst die mobile Nutzung Ihrer wichtigsten Seiten: Wird das Angebot verständlich angezeigt? Reagieren Navigation und Kontaktformular? Bleibt das Layout stabil? Ordnen Sie danach Messwerte dem konkreten Problem zu und prüfen Sie denselben Ablauf nach der Änderung erneut.

Für geschäftliche Wirkung vergleichen Sie die tatsächlich erfassten Anfragen bei ähnlicher Herkunft und Geräteverteilung. Kleine Stichproben bleiben unsicher. Eine gute Ladezeit ist ein Qualitätsziel; die Zahl zusätzlicher Kunden lässt sich daraus nicht versprechen.