Mein Blog mit Astro 5 neu gebaut: Lighthouse-Score von 68 auf 100

Letzte Woche habe ich meinen zweijährigen Next.js-Blog komplett neu aufgesetzt und auf Astro 5 umgestellt. Auslöser war ein Lighthouse-Score von nur 68 – Freunde sagten, der Blog „dreht sich ewig, bis etwas kommt“. Nach der Migration sank die Build-Zeit von 2 Minuten auf 18 Sekunden, der Performance-Score stieg von 68 auf 98.

Dieser Artikel behandelt drei Dinge: warum Astro so schnell ist, wie Sie damit einen Blog aufbauen und wie SEO richtig konfiguriert wird. Wenn Sie schon einmal unter Blog-Performance gelitten haben, sollte das Folgende weiterhelfen.

Warum Astro Ihre Aufmerksamkeit verdient

Ehrlich gesagt war ich anfangs nicht besonders interessiert. Es gibt zu viele Frameworks – Next.js, Nuxt, Gatsby – die Auswahl überfordert. Mein erster Gedanke: Wieder etwas Neues lernen, lohnt sich der Zeitaufwand wirklich?

Bis ich auf diese Zahlen stieß –

Die State of JavaScript 2024-Umfrage zeigt: Astro führt bei Interesse, Retention und Zufriedenheit. Bei der Nutzung liegt es auf Platz zwei, direkt hinter Next.js. GitHub Octoverse 2025 geht noch weiter und nennt Astro die drittschnellst wachsende Sprache.

Interessant: 60 % der Astro-Sites bestehen die Core-Web-Vitals-Bewertung, bei WordPress und Gatsby sind es nur 38 %. Der Abstand ist beträchtlich.

Wer Astro nutzt? GitHub-Dokumentation, Firebase Developer Docs, Smashing Magazine (von WordPress migriert). 2025 kamen Google, Reuters und Typst dazu.

Dann dachte ich ernsthaft nach: Was ist mein Blog? Eine Sammlung Markdown-Artikel, etwas Code-Highlighting, gelegentlich eine Kommentar-Komponente. Brauche ich die komplexe Full-Stack-Power von Next.js? Wohl kaum.

Mein Fazit: Wenn Sie vor allem Blog, Dokumentation oder Marketingseiten bauen, ist Astro derzeit nahezu die beste Wahl. Für E-Commerce oder SaaS mit viel Interaktion passt Next.js besser.

Es geht nicht um besser oder schlechter – sondern um unterschiedliche Szenarien.

Island-Architektur – Astro’s Geheimnis der Geschwindigkeit

Kennen Sie das? Der Seiteninhalt ist längst da, aber Buttons reagieren nicht.

Meist ist JavaScript-Hydration schuld. Klassische Frameworks schicken das gesamte JS an den Browser und „aktivieren“ die Seite nach und nach. Je komplexer die Seite, desto länger warten Sie.

Astro geht einen anderen Weg – die sogenannte Island-Architektur (Islands Architecture).

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Stellen Sie sich vor: Ihre Seite ist ein Ozean aus statischem HTML. Nur Komponenten, die wirklich interaktiv sein müssen – Zähler, Formulare, Kommentare – „tauchen auf“ als unabhängige Inseln. Jede Insel verwaltet ihr eigenes JavaScript, ohne die anderen zu stören.

Im Code sieht das so aus:

---

// Diese Komponente lädt JS erst, wenn sie sichtbar wird

---

<Counter client:visible />
// Diese Komponente bleibt reines statisches HTML – kein JS
<Header />

Sehen Sie client:visible? Das ist eine Astro-Direktive: Die Komponente wird erst aktiviert, wenn der Nutzer sie sieht. Es gibt auch client:load (sofort beim Laden) und client:idle (wenn der Browser Leerlauf hat).

Die Wirkung bei meinem Blog: First Contentful Paint (FCP) von 2,1 auf 0,8 Sekunden, Time to Interactive (TTI) von 4,5 auf 1,2 Sekunden. Das JS-Bundle: von 280 KB auf 45 KB.

