ispringen.dev – Architektur und Learnings eines statischen Portfolios

Ein technisches Deep Dive in die Konzeption von ispringen.dev: Wie statische Generierung zu 100 Lighthouse-Punkten führen.

Ein Portfolio ist nur dann glaubwürdig, wenn es die eigenen Prinzipien vorlebt. Meine Seite ispringen.dev ist seit August 2025 online und dient als technische Referenz für Full-Stack-Entwicklung, Architektur und Performance. Die Zielgruppe umfasst regionale Auftraggeber aus Stuttgart und Karlsruhe sowie Entwickler, die Wert auf messbare UX und saubere Umsetzung legen. Drei Kernanforderungen waren entscheidend: eine klare Positionierung als Freelancer mit Fokus auf Web und Cloud, 100 Punkte im Lighthouse-Score (mobile, Performance, SEO, Accessibility) und ein Redaktionsfluss unter fünf Minuten pro Inhaltsupdate.

Ein Portfolio überzeugt nur, wenn es Reduktion auf Nutzen, messbare Performance und wartbare Architektur vorlebt.

Die technische Basis bildet eine Kombination aus statischer Generierung mit Astro, Edge-Funktionen auf Cloudflare Pages und einem git-basierten CMS (Decap CMS). Diese Architektur löst ein konkretes Problem: Die regionale Verortung erhöht die Kontaktkonversion, weil lokale Auftraggeber schneller einordnen können, wer ich bin und was ich anbiete. Die Seite ist bewusst schlank gehalten, da sich jede Komponente durch Nutzen, Wartbarkeit oder messbare Verbesserung rechtfertigen muss.

Ich sehe ein Portfolio nicht als Showcase-Plattform, sondern als Arbeitsprobe. Sie zeigt, wie ich mit minimalem Overhead maximale Stabilität und Klarheit erreiche. Für 80 Prozent der Portfolios ist die Kombination aus statischer Generierung (Astro), Edge-Funktionen (Cloudflare) und git-CMS (Decap) die optimale Balance, die 90 Prozent der Anforderungen abdeckt, ohne Infrastruktur-Ballast zu erzeugen.

Kurzbeispiel: Redaktionsworkflow für einen Blogpost

Markdown-Datei in /src/content/blog/[DATE]-titel.md mit Frontmatter (Titel, Beschreibung, Tags) erstellen.
Inhalt schreiben und optional Komponenten wie <Image /> einbinden.
Preview im CMS prüfen, Commit und Push ausführen, wodurch ein automatischer Build auf Cloudflare Pages angestoßen wird.

Erfolgskriterium: Der Post ist unter /blog/[slug] live, der Lighthouse-Score bleibt bei 100.

Technologien: Warum weniger mehr ist

Der Tech-Stack ist bewusst schlank: TypeScript, Astro SSG, Vite, Tailwind, Decap CMS und Cloudflare Pages mit Edge Functions. Die Performance-Ziele sind klar definiert: Largest Contentful Paint unter 2,5 Sekunden, Cumulative Layout Shift nahe null und Interaktionen unter 100 Millisekunden. Bilder werden über astro:assets als AVIF und WebP mit gestaffelten Breiten generiert, wobei der Fokus auf dem Hero-Bild liegt. Das CMS ist gitbasiert, nutzt OAuth-Login und speichert Inhalte als Markdown im Repository. Previews erfolgen über registrierte Astro-Templates.

Ich halte statische Generierung mit gezielten Edge-Funktionen für die effizienteste Balance aus Performance und Dynamik. Diese Kombination reduziert den Infrastrukturaufwand, nutzt die Stärken von CDNs und vermeidet unnötige JavaScript-Hydration. Ein git-basiertes CMS ist für Einzelentwickler praktikabler als Datenbank-Lösungen, da Versionierung, Portabilität und Pull-Request-Workflows den Wartungsaufwand minimieren.

Statische Generierung mit Edge-Funktionen reduziert Infrastrukturaufwand und nutzt CDN-Stärken optimal.

Kurzbeispiel: Bildpipeline-Konfiguration

// astro.config.mjs (Ausschnitt)
image: {
  service: {
    entrypoint: "astro/assets/services/sharp",
    config: {
      formats: ["avif", "webp"],
      breakpoints: [640, 1280, 1920],
    },
  },
}

Architektur: Statisch, aber nicht starr

Die Architektur basiert auf Astro SSG mit Edge Functions für dynamische Teile, wie die Kontaktfreigabe nach Bot-Prüfung. Decap CMS ist gitbasiert: Inhalte liegen als Markdown im Repository, Änderungen laufen über Pull Requests. Cloudflare Pages hostet die Seite mit CDN-Kanten-Caching. Gehashte Assets haben lange Cache-Zeiten, während HTML kurz revalidiert wird. Sicherheit wird durch OAuth-Login für das CMS, Turnstile-Validierung für das Kontaktformular und restriktive Security Header gewährleistet.

Ich finde, dass ein gitbasiertes CMS für Solo-Entwickler effizienter ist als Datenbank-Lösungen. Versionierung, Portabilität und Pull-Request-Workflows sparen Wartungsaufwand. Edge Functions ersetzen oft einen vollen Backend-Server, wenn die Logik einfach ist, Latenz kritisch ist und Skalierung automatisch mit dem Hosting-Anbieter wächst.

Kurzbeispiel: Edge Function für Kontaktfreigabe

// [FILE] /functions/verify-turnstile.js
export async function onRequestPost(context) {
  const { token } = await context.request.json();
  const response = await fetch(
    "https://challenges.cloudflare.com/turnstile/v0/siteverify",
    { method: "POST", body: `secret=${SECRET_KEY}&response=${token}` }
  );
  return new Response(JSON.stringify({ success: true }), { status: 200 });
}

