TTFB, CDN und Caching einfach erklärt: was die Begriffe bedeuten, wie du die Server-Antwortzeit misst, welche Cache-Ebenen es gibt, welches Hosting passt und welche Maßnahmen zuerst wirken.
Wenn eine Website langsam ist, schauen die meisten zuerst auf Bilder und Skripte. Oft ist das Problem aber simpler und liegt davor: Der Server braucht eine Sekunde, bis er überhaupt antwortet. In dieser Sekunde kann der Browser nichts tun, egal wie gut die Bilder optimiert sind. Wer das versteht, kann seine Website in wenigen Stunden spürbar schneller machen, ohne sie neu zu bauen.
Du bekommst:
- die Begriffe TTFB, CDN, Cache und Origin ohne Fachchinesisch erklärt
- Schwellenwerte und Werkzeuge, um die Server-Antwortzeit selbst zu messen
- die vier Cache-Ebenen und was auf welcher Ebene passiert
- eine Entscheidungshilfe für Hosting, ob WordPress, Shopify oder Next.js
- Cache-Regeln, die fast immer stimmen, und die Liste dessen, was nie gecacht werden darf
- einen 60-Minuten-Plan mit Messung vorher und nachher
Der Artikel ist für Inhaber und Entscheider geschrieben, die eine Hosting-Rechnung, ein Agentur-Angebot oder einen PageSpeed-Bericht einordnen wollen. Die technischen Abschnitte sind gekennzeichnet.
Kurzantwort: Warum der Server oft die eigentliche Bremse ist
TTFB (Time to First Byte) ist die Zeit vom Aufruf bis zum ersten Stück Antwort des Servers. Google stuft bis 0,8 Sekunden als gut ein, und jede Zehntelsekunde darüber verschiebt alles, was danach kommt, vor allem den LCP. Hoher TTFB entsteht fast immer aus drei Gründen: Die Seite wird bei jedem Aufruf neu berechnet, obwohl sie sich selten ändert; der Server ist zu schwach oder steht zu weit weg; oder Datenbank und Plugins bremsen im Hintergrund. Die Lösung heißt Caching: fertige Seiten und Dateien werden zwischengespeichert und beim nächsten Aufruf direkt ausgeliefert, statt neu gebaut zu werden. Das passiert auf mehreren Ebenen, im Browser, in einem CDN (einem Netz aus Servern nahe beim Besucher), auf dem Server und in der Anwendung. Für die meisten Unternehmenswebsites reicht es, den Seiten-Cache zu aktivieren, ein CDN vorzuschalten und Cache-Regeln für Dateien zu setzen. Das dauert Stunden, nicht Wochen.
Was TTFB, CDN und Caching für dein Unternehmen bedeuten
Stell dir vor, ein Kunde ruft in deinem Betrieb an, und es dauert eine Sekunde, bis überhaupt das Freizeichen kommt. Dann klingelt es, dann hebt jemand ab. Der TTFB ist dieses Warten aufs Freizeichen: Zeit, in der nichts passiert und die sich zu allem anderen addiert.
Konkret bedeutet das:
- Jede Seite, jeder Klick: Der TTFB fällt nicht nur beim ersten Besuch an, sondern bei jedem Seitenwechsel. Ein Besucher, der fünf Seiten ansieht, wartet fünfmal.
- LCP und Ranking: Der LCP, einer der drei Core Web Vitals, kann nie besser sein als der TTFB plus die Zeit für das Hauptbild. Wer mit 1,5 Sekunden TTFB startet, bekommt den LCP kaum unter 2,5 Sekunden. Was die Core Web Vitals für dein Unternehmen bedeuten, steht im Artikel Core Web Vitals erklärt.
- Werbekosten: Klicks aus Anzeigen, die auf eine langsame Seite führen, bezahlst du, auch wenn der Besucher vor dem ersten Byte wieder weg ist.
- Lastspitzen: Ohne Caching berechnet der Server jede Anfrage neu. Ein Beitrag, der auf Social Media gut läuft, kann eine ungecachte WordPress-Seite in die Knie zwingen. Mit Cache liefert der Server dieselbe fertige Seite tausendfach aus, ohne zu rechnen.
- Hosting-Kosten: Caching senkt die Last so stark, dass oft ein kleinerer Tarif reicht.
Begriffe erklärt: TTFB, Origin, CDN, Cache
| Begriff | Was es bedeutet | Bild aus dem Alltag |
|---|---|---|
| TTFB (Time to First Byte) | Zeit vom Aufruf bis zum ersten Stück Antwort. Enthält Namensauflösung, Verbindungsaufbau, Verschlüsselung, Weiterleitungen und die Rechenzeit des Servers. | Die Wartezeit, bis im Restaurant überhaupt jemand an den Tisch kommt. |
| Origin | Der eigentliche Server, auf dem deine Website liegt und berechnet wird. | Die Küche. |
| Cache | Ein Zwischenspeicher, der fertige Ergebnisse aufhebt, damit sie nicht neu berechnet werden müssen. | Die Warmhalteplatte mit fertigen Tagesgerichten. |
| CDN (Content Delivery Network) | Ein Netz aus Servern an vielen Standorten, das gecachte Inhalte in der Nähe des Besuchers ausliefert. | Filialen in jeder Stadt statt einer einzigen Zentrale. |
| Edge | Der CDN-Server, der dem Besucher am nächsten ist. | Die Filiale um die Ecke. |
| Cache-Hit und Cache-Miss | Hit: Die Antwort kam aus dem Cache. Miss: Der Cache war leer, die Anfrage ging zum Origin. | Gericht steht bereit oder muss frisch gekocht werden. |
| Cache-Control | Ein Header, mit dem der Server sagt, wie lange und von wem eine Antwort zwischengespeichert werden darf. | Das Haltbarkeitsdatum auf der Warmhalteplatte. |
| Revalidierung | Der Cache prüft nach Ablauf, ob es eine neue Version gibt, und liefert bis dahin die alte aus. | Nachkochen, während die letzte Portion noch verkauft wird. |
TTFB messen: Werkzeuge und Schwellenwerte
Miss immer die Seiten, die für dein Geschäft wichtig sind: Startseite, die wichtigste Leistungs- oder Produktseite und die Kontaktseite. Und miss aus Deutschland, weil deine Kunden von hier aus zugreifen.
| Einstufung | TTFB | Was das in der Praxis heißt |
|---|---|---|
| Gut | bis 0,8 s | Grundlage für einen guten LCP; gecachte Seiten liegen oft deutlich darunter |
| Verbesserungswürdig | 0,8 bis 1,8 s | Typisch für ungecachte WordPress-Seiten auf einfachem Hosting |
| Schlecht | über 1,8 s | Server rechnet bei jedem Aufruf, Datenbank oder Plugins bremsen, oder der Server steht auf einem anderen Kontinent |
| Werkzeug | Was es zeigt | Für wen |
|---|---|---|
| PageSpeed Insights | Felddaten echter Nutzer unter „Zeit bis zum ersten Byte“ sowie in der Diagnose „Server-Antwortzeit reduzieren“ | Alle, fünf Minuten, kostenlos |
| Chrome DevTools, Netzwerk-Tab | Bei der ersten Anfrage unter „Timing“ die Zeile „Warten auf Serverantwort“; dazu die Antwort-Header mit Cache-Status | Wer selbst nachsehen will |
| WebPageTest | Messung von einem wählbaren Standort, zum Beispiel Frankfurt, mit Wasserfall-Diagramm | Vergleich vor und nach einer Änderung |
| Search Console, Bericht Core Web Vitals | Kein TTFB direkt, aber LCP-Probleme, die oft auf TTFB zurückgehen | Beobachtung über Monate |
Wichtig beim Messen: Zweimal laden. Der erste Aufruf kann ein Cache-Miss sein, bei dem der Server die Seite frisch berechnet. Der zweite Aufruf zeigt, ob der Cache greift. Wenn beide Werte gleich hoch sind, cacht nichts. Wenn der zweite schnell ist, funktioniert der Cache, und die Frage ist nur, wie oft er leer ist.
Tipp: Schau in den Antwort-Headern nach Einträgen wie „x-cache“, „cf-cache-status“ oder „x-vercel-cache“. Steht dort HIT, kam die Seite aus dem Cache. Steht dort MISS oder fehlt der Eintrag bei jedem Aufruf, wird jede Anfrage vom Origin berechnet, und genau das ist der Ansatzpunkt.
Typische Ursachen für hohen TTFB
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| TTFB schwankt stark, tagsüber schlechter als nachts | Server berechnet jede Seite neu und ist unter Last überfordert | Seiten-Cache aktivieren, statische Auslieferung, bei Bedarf stärkerer Tarif |
| TTFB konstant hoch, auch nachts und im Cache | Langsame Datenbank, zu viele Plugins, veraltete PHP-Version, externe API im kritischen Pfad | Plugins reduzieren, PHP aktualisieren, Datenbank aufräumen, externe Abfragen cachen |
| TTFB gut aus den USA, schlecht aus Deutschland | Server steht auf einem anderen Kontinent | Hosting mit Standort Deutschland oder EU, CDN vorschalten |
| Erster Aufruf langsam, zweiter schnell | Cache funktioniert, ist aber oft leer, weil er zu kurz hält oder zu oft geleert wird | Cache-Dauer erhöhen, Revalidierung statt Leerung, Cache vorwärmen |
| Jeder Aufruf gleich langsam trotz CDN | CDN cacht nur Dateien, das HTML geht immer zum Origin | Cache-Header für HTML setzen, Seiten-Cache am Origin |
| TTFB gut, Seite trotzdem langsam | Der Engpass liegt nicht beim Server, sondern bei Bildern, Skripten oder Schriften | Weiter beim LCP und den Skripten, siehe Artikel zu Bildern |
| Mehrere Weiterleitungen vor der Seite | http auf https, dann ohne www auf www, dann mit Schrägstrich | Weiterleitungen auf eine einzige zusammenfassen, interne Links direkt auf die Zielversion |
Der letzte Punkt wird oft übersehen: Jede Weiterleitung ist ein kompletter Roundtrip zum Server, und drei hintereinander können den TTFB verdoppeln. Wie du Varianten sauber auf eine Adresse führst, steht im Artikel zu Canonicals, Redirects und www.
Die Cache-Ebenen: Browser, CDN, Server, Anwendung
Caching passiert nicht an einem Ort, sondern auf mehreren Ebenen hintereinander. Jede Ebene fängt Anfragen ab, bevor sie die nächste erreichen.
| Ebene | Wo | Was gecacht wird | Gesteuert durch | Typischer Effekt |
|---|---|---|---|---|
| Browser-Cache | Auf dem Gerät des Besuchers | Bilder, CSS, JavaScript, Schriften; selten HTML | Cache-Control-Header | Zweiter Seitenaufruf und alle weiteren Seiten laden Dateien nicht erneut |
| CDN- oder Edge-Cache | Auf Servern nahe beim Besucher | Dateien fast immer; HTML, wenn erlaubt | Cache-Control, s-maxage, CDN-Regeln | Anfragen erreichen den Origin gar nicht mehr, TTFB sinkt auf wenige Dutzend Millisekunden |
| Server- oder Seiten-Cache | Auf dem Origin, vor der Anwendung | Fertig gerenderte HTML-Seiten | Caching-Plugin, Webserver-Konfiguration, Managed-Hosting | WordPress und andere CMS müssen die Seite nicht bei jedem Aufruf aus der Datenbank bauen |
| Anwendungs- oder Objekt-Cache | In der Anwendung | Datenbankabfragen, API-Antworten, Berechnungen | Redis, Memcached, Framework-Funktionen | Auch dynamische Seiten werden schneller, weil teure Teile wiederverwendet werden |
Für eine Unternehmenswebsite ohne Login sind die ersten drei Ebenen entscheidend. Die vierte wird wichtig, sobald es Kundenkonten, Konfiguratoren oder personalisierte Inhalte gibt, also vor allem bei Onlineshops und Software.
Statisch oder dynamisch: die wichtigste Entscheidung pro Seite
Die Frage, die über den TTFB entscheidet, lautet: Muss diese Seite bei jedem Aufruf neu berechnet werden? Für die meisten Seiten einer Unternehmenswebsite ist die Antwort nein. Eine Leistungsseite ändert sich ein paar Mal im Jahr, ein Blogartikel nach dem Veröffentlichen fast nie. Trotzdem berechnen viele Systeme genau diese Seiten bei jedem Aufruf neu, als wären sie ein Kundenkonto.
| Seitentyp | Ändert sich | Empfohlene Strategie | Effekt auf TTFB |
|---|---|---|---|
| Startseite, Leistungsseiten, Über uns | Selten | Statisch vorrendern, lange cachen, bei Änderung neu erzeugen | Sehr niedrig, kommt aus dem Cache |
| Blogartikel, Ratgeber, Case Studies | Nach Veröffentlichung fast nie | Statisch, Cache über Stunden oder Tage, Revalidierung bei Update | Sehr niedrig |
| Produktlisten und Produktseiten | Bei Preis- oder Bestandsänderung | Statisch mit kurzer Revalidierung (Minuten) oder Seiten-Cache, Bestand per kleinem Nachladen | Niedrig |
| Kontaktseite mit Formular | Nie, außer dem Formular | Seite statisch, Formularversand dynamisch | Sehr niedrig |
| Suche, Filter | Bei jeder Eingabe | Dynamisch, Ergebnisse kurz cachen | Mittel, akzeptabel |
| Warenkorb, Kasse, Kundenkonto | Pro Besucher | Dynamisch, nie cachen, Anwendungs-Cache für Teile | Höher, aber unvermeidbar |
In Next.js heißt dieses Prinzip statische Generierung mit Revalidierung: Seiten werden einmal gebaut, als fertige Dateien ausgeliefert und nach einem festgelegten Intervall oder auf Befehl neu erzeugt. In WordPress erledigt ein Seiten-Cache-Plugin dasselbe: Es speichert die fertige Seite und liefert sie aus, bis jemand den Inhalt ändert. Shopify cacht seine Seiten selbst. Warum Next.js-Websites von Haus aus schneller antworten und wann sich der Unterschied lohnt, steht im Artikel WordPress oder individuelle Website.
Hosting-Entscheidung: Shared, Managed, VPS, Plattform
Das Hosting bestimmt, wie stark der Origin ist, wo er steht und welche Cache-Ebenen du ohne Zusatzaufwand bekommst. Preise ändern sich ständig, deshalb hier nur die Kriterien.
| Hosting-Art | Passt zu | Vorteile | Nachteile | Worauf achten |
|---|---|---|---|---|
| Shared Hosting (Webspace-Paket) | Kleine Visitenkarten-Websites mit wenig Traffic | Günstig, wartungsfrei | Geteilter Server, schwankender TTFB, oft kein Seiten-Cache | Standort Deutschland, aktuelle PHP-Version, HTTP/2 oder HTTP/3, SSD |
| Managed WordPress-Hosting | WordPress-Websites von Praxen, Handwerk, Gastronomie, Mittelstand | Seiten-Cache und CDN eingebaut, Updates und Backups inklusive, Support kennt WordPress | Teurer als Webspace, an WordPress gebunden | Server in Deutschland, Cache ohne eigene Konfiguration, Staging-Umgebung |
| VPS oder eigener Server | Individuelle Software, Shops mit Sonderlogik, Unternehmen mit eigener IT | Volle Kontrolle, feste Leistung | Du bist für Sicherheit, Updates und Cache-Konfiguration selbst verantwortlich | Nur mit jemandem, der den Server betreut; sonst wird er zur Sicherheitslücke |
| Plattform-Hosting (Vercel, Netlify, Cloudflare Pages) | Next.js und andere moderne Frameworks | Globales Edge-Netz eingebaut, statische Seiten kommen direkt aus dem Cache, Deployment per Git | Kosten steigen mit Traffic und Rechenzeit, Abhängigkeit vom Anbieter | Region für Serverfunktionen auf Frankfurt setzen, Kostenmodell verstehen |
| Shopify (gehostet) | Onlineshops | Hosting, CDN und Caching inklusive, keine Serverwartung | Kein Zugriff auf Server oder Cache | Apps sparsam installieren, Theme schlank halten |
Zwei Faustregeln für Unternehmen aus Magdeburg und Umgebung: Der Server steht in Deutschland oder zumindest in der EU, wegen Latenz und Datenschutz. Und das Hosting bringt einen Seiten-Cache mit, damit du ihn nicht selbst konfigurieren musst. Was ein Hosting-Wechsel im Rahmen einer Wartung bedeutet, steht im Artikel zu Website-Wartung und Sicherheit.
Cache-Regeln, die fast immer stimmen
Dieser Abschnitt ist technisch und richtet sich an Entwickler oder an alle, die ihrer Agentur eine Vorgabe machen wollen. Der Server steuert das Caching über den Header Cache-Control, und drei Regeln decken die meisten Fälle ab:
# 1. Versionierte Dateien: CSS, JavaScript, Bilder mit Hash im Dateinamen
Cache-Control: public, max-age=31536000, immutable
# 2. HTML-Seiten, die sich selten ändern
Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400
# 3. Personalisierte Seiten: Kundenkonto, Warenkorb, Kasse
Cache-Control: private, no-store
Was dahinter steckt:
- Regel 1: Dateien, deren Name sich bei jeder Änderung ändert (etwa durch einen Hash wie main.a1b2c3.js), dürfen ein Jahr lang gecacht werden. Ändert sich die Datei, bekommt sie einen neuen Namen, und der alte Cache stört nicht. Next.js macht das für alle Dateien unter /_next/static automatisch, WordPress-Caching-Plugins setzen ähnliche Regeln.
- Regel 2: Das HTML darf im CDN eine Stunde lang liegen (s-maxage gilt nur für geteilte Caches wie CDNs, nicht für den Browser). Danach liefert das CDN noch bis zu einem Tag die alte Version aus, während es im Hintergrund die neue holt (stale-while-revalidate). Der Besucher wartet nie, und die Inhalte sind höchstens eine Stunde alt.
- Regel 3: Seiten mit persönlichen Daten werden nirgends zwischengespeichert. Das ist keine Performance-Frage, sondern eine Sicherheitsfrage.
Bilder ohne Hash im Namen, etwa aus einem CMS-Upload, bekommen eine mittlere Dauer, zum Beispiel eine Woche, damit ein ausgetauschtes Bild nicht ein Jahr lang alt bleibt. Wie du Bilder so ausspielst, dass sie den LCP nicht bremsen, steht im Artikel zu LCP und Bildern.
Tipp: Nach jeder Änderung an Cache-Regeln einmal im Browser prüfen, ob ein Update auf der Website tatsächlich ankommt. Wenn eine Textänderung erst nach Stunden sichtbar wird, ist die Cache-Dauer für HTML zu lang oder die Revalidierung fehlt. Wenn sie sofort da ist, aber der TTFB hoch bleibt, greift der Cache nicht.
Was nicht gecacht werden darf
Caching ist mächtig, und genau deshalb gibt es eine Liste von Dingen, bei denen ein Fehler mehr kostet als die gewonnene Geschwindigkeit:
- Alles hinter einem Login: Kundenkonten, Mitarbeiterbereiche, Dashboards.
- Warenkorb, Kasse, Bestellbestätigung: Ein gecachter Warenkorb zeigt dem nächsten Besucher die Bestellung des vorigen.
- Formulare mit Sicherheitstoken: Ein gecachtes Token ist abgelaufen oder gehört jemand anderem, das Formular schlägt fehl.
- Kundenspezifische Preise und Bestände: Wenn Stammkunden andere Preise sehen, darf diese Seite nicht aus einem geteilten Cache kommen.
- Antworten mit personenbezogenen Daten: API-Antworten, die Namen, Adressen oder Bestellungen enthalten.
- Consent-abhängige Inhalte: Ob Tracking läuft, hängt von der Einwilligung ab. Die Einwilligung selbst gehört nicht in einen geteilten Cache.
Die gute Nachricht: Auf einer typischen Unternehmenswebsite betrifft das nur das Kontaktformular, und dessen Versand ist ohnehin dynamisch. Bei einem Onlineshop dagegen gehört die Trennung zwischen cachebaren Katalogseiten und dynamischen Kundenseiten zur Grundarchitektur. Was dabei häufig schiefgeht, steht im Artikel zu Online-Shop Kosten und Fehlern.
Beispiel: Vorher und nachher bei einer WordPress-Website
Ein vereinfachtes, fiktives Beispiel zur Veranschaulichung, keine Kundendaten, aber ein Muster, das in dieser Form häufig vorkommt: Eine Steuerkanzlei in Magdeburg, WordPress mit 28 Plugins, einfaches Webspace-Paket, kein Seiten-Cache, kein CDN, Server in einem Rechenzentrum in Deutschland.
| Schritt | Maßnahme | TTFB Startseite | Cache-Status |
|---|---|---|---|
| Ausgangslage | Keine | 1,4 s | Jeder Aufruf geht zur Datenbank |
| 1 | Neun ungenutzte Plugins entfernt, PHP auf aktuelle Version | 1,0 s | Unverändert, aber schneller berechnet |
| 2 | Seiten-Cache-Plugin aktiviert | 0,3 s | HIT ab dem zweiten Aufruf |
| 3 | CDN vorgeschaltet, Cache-Header für Dateien | 0,2 s | HTML und Dateien aus dem Edge |
| 4 | Weiterleitungskette http, www, Schrägstrich auf eine Weiterleitung reduziert | 0,15 s | Ein Roundtrip weniger |
Der Aufwand für ein solches Paket liegt in vielen Projekten bei wenigen Stunden bis einem Tag. Der Effekt auf den LCP kommt automatisch hinterher, weil das Hauptbild jetzt eine Sekunde früher angefordert wird.
Kosten und Aufwand realistisch
| Maßnahme | Aufwand | Wirkung auf TTFB | Wer macht das |
|---|---|---|---|
| Seiten-Cache aktivieren (Plugin oder Hosting-Funktion) | Unter einer Stunde | Sehr hoch | Agentur oder du selbst |
| CDN vorschalten | Ein bis zwei Stunden | Hoch bei Dateien, hoch bei HTML wenn erlaubt | Agentur, Hosting |
| Cache-Header setzen und prüfen | Ein bis drei Stunden | Mittel bis hoch | Entwickler |
| Plugins und Datenbank aufräumen, PHP aktualisieren | Ein halber Tag | Mittel | Agentur |
| Hosting-Wechsel zu Managed oder Plattform | Ein halber bis zwei Tage | Hoch, inklusive Cache und CDN | Agentur |
| Relaunch mit statischer Auslieferung | Neue Website | Sehr hoch, dauerhaft | Agentur |
Wenn eine Website so gebaut ist, dass sie trotz Cache-Plugin langsam bleibt, weil Theme und Plugins jede Anfrage aushebeln, ist der Relaunch oft die wirtschaftlichere Entscheidung. Bei uns beginnt eine Starter-Website bei 1.499 € netto und eine Hero-Website bei 3.900 € netto, beide statisch ausgeliefert und mit Caching und CDN von Anfang an.
Häufige Fehler
- Alles dynamisch rendern, obwohl sich die Inhalte einmal im Monat ändern.
- „CDN aktiviert“ mit „Caching funktioniert“ verwechseln. Ohne passende Header cacht das CDN nur Bilder, und jede Seite geht weiter zum Origin.
- Cache bei jeder Kleinigkeit komplett leeren. Danach ist jeder Aufruf ein Miss. Besser gezielt revalidieren.
- HTML und Dateien mit denselben Regeln behandeln. Dateien dürfen ein Jahr, HTML nur Minuten bis Stunden.
- Personalisierte Seiten aus Versehen cachen. Ein Sicherheitsproblem, kein Performance-Gewinn.
- Mit Bildern anfangen, obwohl der TTFB bei 1,5 Sekunden liegt. Erst der Server, dann die Bilder.
- Server auf einem anderen Kontinent, weil das Angebot günstig war.
- Nur einmal messen. Erster Aufruf und zweiter Aufruf erzählen zwei verschiedene Geschichten.
- Nie in die Header schauen. Der Cache-Status steht in jeder Antwort, man muss ihn nur lesen.
60-Minuten-Plan für einen messbar besseren TTFB
- Drei Seiten auswählen: Startseite, wichtigste Leistungs- oder Produktseite, Kontaktseite.
- Vorher messen: Jede Seite zweimal in PageSpeed Insights und im Netzwerk-Tab, TTFB und Cache-Status notieren.
- Seiten-Cache prüfen oder aktivieren: Plugin, Hosting-Funktion oder statische Generierung. Zweiten Aufruf erneut messen.
- Dateien prüfen: Haben CSS, JavaScript und Bilder lange Cache-Zeiten? Antwort-Header ansehen.
- CDN prüfen: Ist eines vorgeschaltet, und cacht es auch HTML? Falls nicht, Regeln anpassen.
- Weiterleitungen prüfen: Wie viele Sprünge von http://deinedomain.de bis zur endgültigen Seite? Auf einen reduzieren.
- Nachher messen und die Werte neben die alten legen. Erst dann weiter zu Bildern und Skripten.
Wer die Werte dauerhaft im Blick behalten will, statt sie einmal im Jahr zu prüfen, findet im Artikel zu Monitoring für SEO und Websites eine Anleitung.
Nächster Schritt
Wenn du selbst loslegen willst: Miss den TTFB deiner drei wichtigsten Seiten, aktiviere den Seiten-Cache, prüfe die Header und die Weiterleitungen, und miss noch einmal. In vielen Projekten liegt zwischen vorher und nachher mehr als eine halbe Sekunde, und die spürt jeder Besucher bei jedem Klick.
Wenn du lieber wissen willst, ob dein Hosting und deine Cache-Konfiguration zu deiner Website passen oder ob ein Wechsel oder Relaunch die bessere Investition ist: Unser kostenloser Website-Check zeigt dir TTFB, Cache-Status und die Maßnahmen mit Aufwand. Wir bauen Websites und Software aus Magdeburg so, dass Caching und Auslieferung von Anfang an mitgedacht sind, statt hinterher nachgerüstet zu werden.
