Schnelle Website auf dem Smartphone: Wie ich den Wert von 61 auf 93 gesteigert habe

Ich entwerfe schnelle Websites, da sollte meine eigene auch schnell sein. Die Messung in Google PageSpeed Insights zeigte auf dem Smartphone aber 61–70 Punkte, und der Hauptinhalt erschien erst nach 5,8 Sekunden. Auf dem Computer sah es gut aus, doch die meisten Menschen rufen Websites vom Smartphone aus auf.

Unten beschreibe ich, was die Website genau ausgebremst hat und wie ich es behoben habe. Die Probleme, die ich gefunden habe, treten auf sehr vielen Firmenwebsites auf, auch auf solchen, die auf WordPress aufgebaut sind.

Ergebnis: vorher und nachher

Auf dem Computer erreicht die Website jetzt 100 Punkte. Und das alles, ohne Animationen zu entfernen und ohne auf den interaktiven Editor oben auf der Seite zu verzichten.

Schritt 0: Messen, bevor Sie verbessern

PageSpeed Insights simuliert ein Smartphone der Mittelklasse mit langsamem mobilem Internet. Das ist eine gute Annäherung, aber die Punktzahl allein sagt wenig. Entscheidend ist die Frage: Welches Element hält Google für den Hauptinhalt, und warum erscheint es so spät?

Die Antwort hat mich überrascht. Google hat nicht die Überschrift der Seite gemessen, sondern ein Foto in der Demonstration des Editors, das nach etwa 6 Sekunden erschien. Die Datei wurde blitzschnell geladen, doch die Animation, die die Website aufbaut, hat sie erst nach einer ganzen Weile sichtbar gemacht. Ohne die genaue Messung hätte ich das Problem an einer ganz anderen Stelle gesucht.

1. Eine Animation, die den Hauptinhalt verzögerte

Als Hauptinhalt (LCP) betrachtet Google das größte auf dem Bildschirm sichtbare Element. Wenn etwas Großes spät erscheint, und sei es im Rahmen einer effektvollen Animation, sinkt das gesamte Ergebnis.

Auf meiner Website kamen dafür zwei Dinge zusammen:

• Die Demo zum Aufbau der Website startete zu früh. Auf dem Smartphone begann sie, wenn 75 % des Editors noch unterhalb des Bildschirms lagen. Jetzt startet sie, wenn der Editor etwa bis zur Bildschirmmitte hereingescrollt ist. Das ist auch für Besuchende besser, denn sie sehen den gesamten Aufbau und nicht nur sein Ende.
• Die Überschrift bestand für Google aus mehreren kleinen Stücken. Jede Zeile der Überschrift war ein eigener Block, und die Animation hat sie zusätzlich in einzelne Wörter zerlegt. Für Google sind das mehrere kleine Elemente statt eines großen. Nach der Änderung ist die Überschrift ein einziger Textblock und zählt vom ersten Moment an.

Außerdem habe ich die Einblend-Animation von JavaScript in CSS verlegt. Früher erschien der Inhalt, verschwand nach dem Laden der Skripte und fuhr erneut herein. Jetzt startet die Animation zusammen mit der ersten Darstellung der Seite, und die Überschrift wird scharf, statt aus der Transparenz aufzutauchen.

2. Springen beim Laden der Schriften

Die Website verwendet zwei Schriften: die serifenlose Geist und die dekorative Kursivschrift Cormorant. Bevor sie geladen sind, zeigt der Browser den Text in einer Ersatzschrift, zum Beispiel Arial. Die Ersatz-Kursivschrift war um 17 % breiter als die richtige, die Überschrift wurde deshalb anders umgebrochen, und nach dem Austausch der Schrift sprang der gesamte Inhalt darunter.

Die Lösung sind Fallback-Schriften mit angepassten Maßen. CSS erlaubt es, Arial und Times New Roman so zu skalieren, dass sie genauso viel Platz einnehmen wie die richtigen Schriften (die Eigenschaften size-adjust, ascent-override und descent-override). Ich habe beide Schriften ausgemessen, und der Breitenunterschied sank von 17 % auf 2 %. Die Layoutverschiebung ging auf null zurück.

3. Zu viele Dateien, die die Darstellung blockieren

Bevor der Browser irgendetwas anzeigt, muss er alle Stylesheets aus dem Header der Seite laden. Bei mir waren es fünf: die Styles der Seite, die Schriften, zwei Icon-Sets und die Styles für sanftes Scrollen. Bei langsamem Internet bedeutet jede Datei eine eigene Verzögerung.

Die Korrekturen:

