Advanced (Aktualisiert: 2.6.2026)

Webfont-Optimierung mit Claude Code

Praktische Webfont-Optimierung mit Claude Code: preload, font-display, Subsetting, CLS/LCP und sichere Prüfung.

Webfont-Optimierung mit Claude Code

Webfonts sind ein Rendering-Risiko

Webfonts wirken zuerst wie Design. In der Praxis sind sie auch ein Performance-Risiko. Wenn eine Schrift zu spät kommt, bleibt Text unsichtbar, eine Überschrift wechselt nachträglich die Breite, ein CTA-Button springt oder der LCP verschlechtert sich. LCP steht für Largest Contentful Paint, also den Zeitpunkt, an dem das größte sichtbare Inhaltselement gerendert ist. CLS steht für Cumulative Layout Shift, also unerwartete Layoutverschiebungen während des Ladens.

Bei Sprachen mit großen Zeichensätzen, etwa Japanisch, Chinesisch oder Koreanisch, ist das Risiko besonders hoch. Eine einzige Schriftdatei kann schwerer sein als der gesamte kritische CSS-Anteil. Claude Code kann hier helfen, aber nur mit klaren Vorgaben. “Optimiere die Fonts” führt leicht zu zu vielen preload-Tags, doppeltem Google-Fonts-CSS oder kaputten Fallbacks.

Dieser Leitfaden nutzt ein Astro-Projekt als Beispiel. Er behandelt Ladestrategie, preload, preconnect, font-display, variable Fonts, Subsetting, Self-Hosting gegen Drittanbieter, CLS/LCP-Risiken, Lighthouse- und WebPageTest-ähnliche Prüfungen sowie konkrete Claude-Code-Prompts. Für Browserdetails sind MDN zufont-display undrel="preload" die Basis. Für den Performance-Kontext dienen web.dev zuFont Best Practices, Optimize web fonts undWeb Vitals.

Strategie vor Codeänderung festlegen

Entscheide zuerst, welche Schrift wirklich für den ersten Viewport nötig ist. Nicht jede Markenentscheidung muss sofort geladen werden. Ein Blog kann den Fließtext mit Systemschriften lesbar machen und nur Überschriften mit einer Webfont gestalten. Ein SaaS-Dashboard kann eine variable Latin-Schrift self-hosten. Eine Landingpage muss Schrift und Hero-Bild gemeinsam betrachten, weil beide den ersten Eindruck und den LCP beeinflussen.

Use CaseStrategieVorteilTypischer Fehler
Mehrsprachiger BlogBody mit Systemfont, Headings mit subset WebfontText bleibt sofort lesbarDisplay-Font landet im gesamten Body
SaaS-DashboardLatin Variable Font self-hostenMehrere Gewichte in einer DateiUnbenutzte Italics, Achsen oder Sprachen bleiben drin
Landingpage HeroNur WOFF2 des LCP-Titels preloadenKernbotschaft erscheint frühAlle Gewichte konkurrieren mit dem Hero-Bild
Alte Icon-FontDurch SVG oder Icon-Komponenten ersetzenEntfernt eine Font-AnfragePseudo-Element-CSS wird vergessen

Für Inhaltsseiten ist die langweilige Lösung oft die beste: erst Lesbarkeit, dann Marke. Für Produktoberflächen lohnt sich eine variable Schrift, wenn tatsächlich mehrere Gewichte genutzt werden. Für Hero-Bereiche lies zusätzlich den Artikel zurBildoptimierung mit Claude Code. Die breitere Einordnung steht inPerformance-Optimierung mit Claude Code.

preload und preconnect in Astro umsetzen

preload ist ein starker Browser-Hinweis. Nutze ihn nur für ein oder zwei WOFF2-Dateien, die im ersten Viewport sicher verwendet werden. Preloade nicht alle Gewichte, nicht alle Sprachen und keine Schrift, die erst nach dem Scrollen erscheint. Bei Self-Hosting vom eigenen Origin brauchst du normalerweise kein preconnect. Bei Google Fonts oder anderen Drittanbietern kann preconnect für CSS- und Font-Origin sinnvoll sein.

---
// src/layouts/BaseLayout.astro
const criticalFonts = [
  { href: "/fonts/inter-var-latin.woff2", type: "font/woff2" },
  { href: "/fonts/noto-sans-jp-latin-kana.woff2", type: "font/woff2" },
];

const usesGoogleFonts = false;
---

<html lang="de">
  <head>
    {criticalFonts.map((font) => (
      <link rel="preload" href={font.href} as="font" type={font.type} crossorigin />
    ))}

    {usesGoogleFonts && <link rel="preconnect" href="https://fonts.googleapis.com" />}
    {usesGoogleFonts && <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />}

    <link rel="stylesheet" href="/styles/fonts.css" />
  </head>
  <body>
    <slot />
  </body>
