Wenn Seiten langsam sind, denken viele sofort an Bilder oder JS. Häufig ist es aber simpler: TTFB (Server antwortet zu spät) + fehlendes Caching.
Wenn du das verstehst, kannst du oft in wenigen Stunden spürbar schneller werden – ohne „alles neu zu bauen“.
In diesem Guide lernst du:
- was TTFB, CDN und Caching wirklich bedeuten
- wie du die Ursache sauber diagnostizierst (statt blind zu optimieren)
- welche Inhalte du fast immer cachen solltest – und welche nicht
- welche Strategien in Next.js (App Router) typischerweise am meisten bringen
Was ist TTFB (Time To First Byte) – einfach erklärt
TTFB ist die Zeit vom Klick bis zum Moment, in dem dein Server das erste Byte der Antwort liefert.
Wenn TTFB hoch ist, fühlt es sich an wie:
- „Server denkt nach“
- „Seite reagiert erst nach 1–2 Sekunden“
Wichtig: TTFB ist nicht nur „Server-Power“. Oft steckt dahinter:
- dynamisches Rendering für Seiten, die eigentlich statisch sein könnten
- Datenbank-/API-Calls auf dem kritischen Pfad
- fehlende oder falsche Cache-Header
- schlechte Edge-/Region-Strategie (Nutzer weit weg vom Origin)
Was ist ein CDN – und was kann es (nicht)?
Ein CDN (Content Delivery Network) verteilt Inhalte geografisch näher an Nutzer.
Sehr gut für:
- Bilder
- CSS/JS
- Fonts
- andere statische Dateien
Ein CDN ist aber kein Zauberstab. Wenn dein HTML nicht cachebar ist oder jeder Request neu gerendert wird, bringt das CDN für die eigentliche Seite oft weniger als erwartet.
Was bedeutet Caching überhaupt?
Caching heißt: du beantwortest wiederholte Anfragen schneller, weil du nicht jedes Mal alles neu berechnest.
Es gibt (mindestens) drei Ebenen:
- Browser-Cache: Nutzer lädt Assets beim zweiten Besuch nicht erneut
- CDN/Edge-Cache: Inhalte werden nahe am Nutzer gespeichert
- Server-/App-Cache: Ergebnisse von Berechnungen/DB-Queries werden wiederverwendet
Das Ziel ist fast immer dasselbe:
Mehr Requests werden aus Cache bedient → weniger Arbeit pro Request → niedrigere TTFB.
Schritt 1: Richtig messen (damit du nicht im Nebel optimierst)
Messe immer mindestens:
- TTFB (Server/Edge)
- LCP (User-perceived Speed)
- INP (Interaktion)
Praxis: Wenn TTFB hoch ist, ist LCP oft automatisch schwierig – weil das HTML spät kommt.
Schritt 2: Entscheide deine Seiten-Strategie (statisch vs. dynamisch)
Die wichtigste Frage:
Muss diese Seite bei jedem Request neu berechnet werden?
Typische Zuordnung:
- Blogposts, Ratgeber, Case Studies: meistens statisch + seltene Updates → ideal für SSG/ISR
- Preislisten/Leistungsseiten: oft statisch + gelegentliche Updates → ISR oder statisch mit Deploy
- Dashboard/Login/Personalisierung: dynamisch, aber selektiv cachen
Wenn du „alles dynamisch“ machst, zahlst du bei jedem Besuch denselben Preis.
Schritt 3: HTML-Caching pragmatisch denken (SSG/ISR/Revalidation)
Wenn Inhalte selten ändern, ist das Standard-Rezept:
- statisch vor-rendern
- bei Bedarf revalidieren statt bei jedem Request neu rendern
Das Ergebnis: TTFB wird oft dramatisch besser, weil die Seite nicht mehr jedes Mal „gebaut“ wird.
Schritt 4: Cache-Control verstehen (die 80/20-Regeln)
1) Assets (CSS/JS/Images) fast immer lange cachen
Wenn Dateinamen versioniert sind (Hash/Fingerprint), kannst du sehr lange cachen.
2) HTML je nach Update-Frequenz
- seltene Updates → lange cachebar oder ISR
- häufige Updates → kurze TTL oder gezielte Revalidation
3) Nicht alles blind cachen
Nicht cachen (oder sehr vorsichtig), wenn:
- Inhalte personalisiert sind
- Auth-abhängig sind
- User-spezifische Preise/Status enthalten
Schritt 5: Typische Ursachen für hohe TTFB (und die Fixes)
Ursache A: Server rendert zu viel pro Request
Symptom: TTFB schwankt stark, besonders unter Last.
Fix:
- statisch/ISR wo möglich
- Datenabfragen aus dem kritischen Pfad holen
Ursache B: Datenquellen sind langsam
Symptom: TTFB ist konstant hoch, auch nachts.
Fix:
- DB/externen API-Call optimieren
- Ergebnisse cachen (Server/App)
- nur das laden, was above-the-fold nötig ist
Ursache C: CDN bringt nichts, weil nichts cachebar ist
Symptom: jeder Request geht zum Origin.
Fix:
- Response-Header prüfen
- sicherstellen, dass statische Assets wirklich cachebar sind
Quick-Checkliste: In 15 Minuten Klarheit bekommen
- Wie hoch ist TTFB auf den wichtigsten Seiten?
- Ist die Seite statisch möglich (Content ändert sich selten)?
- Sind Assets versioniert und lange cachebar?
- Kommt HTML immer vom Origin (oder teilweise aus Edge/Cache)?
Häufige Fehler
- Alles dynamisch rendern, obwohl es statisch sein könnte
- Cache-Control fehlt oder ist zu konservativ
- „CDN aktiviert“ wird mit „Caching funktioniert“ verwechselt
- HTML/Assets werden nicht getrennt gedacht
- Optimierung startet bei Bildern, obwohl TTFB der Engpass ist
1) Was du messen solltest
- TTFB
- LCP (oft Folge von TTFB)
- INP (JS/Interaktion)
2) CDN-Grundlagen
Ein CDN bringt Assets näher an den Nutzer.
Damit es wirkt:
- statische Dateien müssen cachebar sein
- Versionierung (Hash im Dateinamen) verhindert Cache-Probleme
3) HTML-Strategie: SSG/ISR statt alles dynamisch
Blogposts ändern sich selten. Daher:
- statisch prerendern
- bei Bedarf Revalidate
4) Cache-Control pragmatisch
- lange Cachezeiten für Images/CSS/JS
- HTML je nach Update-Frequenz
5) Deployment & Beobachtung
Wenn du deployest, teste:
- Response Headers
- Redirects/Canonicals
- ob
/sitemap.xmlaktuell ist
Mini-Plan: 60 Minuten für spürbar bessere Speed
- Top-3 Seiten auswählen (meist: Start, Service, Kontakt oder ein Top-Blogpost)
- TTFB messen und notieren (vorher)
- Prüfen: statisch/ISR möglich?
- Cache-Header für Assets checken
- Nach dem Deploy erneut messen (nachher)
Nächster Schritt
Wenn du willst, optimieren wir die Auslieferung (TTFB + Caching) und messen echte Verbesserungen.
