Warum Ihre Website am Handy zu langsam ist

Sie öffnen Ihre eigene Website am Handy, im mobilen Netz, so wie es die meisten Ihrer Besucher tun. Die Startseite baut sich auf, aber es dauert. Erst eine leere Fläche, dann ruckelt das Bild rein, dann verschiebt sich der Text noch einmal, weil eine Schriftart nachlädt. Sie tippen auf „Kontakt" und es passiert für einen Moment gar nichts. Am Bürocomputer, mit schnellem WLAN, war davon nie etwas zu merken.

Genau das ist das Problem. Die meisten Websites werden am Desktop gebaut und am Desktop abgenommen. Getestet wird selten dort, wo die meisten Besucher tatsächlich ankommen: unterwegs, am Handy, mit einer Verbindung, die mal gut und mal mittelmäßig ist. Dieser Beitrag erklärt, warum das passiert, was es für Ihr Google-Ranking und für Ihre Besucher bedeutet, und wie Sie es in fünf Minuten selbst nachmessen.

TL;DR: Eine langsame mobile Website ist selten ein Server-Problem, sondern meistens die Summe vieler kleiner Bremsen: zu viele Plugins, unkomprimierte Bilder, nachladende Skripte. Google misst das über Kennzahlen namens Core Web Vitals und lässt sie in die Suchplatzierung einfließen. Mit PageSpeed Insights können Sie in fünf Minuten selbst sehen, wo Ihre Website steht.

Warum am Handy alles langsamer wird

Ein Smartphone unterwegs hat weniger Rechenleistung als ein Bürocomputer und oft eine schlechtere Verbindung als das Büro-WLAN. Das allein wäre nicht dramatisch, wenn Websites für dieses schwächere Gerät gebaut würden. Meistens ist es umgekehrt: Die Seite schickt am Handy denselben Ballast wie am Desktop, nur dass das Handy länger braucht, um ihn zu verarbeiten.

Der Ballast hat bei den meisten Websites, die auf einem Baukasten oder einem Plugin-lastigen Content-Management-System aufgebaut sind, dieselben vier Quellen.

Render-blockierende Skripte. Das sind Programmcode-Dateien (JavaScript), die der Browser laden und ausführen muss, bevor er den sichtbaren Inhalt der Seite überhaupt zeichnen darf. Je mehr davon vor dem eigentlichen Inhalt geladen werden, desto länger starrt der Besucher auf eine leere oder halb aufgebaute Seite.

Unkomprimierte Bilder. Ein Foto direkt von der Kamera oder aus einer Bilddatenbank ist oft mehrere Megabyte groß, obwohl es auf dem Bildschirm nur wenige hundert Pixel breit angezeigt wird. Ohne Komprimierung lädt der Browser die volle Datei, nur um sie dann kleinzurechnen.

Web-Schriftarten. Viele Websites laden eine eigene Schriftart von einem externen Server nach, statt eine Schrift zu verwenden, die auf dem Gerät schon vorhanden ist. Bis diese Datei angekommen ist, zeigt der Browser entweder eine Ersatzschrift oder gar nichts, und wenn die eigentliche Schrift dann eintrifft, springt der Text sichtbar an eine neue Position.

Eingebettete Drittanbieter-Inhalte. Ein YouTube-Video, eine Landkarte, ein Live-Chat-Fenster oder ein Cookie-Banner-Anbieter lädt jeweils eigenen Code von einem fremden Server nach. Jede dieser Einbindungen ist für sich harmlos, in Summe auf einer einzigen Seite aber oft der größte einzelne Bremsklotz.

Die vierte, oft unterschätzte Quelle ist das technische Fundament selbst: Viele Baukasten- und Plugin-Systeme laden erst ihr eigenes Grundgerüst, bevor überhaupt der erste Baustein Ihrer eigentlichen Seite an der Reihe ist. Dieses Grundgerüst sehen Ihre Besucher nie, aber sie warten trotzdem darauf, im Hintergrund, bevor irgendetwas von Ihrem Inhalt erscheint.

