Astro-Website-Qualitätsverbesserungsleitfaden, Fortsetzung - Letzte Anpassungen für 100 Punkte in allen PageSpeed-Insights-Kategorien

Einleitung

Im vorherigen Astro-Website-Qualitätsverbesserungsleitfaden habe ich die große Menge an Verbesserungen zusammengefasst, die auf die erneuerte Acecore-Website angewendet wurden. Dieser Artikel ist die direkte Fortsetzung.

Dieser Artikel schließt die kleineren Punkte ab, die nach der Veröffentlichung des vorherigen Beitrags noch offen waren, und bringt die Website in einen Zustand, in dem alle vier PageSpeed-Insights-Kategorien sowohl auf Mobile als auch auf Desktop 100 Punkte erreichen. Es ging dabei nicht nur um den Score: Auch GA4 und die Suche wurden aus dem Initial-Load herausgenommen, Search-Console-Breadcrumbs und Indexierungsregeln wurden bereinigt, das Icon-Rendering wurde stabilisiert und der sinnvolle Stoppunkt für weitere Optimierungen wurde ausdrücklich festgehalten.

Ergebnis: 100 Punkte in allen PageSpeed-Insights-Kategorien

Zum 29. März 2026 zeigte die Acecore-Startseite die folgenden Ergebnisse.

Unten stehen die tatsächlichen PageSpeed-Insights-Screenshots zusammen mit den Report-URLs. In der vorherigen Runde sah ich „Mobile 99 / alles andere 100“ als realistische Obergrenze an. Dieses Mal ließ sich durch das Entfernen unnötiger Drittanbieter-Beacons und das sorgfältige Einordnen der verbleibenden Diagnosen die 100 erreichen.

Bericht-URLs

Damit nicht nur Screenshots, sondern auch direkt wieder aufrufbare Nachweise erhalten bleiben, lasse ich hier auch die Report-URLs dieser Messung stehen.

• Mobile-Bericht
• Desktop-Bericht

Ein Klick auf das Bild öffnet direkt den passenden PageSpeed-Insights-Bericht.

Mobile Desktop

Wie bemerkenswert ist eine 100?

Bei 100 Punkten könnte man schnell denken, dass Performance immer weiter steigt, wenn man nur genug Funktionen entfernt, das Erscheinungsbild vereinfacht und externe Elemente streicht. Ein Stück weit stimmt das sogar: Eine statische Website wird oft schneller, je mehr man herausnimmt.

Hier ging es aber nicht darum, eine möglichst leere Demo-Seite zu bauen. GA4, Werbung, Suche, ClientRouter und gemeinsames CSS mussten im produktiven Betrieb erhalten bleiben, und trotzdem sollten Mobile und Desktop in allen vier Kategorien bei 100 landen. Entscheidend war also nicht nur, die Website leichter zu machen, sondern festzulegen, was bleiben muss, was entfernt werden kann und was man bewusst nicht weiter anfasst.

Natürlich bedeutet eine 100 nicht, dass dies absolut die schnellste Website der realen Welt ist. Die tatsächliche Nutzererfahrung hängt von Netzwerk, Geräten, Region und Cache-Status ab. Trotzdem kann man sagen, dass die Website ein sehr hohes Niveau erreicht hat, weil die wichtigsten Lighthouse-Audits keine größeren Lücken mehr zeigen, obwohl die nötigen Betriebselemente erhalten blieben.

Die letzten Anpassungen bis 100 Punkte

1. Cloudflare Web Analytics deaktiviert und Messrollen neu sortiert

Cloudflare Web Analytics ist als privacy-first und leichtgewichtiges RUM-Produkt nützlich, doch auf Acecore war die GA4-Seite bereits breit für CTA-Klicks, Suche, Kontaktaktionen, Lead-Generierung und weitere Events instrumentiert.

Nach einer erneuten Rollenprüfung kam ich zu dem Schluss, dass auf der Cloudflare-Seite die Kosten eines unnötigen Beacons in PageSpeed inzwischen höher waren als sein Nutzen. Ich deaktivierte daher RUM im Dashboard und bestätigte, dass static.cloudflareinsights.com/beacon.min.js nicht mehr im Produktions-HTML auftauchte.

Das bedeutete jedoch nicht, Messung grundsätzlich aufzugeben. CTA-Klicks, externe Links, Suche und Kontakt-Conversions sollten weiterhin messbar bleiben. Der nächste Schritt war deshalb, GA4 beizubehalten, aber seinen Ladezeitpunkt zu verschieben.

2. GA4 beibehalten, aber aus dem Initial-Load herausgenommen

Entscheidend war hier die Unterscheidung zwischen „beibehalten“ und „sofort laden“. Die eigentliche Frage lautete nicht nur, ob GA4 bleiben sollte, sondern ob es im frühesten Ladepfad liegen musste.