Performance als Leitlinie: Messbar und nutzerzentriert

Performance ist kein Feature, sondern das Ergebnis von Disziplin in der Priorisierung. Die größten Hebel liegen in Bildern, Fonts und kritischem CSS. Zielwerte sind Largest Contentful Paint unter 2,5 Sekunden, Cumulative Layout Shift nahe null und schnelle Interaktionen. Bilder werden als AVIF und WebP in gestaffelten Breiten generiert, mit expliziten Größenangaben im Markup. Schriften sind selbstgehostet und auf ein bis zwei Familien beschränkt. JavaScript wird als Inseln hydratisiert, nur bei Sichtbarkeit oder Leerlauf.

Screenshot der Startseite von ispringen.dev mit geöffneter Chrome DevTools Lighthouse Ansicht. Alle Kategorien zeigen 100 Punkte. Links das Hero mit Porträt von Tobias Müller sowie Navigation Home, Über mich, Arbeit, Blog und Kontakt. Visualisiert die Performance und Zugänglichkeit des Portfolios von Tobias Müller auf ispringen.dev.

Ich messe Performance mit Lighthouse im mobilen Profil sowie auf echten Geräten. Zielwerte sind bekannt, aber ich betone: „100/100 Lighthouse“ ist ein Nebenprodukt, kein Ziel. Entscheidend ist, dass die Seite auf realen Geräten stabil läuft. Die letzten Prozentpunkte zur vollen Bewertung erfordern Disziplin. Ich prüfe regelmäßig, welches Element den Largest Contentful Paint bestimmt.

Kurzbeispiel: LCP-Optimierung in 3 Schritten

Hero-Bild identifizieren: Größtes sichtbares Element im Viewport, z. B. hero.avif mit 1280px.
Priorisierung setzen: <link rel="preload" as="image" href="[HASH].avif" importance="high"> im <head>.
Platz reservieren: CSS mit aspect-ratio: 16/9 und min-height für den Container.

Erfolgskriterium: LCP unter 2,2 Sekunden bei 4G-Throttling-Test.

Umsetzung und Entwicklerworkflow

Die Content-Struktur basiert auf Astro Content Collections (Projekte, Blog, About, Impressum) mit Frontmatter-Metadaten. Bilder werden via astro:assets im Build zu AVIF und WebP konvertiert, mit gestaffelten Breiten und sizes-Attributen. Der Redaktionsworkflow ist einfach: Markdown schreiben, Commit, Push, woraufhin Cloudflare Pages das Deployment ausführt. Der CMS-Login erfolgt über OAuth mit GitHub-Konto. Dark Mode ist manuell schaltbar, Fokus-Zustände folgen WCAG-Kontrast (4.5:1).

Ich halte ein gitbasiertes CMS für effizienter als Headless-Datenbanken, weil es Versionierung, Backup und Deployment in einem Workflow abbildet. Die manuelle Dark-Mode-Schaltung reduziert Komplexität ohne Nutzenverlust, da die regionale Zielgruppe (DACH) mehrheitlich bewusste Entscheidungen trifft.

Sicherheit und Datenschutz: Minimaler Aufwand, maximale Wirkung

Sensible Informationen bleiben serverseitig. Öffentliche und vertrauliche Konfigurationen sind strikt getrennt. Content Security Policy (CSP) und Security Header sind restriktiv gesetzt. Der Administrationsbereich des CMS ist von der Indexierung ausgeschlossen. OAuth-Login für das CMS nutzt bestehende Entwicklerkonten. Die Kontaktfreigabe (E-Mail, Telefon) erfolgt erst nach erfolgreicher Turnstile-Bot-Prüfung via serverseitiger Validierung.

Ich finde, dass ein schlanker Security-Ansatz mit klaren Grenzen wirksamer ist als komplexe Systeme mit vielen Angriffsflächen. Datenschutz lässt sich durch Architektur entscheiden, nicht nur durch rechtliche Texte. Keine unnötige Client-seitige Datenverarbeitung und statische Auslieferung reduzieren das Exposure von Nutzerdaten.

Ergebnisse und Learnings: Was bleibt, was sich bewährt hat

Die Seite erreicht 100 Punkte im Lighthouse-Score (mobile Profil, August 2025) durch statische Generierung, gezieltes Caching und optimierte Assets. Largest Contentful Paint liegt unter 2,5 Sekunden auf echten Geräten. Der Redaktionsworkflow reduziert sich auf Markdown schreiben, Commit, Push und Live-Schaltung. Drei dynamische Edge-Funktionen decken alle interaktiven Anforderungen ab. Die regionale Fokussierung erhöht die Conversion-Rate bei lokalen Anfragen um etwa 40 Prozent.

Takeaways:

Statische Generierung mit Edge-Funktionen deckt 90 Prozent der Portfolio-Anforderungen ab, ohne Infrastruktur-Ballast.
Git-basiertes CMS reduziert Wartungsaufwand durch Versionierung, Portabilität und Pull-Request-Workflows.
Performance ist kein Ziel, sondern Ergebnis von Disziplin in der Priorisierung (Bilder, Fonts, kritisches CSS).
Regionale Fokussierung erhöht die Conversion-Rate, weil lokale Auftraggeber schneller Vertrauen aufbauen.

So zitierst du mich

Tobias Müller, „ispringen.dev – Architektur und Learnings eines statischen Portfolios“, ispringen.dev, 2025. Abgerufen am 27.08.2025.