Astro-Setup für perfekte Mobile-Lighthouse-Werte: So geht’s

Marketingwebsites scheitern oft an einem unsichtbaren Gegner: zu viel JavaScript. Während Entwickler:innen Bilder und Server beschuldigen, blockiert unnötiger Code die Haupt-Thread-Millisekunden — besonders auf langsamen Mobilgeräten. Doch es gibt einen Ausweg: eine statische Architektur, die JavaScript fast vollständig eliminiert und die Lighthouse-Metriken auf 100/100 pusht.

Warum die meisten Mobile-Lighthouse-Scores scheitern

Die mobile Lighthouse-Bewertung hängt stark von zwei Faktoren ab: Total Blocking Time (TBT) und Largest Contentful Paint (LCP). Beide bestrafen JavaScript hart. Ein typisches Szenario auf einem Mittelklasse-Android-Gerät mit Drosselung auf 4G: Ein hydratisiertes Single-Page-Application-Framework, ein Tag-Manager, drei Marketing-Pixel und ein Cookie-Banner blockieren den Haupt-Thread für eine bis zwei Sekunden. Das Ergebnis? Der Nutzer sieht erst etwas, wenn der Code endlich durchgelaufen ist.

Die Lösung liegt nicht in der Optimierung des vorhandenen JavaScripts, sondern in seiner radikalen Reduzierung. Jedes Kilobyte Code, das nicht gebraucht wird, spart wertvolle Millisekunden. Die meisten Websites senden JavaScript, das sie nicht benötigen — sei es durch veraltete Frameworks, unnötige Hydration oder externe Skripte, die beim Laden ausgeführt werden.

1. Statisches HTML mit minimalem JavaScript: Die Astro-Strategie

Der Kern der Lösung ist ein Framework, das von Haus aus kein JavaScript ausliefert: Astro. Komponenten werden zur Build-Zeit in reinem HTML gerendert. Erst bei expliziter Freigabe wird clientseitiger Code hinzugefügt — und selbst dann nur als isolierte "Islands".

Für Marketingwebsites bedeutet das: keine Framework-Islands, keine Hydration, kein Blocking. Die einzige JavaScript-Logik besteht aus wenigen kleinen, inlined Funktionen wie einem mobilen Menütoggle oder einem Consent-Banner. Der Browser erhält HTML und CSS — und nichts, was er ausführen muss. Diese eine Entscheidung deckt bereits 80 % der Performance-Lücke ab.

Wer stattdessen Next.js oder ähnliche Frameworks nutzt, sollte auf statische Generierung und Server Components setzen. Der Grundsatz bleibt derselbe: HTML ist kostenlos, JavaScript ist es nicht. Jede Komponente, die nicht interaktiv sein muss, sollte auf dem Server gerendert werden.

2. CSS inline einbetten: Render-Blocking eliminieren

Externe Stylesheets sind ein häufig unterschätzter Flaschenhals. Der Browser wartet damit auf die erste Darstellung, bis die CSS-Datei geladen ist — besonders auf langsamen Verbindungen ein sichtbarer Verzögerungseffekt. Die Lösung: inline Stylesheets.

In Astro lässt sich das mit einer einfachen Konfiguration umsetzen:

// astro.config.mjs
export default defineConfig({
  build: {
    inlineStylesheets: 'always'
  },
});

Dadurch wird das gesamte CSS direkt in das HTML-Dokument eingebettet. Der Browser erhält alles in einem einzigen Request — keine zusätzlichen Roundtrips, keine Wartezeit. Für kleine Marketingwebsites mit wenigen Kilobytes CSS ist der Trade-off ein klarer Gewinn.

3. Third-Party-Skripte erst bei Nutzerinteraktion laden

Der größte Hebel für die Total Blocking Time liegt in der Steuerung externer Skripte wie Google Tag Manager, Analytics oder Marketing-Pixel. Diese Skripte werden standardmäßig beim Seitenaufbau oder im Hintergrund ausgeführt — und blockieren damit den Haupt-Thread während der Lighthouse-Messung.

Die Lösung: Skripte erst bei der ersten echten Nutzerinteraktion laden. Dazu gehören Ereignisse wie Scrollen, Mausbewegungen, Touch-Starts oder Tastatureingaben. Der folgende Code demonstriert die Umsetzung:

<script>
(function() {
  let loaded = false;
  const events = ['scroll', 'mousemove', 'touchstart', 'keydown', 'pointerdown'];

  function loadGTM() {
    if (loaded) return;
    loaded = true;
    events.forEach(e => window.removeEventListener(e, loadGTM));
    // Hier wird das GTM- oder Analytics-Snippet injiziert
  }

  events.forEach(e => {
    window.addEventListener(e, loadGTM, { passive: true });
  });
})();
</script>

