- PageSpeed Insights bewertete duna.digital am 15. Juli 2026 sowohl mobil als auch desktop mit 100 Punkten in Performance, Barrierefreiheit, Best Practices und SEO.
- Das Ergebnis kommt nicht von einem einzelnen Trick, sondern von einer schlanken Auslieferungsarchitektur, sehr wenig Browser-JavaScript, einer kontrollierten Bild- und Font-Pipeline und einem sauberen Consent-Konzept.
- Die 100 Punkte sind ein reproduzierbarer Laborwert, aber keine Garantie für jeden Aufruf. Echte Core Web Vitals müssen zusätzlich mit realen Nutzerdaten beobachtet werden.
Transparenz: Die Screenshots dokumentieren einen echten PageSpeed-Insights-Lauf. Zum Messzeitpunkt lagen für die neue Website noch keine ausreichenden CrUX-Felddaten vor. Lighthouse misst in einer simulierten Laborumgebung. Diese Unterscheidung ist wichtig und kein Kleingedrucktes.
Ein bisschen peinlich wäre es schon: Wir verkaufen schnelle, schöne und technisch saubere Websites, während unsere eigene Website Besucher warten lässt. Weil wir bei Kundenprojekten maximalistisch sind, musste duna.digital unser strengster Kunde werden. Nicht als sterile Demo ohne Inhalt, sondern als echte zweisprachige Website mit Magazin, Cases, Animationen, Consent und Kontaktformular.
Der Härtetest: viermal 100 auf mobil und desktop
Eine schnelle Website erkennt man, bevor man eine Zahl sieht: Navigation reagiert sofort, Inhalte stehen ohne Springen an ihrem Platz, und ein Seitenwechsel fühlt sich nicht wie Warten an. Genau dieses Gefühl war das Ziel des kompletten duna.digital Neubaus. Der PageSpeed-Test hat es anschließend messbar gemacht.
Warum wir nicht einfach ein Performance-Plugin installiert haben
PageSpeed-Optimierung beginnt nicht am Ende eines Projekts. Wer erst nach dem Launch versucht, ein schweres Frontend mit Cache-Plugins und Minify-Schaltern zu retten, behandelt Symptome. Wir haben die Website deshalb als System neu gebaut und Performance von der Architektur bis zum Release-Prozess als Produktanforderung behandelt.
Die öffentlichen Seiten werden vorab als vollständiges HTML erzeugt und mit möglichst wenigen Laufzeitabhängigkeiten ausgeliefert. Redaktion, Medien und Formulare sind so angebunden, dass ein normaler Seitenaufruf nicht auf schwere Anwendungslogik warten muss. Das Ergebnis ist eine robuste und schnelle Auslieferung.
Die sieben technischen Hebel hinter dem Lighthouse Score 100
1. HTML zuerst, JavaScript nur für echte Interaktion
Artikel, Service-Seiten, Cases, Navigationstexte und Metadaten kommen als fertiges HTML. Browser-JavaScript laden wir nur für Funktionen, die echten clientseitigen Zustand benötigen. Der Rest braucht keine Hydrierung. Weniger JavaScript bedeutet weniger Download, weniger Parsing und weniger Arbeit auf schwächeren Mobilgeräten.
2. Route-spezifisches CSS statt einer globalen Wundertüte
Die globale Stylesheet-Datei enthält nur das, was jede Seite benötigt. Artikel-, Case- und Teaser-Stile werden nur für Routen eingebunden, auf denen die entsprechenden Blöcke tatsächlich vorkommen. Tailwind CSS 4 hilft bei einem konsistenten Designsystem, aber entscheidend ist die Disziplin, keine ungenutzten Komponenten auf jede Seite zu laden.
3. Fonts als kontrolliertes Budget
PP Mori und Glazier prägen die Marke. Die kritischen Schnitte werden als geprüfte WOFF2-Subsets ausgeliefert, die den vollständigen deutschen und englischen Zeichenbestand der Website enthalten. Nur die wirklich benötigten Above-the-fold-Fonts werden vorgeladen. So bleibt die visuelle Identität erhalten, ohne den ersten Render mit unnötigen Font-Dateien zu blockieren.
4. Responsive AVIF und WebP aus einer deterministischen Pipeline
Jedes CMS-Bild erhält beim Build passende AVIF- und WebP-Derivate in mehreren Breiten. Das Frontend liefert über srcset und sizes die zum Display passende Datei aus. Intrinsische Breite und Höhe verhindern Layoutsprünge. Nur Above-the-fold-Medien laden priorisiert, alles Weitere lazy.
5. Drittanbieter-Skripte laufen nicht ungefragt mit
Der eigene Consent-Manager setzt den Einwilligungsstatus vor optionalen Skripten. Analyse- und Marketingdienste bleiben bis zur Zustimmung inaktiv; der Formularschutz wird erst bei Bedarf geladen. Das schützt Daten und reduziert unnötiges JavaScript.
6. Cache, Kompression und unveränderliche Assets
Versionierte Dateien können langfristig am Browser und am Cloudflare-Edge gecacht werden. HTML bleibt kontrolliert aktualisierbar, komprimierbare Inhalte werden komprimiert übertragen. Wichtig ist dabei nicht die längste denkbare Cache-Zeit, sondern die richtige Trennung: neue Datei bei neuem Inhalt, lange Lebensdauer für unveränderliche Assets.
7. Der Build beweist seine eigene Vollständigkeit
Vor einem Release prüfen automatisierte Kontrollen unter anderem Inhalte, Verlinkung, Medien, Metadaten, Sprachvarianten und strukturierte Daten. Nur vollständig geprüfte Builds werden veröffentlicht; Wiederherstellung und Rollback sind von Anfang an Teil des Release-Konzepts.
Was ein Lighthouse-Wert von 100 bedeutet und was nicht
Lighthouse erzeugt Labordaten unter definierten Bedingungen. Der Score kann durch Teststandort, Netzwerkrouting, Browser-Version und andere Rahmenbedingungen schwanken. Google selbst empfiehlt deshalb, Performance als Verteilung und nicht als einzelne magische Zahl zu betrachten.
Für die echte Nutzererfahrung zählen zusätzlich die Core Web Vitals aus Felddaten: Largest Contentful Paint für Ladegeschwindigkeit, Interaction to Next Paint für Reaktionsfähigkeit und Cumulative Layout Shift für visuelle Stabilität. PageSpeed Insights bezieht solche Daten aus dem Chrome User Experience Report, sobald genügend reale Besuche vorhanden sind. Unser nächster Messpunkt ist deshalb nicht der hundertste Screenshot, sondern die Entwicklung dieser Werte über die kommenden 28-Tage-Fenster.
Ein 100er-Lauf ist ein starker technischer Nachweis. Er ersetzt weder kontinuierliches Monitoring noch eine gute Informationsarchitektur, relevante Inhalte, Conversion-Optimierung oder echte Nutzerforschung.
Funktioniert das nur mit Astro?
Nein. Astro passt hervorragend zu dieser Website, weil fast alles statischer Content ist. Aber die Grundprinzipien gelten auch für WordPress, Laravel und individuelle PHP-Anwendungen: serverseitig oder statisch rendern, JavaScript-Budget begrenzen, Medien korrekt ausliefern, Datenbank- und Cache-Wege messen, Drittanbieter kontrollieren und Releases reproduzierbar machen.
Ein gut gebautes WordPress kann sehr schnell sein. Eine Laravel-Plattform kann trotz komplexer Geschäftslogik ausgezeichnete Core Web Vitals erreichen. Umgekehrt rettet das modernste Framework keine unkontrollierten Skripte, riesigen Bilder oder schlechte Hosting- und Release-Prozesse. Wir wählen den Stack nach Aufgabe, nicht nach Mode.
Und wenn die Website im BaFin-Umfeld eingesetzt wird?
Geschwindigkeit allein macht keine Website BaFin-konform, und ein offizielles BaFin-Siegel für Websites existiert nicht. In regulierten Projekten kommen andere Anforderungen hinzu: nachvollziehbare Änderungen, Zugriffskontrolle, kontrollierte Releases, belastbare Betriebs- und Wiederanlaufprozesse sowie ein dokumentierter Umgang mit Dienstleistern.
Unsere Performance-Pipeline unterstützt diese Anforderungen, weil Builds reproduzierbar, Artefakte prüfbar und Releases bewusst freigegeben werden. Sie ist aber nur ein Baustein. Was regulierte Unternehmen in der Praxis zusätzlich verlangen, haben wir im Artikel Webentwicklung im BaFin-Umfeld anhand unserer Finoa- und König-Leasing-Projekte beschrieben.
Kann man eine Website mit 100 Punkten beauftragen?
Man kann eine Website beauftragen, die mit einem klaren Performance-Budget, messbaren Zielwerten und einem sauberen technischen Betrieb entwickelt wird. Eine Agentur sollte trotzdem keinen dauerhaft identischen Lighthouse-Score garantieren, weil das Messsystem und externe Bedingungen variieren. Seriös garantierbar sind der Prozess, die Architekturentscheidungen, das Testregime und die Reaktion auf Regressionen.
Bei einem Relaunch beginnen wir deshalb mit Zielgruppen, Inhalten und Conversion-Pfaden. Danach definieren wir Performance-Budgets für JavaScript, CSS, Fonts und Bilder. Vor dem Release testen wir reale Seiten und Viewports, nicht nur eine leere Demo. Nach dem Launch folgen Search Console, Core Web Vitals und bei Bedarf eigenes Real User Monitoring.
Häufige Fragen
Kann man einen Lighthouse Score von 100 garantieren?
Nicht dauerhaft für jeden einzelnen Lauf. Messbedingungen und Lighthouse-Versionen ändern sich. Man kann aber eine Website so bauen und kontinuierlich prüfen, dass sie stabil im grünen Bereich bleibt und 100 Punkte unter reproduzierbaren Laborbedingungen erreicht.
Ist PageSpeed 100 dasselbe wie bestandene Core Web Vitals?
Nein. Der Lighthouse-Score ist ein Laborergebnis. Core Web Vitals bewerten reale Nutzererfahrungen anhand von Felddaten, normalerweise über ein rollierendes 28-Tage-Fenster. Beide Perspektiven gehören zusammen.
Kann eine WordPress-Website 100 Punkte erreichen?
Ja, abhängig von Inhalt und Funktionen. Entscheidend sind Theme- und Plugin-Qualität, Rendering, Bildauslieferung, Caching, Hosting und Drittanbieter. WordPress selbst ist kein Ausschlusskriterium.
Macht ein Score von 100 eine Website BaFin-konform?
Nein. Performance ist nur ein Qualitätsmerkmal. Regulierte Umfelder verlangen zusätzlich technische, organisatorische und vertragliche Kontrollen.
- Google: About PageSpeed Insights - Abgrenzung von Labor- und Felddaten
- Chrome for Developers: Lighthouse performance scoring - Berechnung und Schwankungen des Scores
- web.dev: Web Vitals - LCP, INP, CLS und Felddaten