Fairerweise: Wenn Ihre Seite fast nur aus interaktiven Komponenten besteht, ist Astro vielleicht nicht ideal. Der Vorteil liegt bei „meist statischem Inhalt“. Für Blogs und Docs ist das ein enormer Sprung.

Server Islands – Astro 5’s Neuerung

Astro 5 bringt Server Islands – ebenfalls spannend.

Früheres Problem: Die Seite ist größtenteils statisch, aber ein Block soll dynamisch sein (Avatar, Warenkorb-Zähler). Entweder die ganze Seite dynamisch rendern oder auf Personalisierung verzichten.

Server Islands liefern zuerst eine statische HTML-Hülle; dynamische Teile injiziert der Server separat.

Offiziell: „Performance und Personalisierung schließen sich nicht mehr aus.“ In der Praxis fühlt sich das sehr flüssig an.

Content Layer – Inhalte neu organisieren

Ab über 100 Artikeln wird Content-Management unübersichtlich.

Klassisch: Markdown-Dateien unter src/content, Organisation über das Dateisystem. Wenige Artikel – kein Problem. Viele – mühsam suchen, CMS-Anbindung umständlich.

Astro 5’s Content Layer ändert das grundlegend.

Kern ist der Loader: Inhalte aus beliebigen Quellen – lokales Markdown, Strapi, Contentful, Notion oder eigene APIs. Eine einheitliche Quelle, übersichtliche Verwaltung.

// astro.config.mjs
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    tags: z.array(z.string()),
  }),
});

Bedeutung: Alle Markdown-Dateien aus ./src/content/blog laden; jeder Beitrag braucht title, pubDate, tags.

Laut Astro: Markdown-Build bis zu 5× schneller, MDX 2×, Speicher 25–50 % weniger. Mein Blog: Build von 2 Minuten auf 18 Sekunden – vermutlich vor allem Content Layer.

Aktuell nutze ich den glob-Loader für lokales Markdown. Als Nächstes teste ich Notion, um Schreiben und Veröffentlichen zu trennen.

View Transitions – flüssige Seitenwechsel

Kurz und knapp.

In Astro 5 heißt die frühere ViewTransitions-Komponente ClientRouter – gleiche Funktion, klarerer Name für Client-Routing.

---

import { ClientRouter } from 'astro:transitions';

---

<html>
  <head>
    <ClientRouter />
  </head>
  <body>
    <!-- Ihr Inhalt -->
  </body>
</html>

Damit bekommen Seitenwechsel Übergangsanimationen statt hartem Sprung – spürbar besser für Nutzer.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

2025 unterstützen fast alle modernen Browser die native View Transitions API; Firefox war zuletzt. ClientRouter bietet Fallback für ältere Browser.

Cross-Page-State (z. B. Musikplayer ohne Unterbrechung)? ClientRouter. Nur simple CSS-Übergänge? Native CSS View Transitions reichen oft.

SEO-Optimierung in der Praxis

Performance allein reicht nicht. Suchmaschinen prüfen auch Struktur und Metadaten.

Beim ersten SEO-Setup bin ich in mehrere Fallen getappt – hier die richtige Vorgehensweise.

Sitemap

Basis, leicht vergessen:

npx astro add sitemap

In astro.config.mjs die Site-URL setzen:

import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
  site: 'https://yourdomain.com', // Diese Zeile nicht vergessen!
  integrations: [sitemap()],
});

Ich hatte site vergessen – die Sitemap enthielt nur relative Pfade, Google ignorierte sie. Tage lang gesucht.

Meta-Tags

Jeder Artikel braucht eigenes title und description. Ich pflege das im Markdown-Frontmatter:

---

title: "Astro 5 Performance-Optimierung"
description: "Island-Architektur und Content Layer in Astro 5 im Detail..."
publishDate: 2025-11-20
ogImage: "/images/astro-5-cover.png"

---

Im Layout werden die Werte gelesen:

---

const { title, description, ogImage } = Astro.props.frontmatter;

---

<head>
  <title>{title}</title>
  <meta name="description" content={description} />
  <meta property="og:title" content={title} />
  <meta property="og:description" content={description} />
  <meta property="og:image" content={ogImage} />
  <link rel="canonical" href={Astro.url} />
