Astro-Website-Qualitätsverbesserungsleitfaden — PageSpeed Mobile Score von 99 erreichen
Table of Contents
Einleitung
Die offizielle Acecore-Website, die im März 2026 neu gestartet wurde, wurde mit Astro 6 + UnoCSS + Cloudflare Pages erstellt. Die frisch gestartete Website war jedoch bestenfalls auf dem Niveau „es funktioniert” — mit Verbesserungspotenzial in den Bereichen Performance, SEO, Barrierefreiheit und UX.
Dieser Artikel fasst den Weg durch über 150 Verbesserungen zusammen, um PageSpeed Insights Mobile 99 und perfekte 100 Punkte bei allen Desktop-Metriken zu erreichen.
Die PageSpeed Mobile 99-Herausforderung
Zunächst ist festzuhalten, dass ein hoher Score bei PageSpeed Insights Mobile viel schwieriger ist, als man erwarten würde.
Die Mobile-Simulation von Lighthouse
PageSpeed Insights führt im Hintergrund Lighthouse aus und wendet für Mobile-Tests folgendes Throttling an:
| Einstellung | Wert |
|---|---|
| Download-Geschwindigkeit | ~1,6 Mbit/s (langsames 4G) |
| Upload-Geschwindigkeit | ~0,75 Mbit/s |
| Latenz | 150 ms (RTT) |
| CPU | 4-fache Verlangsamung |
Das bedeutet, dass selbst eine Seite, die mit Glasfaserverbindung in 1 Sekunde lädt, unter Lighthouses Simulation 5–6 Sekunden benötigt. Das Laden von 200 KiB CSS allein verursacht bei langsamem 4G etwa 1 Sekunde Blockierung.
Nichtlineare Bewertungsskalierung
PageSpeed-Bewertungen sind nicht linear:
- 50 → 90: Erreichbar mit grundlegenden Optimierungen (Bildkomprimierung, Entfernung unnötiger Skripte)
- 90 → 95: Erfordert strategische CSS-, Schrift- und Bildlieferung
- 95 → 99: Tuning im Millisekundenbereich. Entscheidungen zwischen CSS-Inlining und externen Dateien werden kritisch
- 99 → 100: Beeinflusst durch externe CDN-Antwortzeiten und Lighthouses eigene Messvarianz. Extrem schwierig für Websites mit AdSense oder GA4 konsistent zu erreichen
Bewertungsvarianz
Selbst für dieselbe Website können die Bewertungen zwischen den Messungen um 2–5 Punkte schwanken. Ursachen sind:
- Bild-CDN-Antwortzeiten (z.B. wsrv.nl)
- Cloudflare Pages Edge-Server-Cache-Status
- Lighthouses eigener Messfehler
Aus diesem Grund sollte das Ziel „konsistent hohe Bewertungen bei wiederholten Messungen” sein, nicht „einmal 100 Punkte erzielen.”
Endergebnisse
Trotz dieser Herausforderungen konnten wir konsistent folgende Bewertungen erzielen:
| Metrik | Mobile | Desktop |
|---|---|---|
| Performance | 99 | 100 |
| Barrierefreiheit | 100 | 100 |
| Best Practices | 100 | 100 |
| SEO | 100 | 100 |
Vier Säulen der Verbesserung
Die Verbesserungen wurden in vier Hauptkategorien organisiert, wobei jedes Thema in separaten Artikeln detailliert behandelt wird.
1. Performance
Die Performance-Optimierung trug am meisten zum Erreichen von Mobile 99 bei. Wir haben Engpässe systematisch beseitigt: CSS-Lieferstrategie (Inline vs. extern), Schriftart-Selbst-Hosting, responsive Bildoptimierung und verzögertes Laden von AdSense/GA4.
Die drei wirkungsvollsten Änderungen:
- CSS-Externalisierung: Der Wechsel von 190 KiB inline CSS zu einer externen Datei reduzierte die HTML-Übertragungsgröße um bis zu 91%
- Behebung der Schriftart-Namensdiskrepanz:
@fontsource-variable/noto-sans-jpregistriert den SchriftnamenNoto Sans JP Variable, aber CSS referenzierteNoto Sans JP— diese Diskrepanz wurde entdeckt und behoben - Responsive Bilder:
srcset+sizesauf allen Bildern gesetzt, um für Mobile angemessen dimensionierte Bilder auszuliefern
2. SEO
Zur Unterstützung von Googles Rich Results haben wir 7 Typen von JSON-LD strukturierten Daten implementiert. In Kombination mit OGP-Meta-Tags, kanonischen URLs, Sitemap-Optimierung und RSS-Feed-Verbesserungen haben wir eine Grundlage geschaffen, um die Website-Struktur akkurat an Suchmaschinen zu kommunizieren.
3. Barrierefreiheit
PageSpeed Barrierefreiheit 100 wurde durch das Bestehen von axe DevTools und Lighthouse-automatisierten Tests erreicht. Dies umfasste das Hinzufügen von aria-hidden bei dekorativen Icons (über 30 Instanzen), Screenreader-Benachrichtigungen bei externen Links, Kontrastkorrekturen (text-slate-400 → text-slate-500) und die globale Anwendung von focus-visible-Stilen — stetige, inkrementelle Arbeit.
4. UX & Codequalität
Wir haben Skriptabbruch-Probleme gelöst, die durch View Transitions (ClientRouter) über alle Komponenten hinweg verursacht wurden, und eine Volltextsuche mit Pagefind implementiert. Auf der Code-Seite wurde die TypeScript-Typsicherheit verbessert und Konstanten zentralisiert (Social-URLs, Ad-IDs, GA4-ID in SITE-Konstanten konsolidiert), was die Wartbarkeit erheblich verbesserte.
Tech-Stack
| Technologie | Zweck |
|---|---|
| Astro 6 | Statische Seitengenerierung (Zero-JS-Architektur) |
| UnoCSS (presetWind3) | Utility-First CSS |
| Cloudflare Pages | Hosting, CDN, Header-Steuerung |
| @fontsource-variable/noto-sans-jp | Selbst gehostete japanische Schriftart |
| wsrv.nl | Bild-Proxy (automatische AVIF/WebP-Konvertierung) |
| Pagefind | Volltextsuche für statische Websites |
Fazit
PageSpeed Insights Mobile 99 zu erreichen, läuft darauf hinaus, das Prinzip „nichts senden, was nicht benötigt wird” konsequent zu befolgen. CSS-Lieferstrategie, Schriftart-Selbst-Hosting, Bildoptimierung, verzögertes Laden externer Skripte — jede Maßnahme ist für sich genommen einfach, aber in Kombination liefern sie erhebliche Wirkung.
Durch parallele Verfolgung von SEO-, Barrierefreiheits- und UX-Verbesserungen werden hohe Bewertungen in allen vier Kategorien erreichbar. Statt sich auf 100 zu fixieren, ist ein stabiler Wert von 95+ ein realistischeres Ziel.
Detaillierte Informationen zu den einzelnen Themen finden Sie in den Linkkarten oben. Informationen zum Verbesserungsworkflow und wie Änderungen im Code umgesetzt wurden, finden Sie auch im Artikel Entwicklungsworkflow mit GitHub Copilot.
Verbesserungsprozess
Messen
Engpässe mit PageSpeed Insights und axe identifizieren.
Analysieren
Die Bewertungsaufschlüsselung lesen und die wirkungsvollsten Verbesserungen identifizieren.
Umsetzen
Änderungen einzeln anwenden und null Build-Fehler bestätigen.
Nachmessen
Nach dem Deployment erneut messen und Ergebnisse mit Zahlen validieren.
- PageSpeed Mobile Score im 70er-Bereich
- Keine strukturierten Daten oder OGP konfiguriert
- Keine Unterstützung für Barrierefreiheit
- Skripte brechen bei View Transitions
- Hartcodierte Konstanten überall verstreut
- Mobile 99 / 100 / 100 / 100 (alle Desktop-Metriken bei 100)
- 7 Typen strukturierter Daten + OGP + canonical vollständig implementiert
- WCAG AA-konform (Kontrast, aria, SR-Benachrichtigungen, focus-visible)
- Alle Komponenten kompatibel mit View Transitions
- SITE-Konstanten, Social-URLs und Ad-IDs zentral verwaltet
Ist es möglich, 100 Punkte bei PageSpeed Insights Mobile zu erreichen?
In welcher Reihenfolge sollten Verbesserungen vorgenommen werden?
Können diese Verbesserungstechniken auf andere Astro-Websites angewendet werden?
Wurde GitHub Copilot für die Verbesserungen eingesetzt?
Gui
CEO von Acecore. Ein vielseitiger Ingenieur, der Systementwicklung, Webproduktion, Infrastrukturbetrieb und IT-Bildung abdeckt. Löst gerne organisatorische und menschliche Herausforderungen durch Technologie.
Want to learn more about our services?
We provide comprehensive support including system development, web design, graphic design, and IT education.