Tech-Deep-Dive · Homepage
Static-First. 0 KB JS.
Lighthouse 100/100/100/100 als Baseline.
Marketing-Sites als Static-Builds mit Islands-Hydration, kein SPA-Bloat, kein Framework-Overhead. Schema-validierter Content-Layer, Image-Pipeline mit modernen Formaten, Tracking-Snippet-Verify als Build-Gate, IndexNow-Push für Tag-1-3-Indexierung. Live-Reference: reiterverein-salzkotten.de und sandra-hietel.de.
Capability-Stack
Acht Schichten, was sie können.
Konkrete Tool-Wahl behalte ich für mich, was zählt sind die Eigenschaften: 0 KB JS by default, Schema-validierter Content, Lighthouse 100 als Block-Gate.
Render-Modell
Static-First mit Islands-Hydration
0 KB JS by default · LCP < 1.2 s · CLS 0 Content-Layer
Schema-validiertes Frontmatter
Type-safe getCollection · Build-Error bei Drift Image-Pipeline
WebP + AVIF + JPEG Auto-Variants
srcset responsive · Lazy-Loading default · Hash-Cache-Busting Schema
JSON-LD inline pro Page
Article + BreadcrumbList Standard · validiert beim Build Tracking
Cookieless via eigenes Beacon-Snippet
Build-Gate prüft, dass Snippet im Output landet Deploy
Static-Files via SSH/lftp zum Hoster
EU-Hosting · CI < 2 min · Cache-Bust + Verify Indexing
Sitemap-Submit + IndexNow-Push
Tag 1-3 indexiert statt Tag 14-21 Performance-Gate
Lighthouse 100 als Build-Block
Performance/A11y/Best-Practice/SEO je 100 FAQ
Tech-Fragen.
Warum Static-First statt SSR/SPA-Framework?
Marketing-Sites brauchen kein Hydration-by-Default. Islands-Pattern hydratet nur was wirklich interaktiv ist (z.B. ein optionaler Cookie-Banner), der Rest bleibt reines Static-HTML. Bundle-Size oft 5x kleiner als bei SPA-Frameworks, Lighthouse 100/100/100/100 ohne Tuning erreichbar, TTFB unter 50 ms aus Edge oder klassischem Webhosting.
Type-Safety auf Marketing-Sites?
Content-Layer mit Schema-validiertem Frontmatter, jeder Blog-Post / jede Page-Datei wird beim Build gegen ein Schema geprüft. Type-safe Iterator gibt typed Arrays zurück, Frontend-Templates haben Autocomplete auf jeden Frontmatter-Key. Schema-Drift wird zum Build-Error, nicht zum 404 in Production.
Image-Optimierung?
Image-Pipeline auf Build-Zeit: jedes importierte Bild wird in WebP plus AVIF plus JPEG-Fallback generiert, srcset für responsive, Lazy-Loading per Default, Hash-Cache-Busting auf Asset-URLs. Original-Quellen in /src/assets/ werden processed, /public/-Files bleiben unprocessed (Logos, Icons). Browser kriegt das beste Format, das er versteht.
Wie sieht die Deploy-Pipeline aus?
CI: Cache-Bust (rm -rf Build-Caches) + Install + Em-Dash-Replace + Build + Tracking-Snippet-Verify (grep dist/index.html nach dem Tracking-Snippet. Build bricht ab wenn das Snippet im Output fehlt) + lftp-Upload zum Hoster. Plus IndexNow-Ping mit allen Sitemap-URLs an Bing/Yandex/Seznam. Ergebnis: Tag 1-3 Indexierung statt Tag 14-21.
Performance-Targets?
Lighthouse Mobile 100/100/100/100 als Build-Gate (Performance/Accessibility/Best-Practices/SEO), LCP < 1.2 s, CLS 0, INP < 100 ms. Erreicht durch: Static-HTML statt SSR, Font-Preload nur woff2, Critical-CSS inline, kein Hydration auf Marketing-Sections, Image-Pipeline mit modernen Formaten, Resource-Hints im BaseLayout. Hosting: klassisches Webhosting reicht, kein VPS nötig für Static-Sites.
Wie wird Schema/SEO behandelt?
JSON-LD inline pro Page: Article + BreadcrumbList als Standard, plus spezifische Types je Page-Type (Service, FAQPage, LocalBusiness, Person, Event). Per-Page-llms.txt für Hub-Services, globale /llms.txt als Site-Index. Schema wird beim Build via Validator gegen Schema.org geprüft, Konventionen (z.B. Article für Portfolio-Cases) als Repo-Schema-Rules.
Stack-Sparring oder Code-Walkthrough?
30 Min Erstgespräch, kostenlos. Walkthrough an reiterverein-salzkotten.de oder sandra-hietel.de.
Erstgespräch buchen