</head>

Canonical-URLs verhindern Duplicate-Content-Probleme.

Strukturierte Daten (JSON-LD)

Weniger bekannt, aber wertvoll: Sie sagen Suchmaschinen explizit „BlogPosting“, Autor, Datum.

<script type="application/ld+json">
  {JSON.stringify({
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": title,
    "datePublished": publishDate,
    "author": {
      "@type": "Person",
      "name": "Ihr Name"
    }
  })}
</script>

Prüfen mit dem Schema.org Validator.

SEO-Trends 2025

1. LLMs crawlen Ihre Seiten mit. Suchmaschinen und KI brauchen klare Struktur – mehr als Keyword-Stuffing.
2. Interne Links zählen. Mindestens drei pro Seite, sonst wirkt die Seite für Crawler unwichtig.
3. E-E-A-T. Experience, Expertise, Authoritativeness, Trustworthiness – echte Ranking-Faktoren bei Google.

SEO-Checkliste

Nach dem Setup durchgehen:

• sitemap.xml erzeugt und erreichbar
• Eindeutiges title und description pro Seite
• Bilder mit alt-Attribut
• JSON-LD strukturierte Daten
• robots.txt korrekt
• Mindestens 3 interne Links pro Seite

Bildoptimierung – unterschätzter Performance-Killer

Komprimieren allein reicht nicht.

Astro liefert astro:assets mit einer starken Image-Komponente:

---

import { Image } from 'astro:assets';
import myImage from '../assets/hero.png';

---

<Image
  src={myImage}
  alt="Hero image"
  widths={[400, 800, 1200]}
  format="webp"
/>

Das leistet:

1. Automatische Breite/Höhe – weniger Layout Shift (CLS)
2. Mehrere Größen – Browser lädt passend
3. WebP – kleinere Dateien

Wichtig: Bilder in src, nicht in public. Nur unter src optimiert Astro. Falsche Ablage = riesige Dateien.

Remote-Bilder: inferSize für automatische Dimensionen:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

<Image
  src="https://example.com/image.jpg"
  alt="Remote image"
  inferSize
/>

Das Open-Source-Projekt AstroEdge: 4,2 MB → 0,8 MB (−82 %), Lighthouse 79 → 100.

Astro 5: experimentelles Cropping, SVG-Komponenten – Details in der offiziellen Doku.

Migration von anderen Frameworks

Kurz für Upgrades von Astro 4 oder anderen Stacks.

Wesentliche Astro-5-Änderungen:

1. ViewTransitions → ClientRouter
2. Astro.glob() deprecated → import.meta.glob() oder getCollection()
3. Hybrid-Rendering in static Output integriert
4. Bildservice: Squoosh → Sharp
5. CSRF-Schutz standardmäßig aktiv

Migration:

npx @astrojs/upgrade

Behebt die meisten Kompatibilitätsprobleme automatisch.

Von Next.js oder Gatsby: mehr Aufwand. Astro unterstützt React-Komponenten – Seiten zuerst migrieren, Komponenten nach und nach ersetzen.

Fazit

Kernpunkte:

1. Island-Architektur – standardmäßig wenig bis kein JS, natürlicher Performance-Vorsprung
2. Content Layer – einheitliches Content-Management, beliebige Datenquellen
3. SEO – wenige Schritte, jeder einzelne wichtig
4. Bildoptimierung – versteckter Hebel, nicht ignorieren
5. View Transitions – flüssigere Navigation

Unsicher beim Blog-Framework? Nehmen Sie sich 30 Minuten für das offizielle Astro-Blog-Template – Build-Zeit und Lighthouse-Score selbst erleben.

npm create astro@latest -- --template blog

Out of the box, Konfiguration anpassen, veröffentlichen.

Nützliche Links:

• Astro-Dokumentation (Englisch, am vollständigsten)
• Astro-Chinesische Community (chinesische Übersetzung)

Als Nächstes plane ich ein Tutorial: Astro + Tailwind + MDX für Tech-Blogs.

Welches Framework nutzen Sie? Performance-Probleme gehabt? Schreiben Sie in die Kommentare.