</html>

Prüfe danach das generierte HTML. Der href des Preloads muss zur src-URL in @font-face passen. Die Attribute as="font", type="font/woff2" und crossorigin müssen vorhanden sein. Die vorgeladene Schrift muss im ersten Viewport wirklich verwendet werden. Eine Warnung über einen ungenutzten Preload ist ein Signal, den Hinweis zu entfernen.

font-display ohne CLS einsetzen

font-display: swap zeigt zunächst eine Fallback-Schrift und tauscht später zur Webfont. Das reduziert unsichtbaren Text, kann aber CLS erzeugen, wenn Fallback und Zielschrift unterschiedliche Metriken haben. Für nicht kritischen Text auf langsamen Verbindungen kann optional sinnvoll sein, weil der Browser dann eher bei der Fallback-Schrift bleibt.

/* public/styles/fonts.css */
@font-face {
  font-family: "InterVariable";
  src: url("/fonts/inter-var-latin.woff2") format("woff2");
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "NotoSansJPSubset";
  src: url("/fonts/noto-sans-jp-latin-kana.woff2") format("woff2");
  font-weight: 400 700;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF, U+3000-30FF, U+FF00-FFEF;
}

@font-face {
  font-family: "InterFallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

:root {
  --font-ui: "InterVariable", "InterFallback", system-ui, sans-serif;
  --font-ja: "NotoSansJPSubset", "Hiragino Sans", "Yu Gothic", sans-serif;
}

body {
  font-family: var(--font-ui);
}

article {
  font-family: var(--font-ja);
}

Der MDN-Artikel zuunicode-range erklärt, wie eine @font-face-Regel nur für bestimmte Zeichenbereiche gilt. Das verkleinert die Datei nicht automatisch. Für weniger Bytes musst du eine kleinere WOFF2-Datei erzeugen.

Bytes mit Variable Fonts und Subsetting reduzieren

Variable Fonts können mehrere statische Dateien ersetzen, wenn eine Oberfläche mehrere Gewichte nutzt. Sie sind aber nicht automatisch kleiner. Viele Achsen, Italics und große Sprachbereiche können die Datei schwer machen. Lass Claude Code zuerst echte Nutzung, CSS-Regeln und benötigte Gewichte prüfen.

Subsetting erzeugt eine Schriftdatei mit nur den benötigten Zeichen. Das ist stark für Navigation, Hero-Headlines, feste Labels und CTA-Texte. Für Artikeltext ist es riskanter, weil neue Inhalte neue Zeichen mitbringen können.

# Create a WOFF2 subset with Latin, punctuation, kana, and full-width forms.
python -m pip install "fonttools[woff]"
mkdir -p public/fonts

pyftsubset ./vendor-fonts/NotoSansJP-Regular.ttf \
  --output-file=./public/fonts/noto-sans-jp-latin-kana.woff2 \
  --flavor=woff2 \
  --layout-features='*' \
  --unicodes="U+0000-00FF,U+3000-30FF,U+FF00-FFEF"

Dieser Befehl enthält bewusst nicht die meisten Kanji. Für Navigation und feste Headings ist das gut, für japanischen Fließtext nicht. Für Body-Text solltest du Zeichen aus den MDX-Dateien extrahieren und über --text-file einspielen oder ein separates Kanji-Subset erzeugen. Prüfe vorher die Lizenz, besonders bei Self-Hosting und Veränderung der Datei.

Self-Host oder Drittanbieter

Self-Hosting bedeutet, dass die WOFF2-Dateien von deinem eigenen Ursprung kommen. Du kontrollierst URL, Cache-Header, Fingerprints, Preload und Subsetting. Dafür bist du für Lizenz, Updates und Build-Skripte verantwortlich. Drittanbieter sind schnell eingerichtet, erzeugen aber externe Verbindungen und oft eine zusätzliche CSS-Anfrage.

KriteriumSelf-HostDrittanbieter
VerbindungGleicher OriginDNS, TLS, CSS-Origin, Font-Origin
CacheVoll kontrollierbarVom Anbieter abhängig
PreloadExakte DateiURL kommt oft aus Anbieter-CSS
SubsettingFreiServiceabhängig
BetriebMehr VerantwortungEinfacher Start, mehr Abhängigkeit

Für Seiten mit Umsatzbezug ist Self-Hosting der kritischen ersten Schrift oft die bessere Wahl. Dekorative Schriften sollten später geladen werden. Wenn du einen Drittanbieter nutzt, lade nur verwendete Gewichte, nutze display=swap und entferne alte CSS-Links nach einer Migration.

Mit Lighthouse und WebPageTest-artiger Waterfall prüfen

Nach der Umsetzung reicht ein Blick auf die Seite nicht. Führe Lighthouse aus und prüfe LCP, CLS und Font-Audits. Danach analysiere die Network-Waterfall wie in WebPageTest: HTML, CSS, kritische Schrift, Hero-Bild, JavaScript. Die Schrift soll früh starten, aber CSS und LCP-Element nicht blockieren.

URL="https://example.com/"
npx --yes lighthouse "$URL" \
  --only-categories=performance \
  --chrome-flags="--headless" \
  --output=json \
  --output-path=./lighthouse-fonts.json

node -e "const r=require('./lighthouse-fonts.json'); for (const id of ['largest-contentful-paint','cumulative-layout-shift','font-display']) console.log(id, r.audits[id]?.displayValue ?? r.audits[id]?.score ?? 'n/a')"

Gute Signale: nur ein oder zwei kritische WOFF2-Dateien starten früh; es gibt keinen ungenutzten Preload; Wiederholungsbesuche nutzen Cache; Headline und CTA springen beim Font-Swap nicht; nach Self-Hosting bleibt kein Google-Fonts-CSS übrig; dieselbe Datei wird nicht doppelt geladen.

Konkrete Fehler: Eine Bold-Datei wird vorgeladen, obwohl der erste Viewport nur Regular nutzt. Ein Subset vergisst Satzzeichen oder Fullwidth-Ziffern. font-display: swap wird ergänzt, aber die Fallback-Metriken bleiben unpassend. Eine Icon-Font wird weiter geladen, obwohl SVG-Icons vorhanden sind.

Sichere Claude-Code-Prompts

Trenne Audit, Implementierung und Verifikation. Starte ohne Schreibrechte im Prompt.

Audit web font loading in this Astro site. Do not edit files yet.

Find:
- @font-face, Google Fonts, Fontsource, and CSS import locations
- Font files used above the fold
- preload and preconnect hints that are missing or unnecessary
- CLS or LCP risks caused by font swapping
- Candidates for self-hosting, variable fonts, and subsetting

Return:
- A prioritized table of changes
- Files that should be edited and files that must not be touched
- Verification commands and residual risks

Danach begrenzt du die Umsetzung.

Implement web font optimization only in these files:
- src/layouts/BaseLayout.astro
- public/styles/fonts.css
- generated files under public/fonts/

Acceptance criteria:
- Preload only WOFF2 files used in the first viewport
- Do not add preconnect when fonts are self-hosted
- Every @font-face has a deliberate font-display value
- Fallback metrics are adjusted to reduce CLS
- Existing routes, article slugs, hero images, and unrelated content are untouched

Verification:
- npm run build
- node scripts/check-code-fences.mjs
- Lighthouse check for LCP, CLS, and font-display
- Report what could not be verified

Praktisches Ergebnis und CTA

In Masas Arbeitsweise funktionierte eine konkrete Anweisung besser als eine allgemeine. “Preloade nur die Schrift der LCP-Überschrift, halte Body-Text mit Systemfonts lesbar und berichte CLS-Risiken” führte zu kleineren Diffs. Auf einer japanischen Artikelseite machte ein Latin/Kana-Subset den ersten Viewport stabiler, aber vollständiger Body-Support brauchte eine separate Zeichenermittlung. Die wichtigste Prüfung war eine langsame mobile Waterfall plus manuelle Beobachtung von Headline und CTA während des Swaps.

Für Teams gehören diese Regeln in CLAUDE.md. Starte mit demkostenlosen Cheat Sheet für sichere Befehle, nutzeProdukt-Templates für wiederholbare Prompts und prüfeClaude-Code-Training, wenn Core Web Vitals, Artikelqualität und Monetarisierungs-CTA gemeinsam verbessert werden sollen.

Selbstcheck vor Veröffentlichung: Dieser Artikel enthält mehr als drei konkrete Use Cases, kopierbare Astro/CSS/bash-Beispiele, offizielle MDN- und web.dev-Links, interne Links, konkrete Fehlerbilder, einen natürlichen CTA und eine praktische Verifikationsnotiz.

#Claude Code #Webfonts #Core Web Vitals #Astro #Performance
Kostenlos

Kostenloses PDF: Claude-Code-Cheatsheet

E-Mail eintragen und eine Seite mit Befehlen, Review-Gewohnheiten und sicheren Workflows herunterladen.

Wir schützen Ihre Daten und senden keinen Spam.

Masa

Über den Autor

Masa

Engineer für praktische Claude-Code-Workflows und Team-Einführung.

Ähnliche Artikel