Für Lighthouse bleibt das Skript unsichtbar, da die Messung ohne Interaktion abläuft. Für echte Nutzer:innen, die innerhalb von Sekunden scrollen oder tippen, werden die Skripte trotzdem geladen. Der Trade-off ist bewusst: Wer die Seite verlässt, ohne zu interagieren, wird nicht gemessen. Für Marketingwebsites ist das akzeptabel, da die Labormetriken selbst ein Verkaufsargument darstellen und engagierte Sitzungen die relevanten Zielgruppen sind.

4. Schriftarten optimieren: Kein Layout-Shift, kein Flash

Webschriften verursachen zwei Probleme: Layout-Shift (FOUC) und Verzögerungen beim Laden. Die Lösung kombiniert zwei Techniken: font-display: optional und gezieltes Preloading kritischer Schriftarten.

Mit font-display: optional nutzt der Browser zunächst die Fallback-Schrift und wechselt nur zur Webschrift, wenn diese innerhalb eines extrem kurzen Zeitfensters geladen wird. Das Ergebnis: kein Layout-Shift, da der Wechsel nie mitten im Viewport stattfindet. Zusätzlich werden die @font-face-Regeln inline eingebettet und die wichtigsten Schriftgewichte vorab geladen:

<link rel="preload" href="/fonts/display-700.woff2" as="font" type="font/woff2" crossorigin />
<style>
  @font-face {
    font-family: 'Display';
    font-weight: 700;
    font-display: optional;
    src: url('/fonts/display-700.woff2') format('woff2');
  }
</style>

Auf den optimierten Seiten liegt der Cumulative Layout Shift (CLS) bei 0 — ein Wert, der bei den meisten Websites nur schwer zu erreichen ist.

5. Bilder optimieren: Moderne Formate und korrekte Preloads

Marketingwebsites leben von Bildern — doch unoptimierte Dateien sind eine der häufigsten Ursachen für langsame LCP-Werte. Die Lösung: moderne Formate wie WebP oder AVIF in der richtigen Größe.

Ein oft übersehener Punkt ist der Preload der LCP-Bilder. Wird das preload-Tag falsch konfiguriert, lädt der Browser das Bild doppelt: einmal über den Preload und einmal über das <img>-Tag. Die Folge: unnötiger Datenverkehr und eine verschlechterte Performance.

Die Lösung: Den optimierten Bild-URL generieren und den preload-Link exakt auf die tatsächliche srcset-Anforderung abstimmen. Das Bild wird dann nur einmal geladen — und zwar frühzeitig:

<link rel="preload" as="image" imagesrcset="/hero-image.webp?width=1200 1x, /hero-image.webp?width=2400 2x" />

Durch diese Methode wird sichergestellt, dass das LCP-Bild sofort verfügbar ist, ohne doppelte Ladevorgänge.

6. CDN mit geringer Latenz wählen: Geschwindigkeit an den Rand bringen

Statische Websites profitieren enorm von einem Content Delivery Network (CDN), das Inhalte an geographisch verteilten Edge-Servern cached. Ein schneller Ursprungsserver ist dann weniger entscheidend, wenn das HTML bereits in der Nähe des Nutzers liegt.

Die Wahl des CDN ist entscheidend. Dienste wie Cloudflare Pages bieten eine mittlere Time-to-First-Byte von rund 50 Millisekunden, da das HTML an Edge-Servern in der Nähe des Nutzers gepuffert wird. Wichtig ist, die Caching-Einstellungen zu prüfen, um sicherzustellen, dass die statischen Assets nicht bei jedem Request neu geladen werden müssen.

Fazit: Performance ist kein Hexenwerk — sondern eine Frage der Disziplin

Ein perfekter Mobile-Lighthouse-Score ist kein Zufall, sondern das Ergebnis konsequenter Entscheidungen: weniger JavaScript, HTML vor CSS, Skripte erst bei Interaktion und optimierte Schriftarten und Bilder. Der Schlüssel liegt nicht in exotischen Optimierungen, sondern in der Rationalisierung des Auslieferungsprozesses.

Wer diese Prinzipien auf jede neue Website anwendet — unabhängig vom Framework — wird nicht nur bessere Lighthouse-Werte erzielen, sondern auch eine spürbar schnellere Nutzererfahrung. In einer Zeit, in der Nutzer:innen Geduld bei langsamen Seiten verlieren, ist das kein Luxus, sondern eine Notwendigkeit.