Was das für Google bedeutet

Google misst, wie sich eine Website für echte Besucher anfühlt, mit drei Kennzahlen, den sogenannten Core Web Vitals. Zwei davon sind für eine langsame mobile Website am relevantesten.

LCP (Largest Contentful Paint) misst, wie lange es dauert, bis das größte sichtbare Element der Seite, meist ein Bild oder eine Überschrift, tatsächlich angezeigt wird. Nach Googles eigener Einteilung gilt ein Wert bis 2,5 Sekunden als gut, über 4 Sekunden als schlecht.

INP (Interaction to Next Paint) misst, wie lange es dauert, bis die Seite sichtbar reagiert, nachdem jemand getippt oder geklickt hat. Ein Wert bis 200 Millisekunden gilt als gut, über 500 Millisekunden als schlecht. Genau dieser Wert leidet am meisten unter zu vielen gleichzeitig laufenden Skripten, weil der Browser beschäftigt ist, während der Besucher schon auf einen Button tippt.

Diese Werte sind kein reiner Komfortfaktor. Google selbst schreibt, dass sie mit anderen Aspekten der Nutzererfahrung zusammen in die Bewertung einer Seite einfließen, die die eigenen Ranking-Systeme belohnen wollen. Für Sie heißt das praktisch: Eine langsame mobile Seite konkurriert bei gleichem Inhalt gegen eine schnellere Seite eines Mitbewerbers und hat es dabei schwerer, weit oben zu erscheinen.

Was das für Ihre Besucher bedeutet

Für den Besucher ist die Kennzahl egal, das Gefühl zählt. Eine Seite, die sichtbar hängt, wenn er tippt, wirkt unzuverlässig, egal wie gut das Angebot dahinter ist. Bei einem Handwerksbetrieb, einer Kanzlei oder einer Ordination ist das besonders heikel, weil Vertrauen genau der Faktor ist, den die Website eigentlich aufbauen soll. Eine ruckelnde Seite sät im ersten Moment schon Zweifel, bevor der Besucher überhaupt gelesen hat, was Sie anbieten.

Der zweite Effekt ist der Absprung. Wer auf ein Suchergebnis tippt und lange auf eine leere Fläche starrt, geht häufig zurück zur Suche und klickt das nächste Ergebnis an, oft ein Mitbewerber. Diese Person taucht in keiner Statistik als „wegen Ladezeit verloren" auf, sie ist einfach nicht mehr da.

So messen Sie das selbst, in fünf Minuten

Sie brauchen dafür nichts zu installieren und kein technisches Wissen. Nur Ihr Handy oder einen Computer mit Internetzugang.

1. Öffnen Sie PageSpeed Insights. Rufen Sie pagespeed.web.dev auf, das offizielle, kostenlose Mess-Tool von Google.
2. Geben Sie Ihre Web-Adresse ein. Am besten die Startseite und danach noch eine Unterseite, die Ihnen wichtig ist, etwa die Kontaktseite oder eine Leistungsseite.
3. Warten Sie auf das Ergebnis und öffnen Sie den Reiter „Mobil". Der Bericht zeigt getrennte Werte für Handy und Computer. Der mobile Wert ist der, der für die meisten Ihrer Besucher zählt.
4. Schauen Sie sich nur die Farbe der obersten Zahl an. Grün heißt gut, Orange heißt verbesserungswürdig, Rot heißt schlecht. Sie müssen die Details nicht verstehen, um zu sehen, ob hier Handlungsbedarf besteht.
5. Scrollen Sie zu „Core Web Vitals-Bewertung". Dort stehen LCP und INP als eigene Zeilen mit demselben Ampelsystem. Rot bei einem der beiden ist ein klares Signal, dass Besucher das im Alltag auch spüren, nicht nur das Messgerät.