Praktisch blieb der gtag-Einstiegspunkt sofort verfügbar, sodass Events weiter entgegengenommen werden konnten. Das eigentliche gtag/js-Skript wurde jedoch auf requestIdleCallback und Nutzerinteraktionen verschoben. Zusätzlich gibt es je nach Seitentyp unterschiedliche Fallback-Zeitfenster, damit Analytics auch dann noch geladen wird, wenn keine direkte Interaktion stattfindet.

So blieb die Messung von CTA, externen Links, Suche und Kontakt erhalten, ohne Drittanbieter-Skripte in die früheste Render-Phase zu drücken. Die 100 Punkte resultieren also nicht nur aus dem Entfernen des Cloudflare-Beacons, sondern auch aus einem intelligenteren Ladezeitpunkt für GA4.

3. Suche und Pagefind auf On-Demand-Laden umgestellt

Auch die Suche ist eine Funktion, die den Initial-Load still und leise schwerer machen kann, obwohl Nutzer sie oft gar nicht sofort öffnen. Acecore verwendet Pagefind für Volltextsuche, und in dieser Runde habe ich die gleiche Logik angewandt: Funktion beibehalten, aber die Kosten nicht mehr im Voraus bezahlen.

Das Such-Modal lädt pagefind-ui.js und die zugehörigen Styles erst dann, wenn die Suche tatsächlich geöffnet wird. Das Promise wird gecacht, sodass die Assets nicht doppelt geladen werden, und Tastenkürzel oder Query-Parameter zum Öffnen funktionieren weiterhin normal.

Das ist nicht nur gut für den Lighthouse-Score, sondern macht auch den alltäglichen ersten Render leichter. Die Suche bleibt erhalten, muss aber nicht länger auf dem kritischen Pfad jeder Seitenansicht liegen.

4. Die verbleibenden PageSpeed-Diagnosen eingeordnet

Selbst wenn der Score 100 erreicht, kann PageSpeed weiterhin Diagnosen wie Network dependency tree oder render-blocking resources anzeigen. Wenn man diese pauschal als Warnungen interpretiert, die vollständig verschwinden müssen, jagt man schnell Optimierungen mit geringem Gegenwert hinterher.

Die kritische Kette sah in diesem Fall ungefähr so aus:

1. /en/
2. ClientRouter.js
3. BaseLayout.css
4. BaseLayout.js

Von diesen Punkten blieb tatsächlich nur BaseLayout.css als render-blocking übrig. Die Datei ist inzwischen jedoch klein genug, und Mobile 100 bleibt stabil, daher habe ich sie vorerst als „verbleibende, aber akzeptable Diagnose“ eingeordnet. Diese Einschätzung ausdrücklich zu formulieren war bereits ein wichtiger Gewinn, weil sie eine klare Stoppregel für spätere Optimierungen liefert.

5. Search-Console-Breadcrumbs und Indexierungsregeln bereinigt

Nachdem PageSpeed stabil bei 100 lag, habe ich die Lage auch aus Sicht der Suche neu betrachtet. Genau dort zeigte Search Console noch einen echten Widerspruch: ungültige Breadcrumb-Einträge waren verblieben, obwohl FAQ-Markup bereits sauber war.

Um das zu korrigieren, wurde die BreadcrumbList-Ausgabe auf Listen-Seiten so umgebaut, dass explizite Breadcrumb-Elemente übergeben werden können, statt sich nur lose aus dem Pfad abzuleiten. Gleichzeitig wurde die Behandlung von Trailing Slashes angeglichen, damit Canonical-URLs, hreflang-Links und Breadcrumb-URLs nicht mehr auseinanderlaufen.

Zusätzlich wurde die Indexierungsrolle von Tag-, Archiv-, Autor- und Paginierungsseiten explizit geklärt. Solche Seiten sind als Navigation nützlich, werden aber leicht zu dünnen oder doppelt wirkenden Indexzielen. Deshalb wurden sie mit noindex, follow versehen und aus der Sitemap ausgeschlossen. Das löscht nicht sofort jeden „crawled - currently not indexed“-Eintrag, aber es bedeutet, dass die gewünschte Indexierungsstrategie nun direkt im Code ausgedrückt wird.

6. Icon-Rendering auf ein gemeinsames SVG-Component vereinheitlicht

Im Zuge der letzten Anpassungen befand sich das Projekt bereits im Übergang von UnoCSS-Icon-Utilities zum gemeinsamen SVG-basierten Icon-Component. In diesem Prozess blieben einige dynamische Icon-Klassen in ProcessFigure und StatBar zurück, wodurch in manchen Artikeln nur leere Kreise angezeigt wurden.

Ich habe das Rendering auf der Komponenten-Seite über Icon vereinheitlicht und zusätzlich einen Alias ergänzt, der den alten Namen check-circle in circle-check aufnimmt.

Dadurch ergaben sich drei praktische Vorteile:

• Es wird deutlich unwahrscheinlicher, dass ein Icon verschwindet, weil eine dynamische Klasse übersehen wurde
• Barrierefreiheitsattribute wie aria-hidden lassen sich auf der SVG-Seite vereinheitlichen
• Der Betrieb wird stabiler, weil das Rendering nicht mehr von der statischen Analyse von UnoCSS abhängt