• Eine CSS-Datei statt fünf. Das Zusammenfügen geschieht automatisch bei der Veröffentlichung der Website, im Quellcode liegen die Dateien weiterhin getrennt.
• Skripte mit dem Attribut defer. Sie werden parallel geladen und in derselben Reihenfolge ausgeführt, halten aber die erste Darstellung nicht auf.
• Chat-Styles werden im Hintergrund geladen. Der Chat-Button erscheint ohnehin erst, nachdem die Skripte geladen sind.

4. Icons: 1500 in der Datei, 135 in Benutzung

Die Icons auf der Website stammen aus der Bibliothek Phosphor und werden als Schrift geladen. Die vollständigen Dateien enthielten rund 1500 Icons und wogen zusammen 280 KB. Ich verwende 135.

Bei der Veröffentlichung sucht die Website die verwendeten Icons selbst heraus und kürzt die Stylesheet- und Schriftdateien auf sie. Übrig blieben 28 KB, also zehnmal weniger. Die Icons sehen genauso aus, und wenn ich ein neues hinzufüge, landet es bei der nächsten Veröffentlichung automatisch in der Datei.

5. Fotos: richtige Größe und richtiges Format

Das ist das häufigste Problem von Firmenwebsites, und bei mir war es auch das größte:

• Die Fotos in den Karten waren 1440 px breit, wurden aber in Rahmen mit einer Breite von 285–557 px angezeigt. Jetzt bekommen die Karten WebP-Versionen mit 800 px Breite. Große Karten können über das Attribut srcset bei hochauflösenden Bildschirmen weiterhin auf das volle Foto zugreifen. Allein die Fotos von Projekten wurden von 2,9 MB auf 0,9 MB abgespeckt.
• Lazy Loading funktioniert nicht immer. Die Fotos hatten loading="lazy", der Browser lud sie aber trotzdem sofort. Beim ersten Seitenaufbau, bevor die Skripte die weiter oben liegenden Sektionen gebaut hatten, lagen sie nahe am Seitenanfang. Die Lösung war, die Dateien zu verkleinern und bewusst zu steuern, wann was geladen wird.
• Die Demo lud vorsorglich Fotos für fünf Branchen. Jetzt lädt sie die Fotos der aktuellen Branche kurz vor dem Aufbau, die übrigen erst dann, wenn die Vorführung tatsächlich zwischen den Branchen wechselt. Ersparnis: etwa 1,6 MB bei jedem Aufruf.

Bonus: Die Seite scrollte beim Aktualisieren von selbst

Nebenbei kam ein kleiner, aber lästiger Fehler ans Licht: Nach dem Aktualisieren öffnete sich die Seite leicht nach unten gescrollt. Der Browser merkt sich die Scrollposition relativ zu einem bestimmten Element. Bei mir bauen die Skripte nach dem Laden die halbe Seite auf, dieses Element landete dadurch weiter unten, und die Seite sprang um 80–180 px.

Jetzt beginnt das Aktualisieren immer oben, und der „Zurück“-Button kehrt genau an dieselbe Stelle zurück, weil sich die Seite die Position selbst merkt.

Was das für Ihre Website bedeutet

Auf den Firmenwebsites, die ich prüfe, wiederholen sich meistens dieselben Ursachen:

1. Fotos direkt aus der Kamera oder aus Bilddatenbanken, mehrere Megabyte groß, statt Dateien, die an den Platz auf der Seite angepasst sind.
2. Ein Slider oder Video oben auf der Seite, das verzögert erscheint und in den Augen von Google zum Hauptinhalt wird.
3. Ein schweres Theme und ein Dutzend Plugins, von denen jedes auf jeder Unterseite eigene Styles und Skripte beisteuert.
4. Mehrere Schriftarten ohne angepasste Ersatzschriften, wodurch der Text springt.
5. Fehlende Messung. Ohne zu prüfen, welches Element der Hauptinhalt ist, verbessert man leicht das Falsche.

Die Prüfung dauert eine halbe Minute: Geben Sie die Adresse im Tool Website prüfen ein, und Sie erhalten den Geschwindigkeitswert von Google zusammen mit einer Liste konkreter Ursachen.

Was es kostet, eine Website zu beschleunigen

Kleine Korrekturen wie Bildkompression, Ordnung bei den Plugins und Servereinstellungen erledige ich im Rahmen der technischen Betreuung ab 149 PLN pro Monat. Wenn die Website auf einem schweren Theme läuft und die Korrekturen mehr kosten würden als eine neue Version, kostet die Website-Modernisierung ab 2.900 PLN. Alle Preise sind netto.

Prüfen wir Ihre Website

Prüfen Sie Ihre Website kostenlos und schicken Sie mir den Bericht unter dem Ergebnis, oder schreiben Sie mir über das Formular. Ich antworte in 24 Stunden, was Ihre Website ausbremst und was die Verbesserung kostet. Neukunden erhalten 20 % Rabatt auf den ersten Auftrag.