Ein einziger Test ist eine Momentaufnahme. Wenn Sie unsicher sind, wiederholen Sie ihn zwei, drei Mal an unterschiedlichen Tagen. Bleibt das Ergebnis konstant im roten oder orangen Bereich, ist das kein Ausreißer, sondern der Normalzustand Ihrer Seite.

Was sich tunen lässt, und was nicht

Nicht jedes rote Ergebnis braucht denselben Aufwand. Die folgende Übersicht ordnet die häufigsten Ursachen danach ein, ob sie sich innerhalb der bestehenden Website beheben lassen oder ein grundlegenderes Problem anzeigen.

Ursache	Tunbar innerhalb der Website	Braucht meist einen Neuaufbau
Unkomprimierte Bilder	Ja, Bilder verkleinern und in moderne Formate umwandeln
Zu viele Plugins gleichzeitig aktiv	Teilweise, ungenutzte Plugins entfernen	Ja, wenn die verbleibenden Plugins sich gegenseitig ausbremsen
Web-Schriftart lädt zu spät	Ja, Schriftart optimieren oder Systemschrift verwenden
Einzelnes Drittanbieter-Skript (z. B. Kartenembed)	Ja, erst laden, wenn der Besucher scrollt oder klickt
Das Grundgerüst des Baukastens/CMS selbst		Ja, das lässt sich nicht wegkonfigurieren
Server dauerhaft überlastet	Teilweise, besseres Hosting-Paket	Ja, wenn viele Websites denselben Server teilen

Der entscheidende Unterschied: Bilder, einzelne Skripte und Schriftarten sind Stellschrauben. Man dreht daran, und die Seite wird spürbar schneller, oft innerhalb weniger Stunden Arbeit. Das technische Fundament selbst, also ein Baukasten mit einem Dutzend Plugins, die sich gegenseitig zur Ladezeit hochschaukeln, ist keine Stellschraube. Da hilft kein einzelnes Bild-Komprimieren mehr, weil das Grundproblem im Aufbau der Seite liegt, nicht in einer einzelnen Datei.

Woran Sie erkennen, in welcher Kategorie Sie stehen: Wenn Sie in PageSpeed Insights unter „Diagnose" oder „Verbesserungsmöglichkeiten" hauptsächlich Hinweise zu einzelnen Bildern oder Skripten sehen, ist Tuning der richtige Weg. Wenn dort viele verschiedene Plugins und Bibliotheken gleichzeitig auftauchen, deren Namen Sie noch nie bewusst installiert haben, ist das ein Hinweis auf das Grundproblem im Fundament.

Wann sich ein Neuaufbau lohnt

Ein Neuaufbau ist kein Ziel für sich, er lohnt sich nur dann, wenn Tuning die Kennzahlen strukturell nicht mehr bewegt. Das ist typischerweise der Fall, wenn eine Website über Jahre gewachsen ist, mit einem Plugin für jede neue Anforderung, ohne dass jemals wieder etwas entfernt wurde. Jedes einzelne Plugin ist dann für sich erklärbar, in Summe bremsen sie sich gegenseitig aus.

Eine schlank gebaute Website ohne diesen Unterbau muss von Grund auf nicht dasselbe Gewicht mitschleppen. Wie ein solcher Aufbau technisch abläuft und was er in der Praxis dauert, steht unter Website in 5 Werktagen.

Ob Ihre eigene Website eher ein Tuning- oder ein Neuaufbau-Fall ist, lässt sich in den allermeisten Fällen schon am PageSpeed-Insights-Ergebnis erkennen, so wie oben beschrieben. Wenn Sie unsicher sind, wie das bei Ihnen konkret aussieht, ist das auch eine gute erste Frage für ein Gespräch, ganz ohne Verpflichtung.

Wenn Sie ohnehin gerade wiederkehrende Abläufe rund um Ihre Website und Anfragen anschauen, etwa wie Kontaktformulare weiterverarbeitet werden, lohnt sich auch ein Blick in Prozesse automatisieren im KMU.

Quellen: web.dev: LCP, web.dev: INP, Google Search Central: Core Web Vitals, PageSpeed Insights