Parallel dazu wurden Datums-Parsing und Anzeige im Blog auf JST ausgerichtet. Das ist nicht das Hauptthema dieses Artikels, aber es stabilisiert die Reihenfolge von Beiträgen am selben Tag und verbessert die Zeitgenauigkeit strukturierter Daten.

7. Geprüft, aber nicht übernommen

Sobald 100 Punkte erreicht sind, liegt die Versuchung nahe, jede verbleibende Diagnose noch um jeden Preis verschwinden zu lassen. Einige Richtungen habe ich dafür verglichen, aber nicht übernommen.

• BaseLayout.css noch weiter aufzuteilen: Das könnte die Diagnosen optisch etwas sauberer wirken lassen, doch Mobile 100 bleibt bereits stabil und der praktische Nutzen rechtfertigt die zusätzliche Komplexität nicht.
• Die bloße Anzeige des network dependency tree vollständig verschwinden zu lassen: Eine angezeigte Diagnose ist nicht automatisch ein echtes Problem für Nutzerinnen und Nutzer.
• Selbst GA4 zu streichen, um Drittanbieter noch stärker zu reduzieren: Das würde die Seite zwar etwas leichter machen, aber zugleich wichtige Business-Messungen opfern.

Gerade dieser Vergleich war wichtig. Die letzten Anpassungen waren nicht deshalb abgeschlossen, weil alles nur Denkbare entfernt wurde, sondern weil die verbleibenden Abwägungen nun klar und belastbar benannt werden konnten.

Praktische Erkenntnisse aus den letzten Anpassungen

Der größte Gewinn bestand dieses Mal nicht nur darin, 100 Punkte zu erreichen. Entscheidend war, einen Zustand zu erreichen, in dem ich erklären kann, was entfernt werden sollte und was sinnvollerweise bleiben darf.

Cloudflare Web Analytics lohnt sich zum Beispiel zu entfernen, wenn es nur noch aus Gewohnheit vorhanden ist, während GA4 bleiben sollte, weil es den Kern der Business-Event-Messung bildet. Wenn GA4 aber bleibt, muss es nicht zwingend im frühesten Ladepfad liegen. Sinnvoller ist es, die Messung zu behalten und den Ladezeitpunkt zu verschieben.

Dasselbe gilt für Suche und SEO. Die Suche sollte erhalten bleiben, muss aber nicht im Initial-Load liegen. Listen-Seiten bleiben als Navigation nützlich, müssen aber nicht als primäre Indexziele behandelt werden. Und network dependency tree ist kein Fehler an sich; man muss hineinschauen und beurteilen, ob die verbleibende Kette noch vernünftig ist.

Ich habe außerdem KI genutzt, um das Feld möglicher Änderungen breiter zu öffnen. Die endgültigen Kriterien blieben aber drei sehr konkrete Fragen: Verbessern sich die Messwerte tatsächlich, steigen die Betriebskosten nicht übermäßig, und bleiben die nötigen Messfunktionen erhalten? KI war hilfreich für die Breite der Optionen, entschieden wurde am Ende dennoch anhand von Messung und Urteil.

Wenn man nur dem Score hinterheroptimiert, geht die Abstimmung schnell zu weit. Dieses Mal konnte ich nicht nur die Korrekturen, sondern auch die Grenze zum sinnvollen Stopp klar ordnen. Daher kann man sagen, dass die Verbesserungen der Acecore-Website vorerst einen abgeschlossenen Zustand erreicht haben.

Zusammenfassung

Als Fortsetzung des vorherigen Artikels wurden mit den letzten Anpassungen die folgenden Punkte abgeschlossen:

• 100 Punkte in allen PageSpeed-Insights-Kategorien auf Mobile und Desktop bestätigt
• Cloudflare Web Analytics deaktiviert, während GA4 erhalten blieb und verzögert geladen wird
• Suche und Pagefind auf On-Demand-Laden umgestellt und die Anfangslast reduziert
• Verbleibende Netzwerk-Diagnosen eingeordnet und akzeptable Restpunkte klar benannt
• Search-Console-Breadcrumb-Ausgabe und Indexierungsregeln für Listen-Seiten bereinigt
• Fehlende Icon-Darstellung durch Vereinheitlichung auf das gemeinsame SVG Icon beseitigt
• Zusätzliche Optimierungen mit geringem Gegenwert verworfen und den sinnvollen Stoppunkt klar benannt

Zumindest aus Sicht von Lighthouse und PageSpeed Insights wurde die Acecore-Website auf ein Niveau gebracht, das legitimerweise Spitzengeschwindigkeit anstreben kann. Gleichzeitig ist der Score nicht das Ziel, sondern nur das Ergebnis. Ich werde daher sowohl den Betrieb als auch weitere Verbesserungen fortführen, damit dieser Zustand nicht wieder verloren geht.