// audit · hosting
Deine Seite ist langsam, bevor sie überhaupt anfängt zu laden? Dann liegt es selten am Bild, sondern an der Umgebung darunter. Die Hosting-Analyse von siteway prüft TTFB, Caching, CDN, Serverstandort und Uptime — und liefert einen Report, der sagt, was zuerst zu tun ist.
// definition
Ein Hosting- & Infrastruktur-Audit ist die Prüfung der Server-Umgebung unter deiner Website: TTFB, Caching, CDN, Serverstandort, Protokolle, Ressourcen und Uptime. Es misst nicht, wie schnell dein Frontend rendert, sondern wie schnell und zuverlässig überhaupt geantwortet wird.
Der Unterschied zu einem kostenlosen Speed-Test: Ein Tool zeigt dir eine Zahl. Wir sagen dir, woher die Zahl kommt, welcher der vier Werte die anderen blockiert und in welcher Reihenfolge du das abarbeitest. Heraus kommt ein infra-report — priorisierte Befunde mit Aufwand und Wirkung. Was du damit machst, entscheidest du.
// anlass
erst messen, dann kaufen
Der teuerste Weg zu einer schnellen Website ist Raten. Ein neuer Tarif, ein Caching-Plugin, ein CDN obendrauf — und danach ist die Seite so langsam wie vorher, nur die Rechnung ist höher. Das Audit dreht die Reihenfolge um: erst die Ursache benennen, dann Geld ausgeben.
Typischer Anlass ist ein Verdacht, den niemand belegen kann. PageSpeed Insights meldet „Serverantwortzeit reduzieren", der Hoster sagt „bei uns ist alles grün", die Agentur zeigt auf den Hoster. Genau in dieser Situation liefert das Audit die Zahlen, mit denen sich die Diskussion beenden lässt. Für einen ersten eigenen Eindruck gibt es unseren kostenlosen PageSpeed-Check.
// prüfung · 6 felder
jedes feld ein befund
Sechs Felder, in denen sich Antwortzeit und Verfügbarkeit entscheiden. Wir messen jedes einzeln, damit am Ende klar ist, welcher Teil der Kette bremst — und welcher zu Unrecht verdächtigt wurde.
// p-01ttfb
Time to First Byte je Seitentyp und Region — und zerlegt in seine Teile: DNS, TLS-Handshake, Redirects, reine Rechenzeit des Servers. Erst die Aufschlüsselung zeigt, ob die Datenbank bremst oder das Netz.
befund: ttfb-aufschlüsselung
// p-02caching
Page-Cache, Objekt-Cache, OPcache, Cache-Control-Header. Häufigster Befund: Ein Cache ist installiert, greift aber nicht — weil Cookies, Query-Parameter oder ein Session-Start jede Seite an ihm vorbeischicken.
befund: cache trifft / trifft nicht
// p-03cdn
Läuft ein CDN, und wenn ja: Welcher Anteil wird am Edge beantwortet und welcher geht doch zum Origin durch? Ein CDN, das nur Bilder ausliefert und HTML durchreicht, kostet Geld und spart kaum Zeit.
befund: hit-rate + lücken
// p-04standort
Wo steht der Server wirklich, wie weit ist er von deiner Zielgruppe entfernt, was kostet die Distanz? Wir messen aus mehreren Regionen — bei mehrsprachigen Seiten ist das oft der größte einzelne Posten.
befund: latenz je region
// p-05protokoll
HTTP/2 oder HTTP/3, TLS-Version, Kompression, HSTS — und Redirect-Ketten, die jede Anfrage zweimal laufen lassen. Kleine Konfigurationsposten, die zusammen leicht ein paar hundert Millisekunden ausmachen.
befund: header + redirect-kette
// p-06uptime
PHP-Version, Speicher- und Prozess-Limits, Datenbank-Umgebung, Ausfälle der letzten Monate. Dazu die unbequeme Frage: Merkt überhaupt jemand, wenn die Seite steht — oder ruft der erste Kunde an?
befund: limits + ausfall-historie
// mehrwert
ttfb-schwelle: 0,8 s
Wer „TTFB messen" sucht, findet Dutzende kostenlose Tools. Sie liefern alle dieselbe Sache: eine Zahl, manchmal mit Ampelfarbe. Google zieht die Grenze bei 0,8 Sekunden — darunter gilt der TTFB als gut, ab 1,8 Sekunden als schlecht (web.dev). Nur: Aus „1,4 s" folgt keine einzige Handlung.
Der Wert ist eine Summe aus DNS, Verbindungsaufbau, TLS, Weiterleitungen und der Zeit, die dein Server rechnet. Solange du nicht weißt, welcher Posten wie groß ist, optimierst du blind. Deshalb zerlegen wir den TTFB, statt ihn nur zu melden — und sortieren die Befunde danach, was am meisten bringt und am wenigsten kostet.
In der Praxis stehen die billigen Posten oft oben: Page-Cache aktivieren, Redirect-Kette auflösen, PHP-Version anheben. Der Hoster-Wechsel — die Maßnahme, mit der die meisten anfangen — steht bei uns selten auf Platz 1 und manchmal gar nicht auf der Liste.
// output
der report gehört dir
Ein Dokument, das eine fremde Technik-Abteilung ohne Rückfragen abarbeiten kann. Kein Screenshot-Album, keine Ampel ohne Erklärung — sondern Befund, Ursache, Maßnahme, Aufwand, erwartete Wirkung. Dazu ein Gespräch, in dem wir den Report durchgehen.
// r-01befunde
Jeder Befund mit Messwert, Ursache und Maßnahme — sortiert nach Wirkung, nicht nach Reihenfolge der Prüfung. Oben steht, was du morgen anfassen solltest.
liste, nach wirkung sortiert
// r-02bewertung
Zu jeder Maßnahme eine ehrliche Schätzung: Was kostet sie an Zeit, was bringt sie an Millisekunden. Wo wir es nicht seriös schätzen können, steht das da — statt einer erfundenen Prozentzahl.
schätzung je maßnahme
// r-03nächste schritte
Konkrete To-dos mit Adressat: Was der Hoster tun muss, was ins CMS gehört, was Entwicklungsarbeit ist. Formuliert so, dass du den Punkt einfach weiterleiten kannst.
to-dos je adressat
// ablauf · 4 schritte
3–5 werktage bis zum report
// schritt 01 · briefing
Welche Seitentypen, welche Zielregionen, welche Umgebungen. Wenn vorhanden: Zugänge zu Hosting-Panel und Logs, dazu der Hosting-Vertrag. Danach steht der Festpreis.
output: scope + festpreis
// schritt 02 · messung
TTFB aus mehreren Regionen, über mehrere Tageszeiten, mit warmem und kaltem Cache. Dazu Header, Redirects, Protokolle, CDN-Verhalten und die Uptime-Historie.
output: rohdaten
// schritt 03 · auswertung
Jeder auffällige Wert bekommt eine Ursache — Konfiguration, Anwendung, Tarif oder Distanz. Ohne diesen Schritt bleibt jede Empfehlung geraten.
output: befund-liste
// schritt 04 · übergabe ● ergebnis
Der infra-report kommt als Dokument, priorisiert und mit Adressat je To-do. Wir gehen ihn in einem Termin mit dir durch — und beantworten die Frage, ob sich der nächste Schritt lohnt.
output: infra-report
// faq
Ein Hosting- & Infrastruktur-Audit ist eine Hosting-Analyse der Server-Umgebung unter einer Website. Geprüft werden TTFB und Server-Antwortzeit, Caching-Schichten, CDN, Serverstandort, HTTP- und TLS-Konfiguration, Ressourcen und Uptime. Ergebnis ist kein Messwert, sondern ein Report mit priorisierten Befunden: was die Antwortzeit bremst, in welcher Reihenfolge es zu beheben ist und was der jeweilige Schritt kostet.
Das Page-Speed-Audit misst, was im Browser passiert: Core Web Vitals wie LCP unter 2,5 s, INP unter 200 ms und CLS unter 0,1, dazu Bundle-Größen. Das Hosting- & Infrastruktur-Audit schaut darunter — auf den Server, der das erste Byte liefert. Beide hängen zusammen: Ein hoher TTFB verschiebt jede Frontend-Metrik nach hinten. Wenn unklar ist, wo das Problem sitzt, fangen wir mit dem Infrastruktur-Audit an, weil es die Frage beantwortet, ob überhaupt am Frontend zu suchen ist.
Festpreis nach Briefing. Sobald klar ist, wie viele Seitentypen, Umgebungen und Standorte geprüft werden, nennen wir einen Preis und halten ihn fest. Keine Tagessätze, keine offene Rechnung am Ende.
Nein. Der infra-report gehört dir. Du kannst ihn deinem Hoster vorlegen, an deine interne IT geben oder von einer anderen Agentur abarbeiten lassen — er ist so geschrieben, dass eine fremde Technik-Abteilung damit arbeiten kann. Wenn du willst, übernimmt siteway die Umsetzung über Performance & Core Web Vitals oder den laufenden Betrieb. Das ist eine eigene Entscheidung nach dem Report.
Für den Grundteil nicht: TTFB, Redirects, HTTP- und TLS-Konfiguration, CDN-Header und Cache-Verhalten lassen sich von außen messen. Tiefer wird es mit Zugängen — Hosting-Panel, Logs, Datenbank-Metriken und der Hosting-Vertrag zeigen, ob Ressourcen knapp sind oder der Tarif zur Last passt. Ohne Zugänge liefern wir das Audit trotzdem, wir kennzeichnen dann, welche Befunde eine Annahme sind.
Nein. Wir schauen auf Tempo, Verfügbarkeit und Konfiguration der Umgebung, nicht auf Angriffsflächen. Ein Penetrationstest oder eine Schwachstellen-Analyse ist ein eigenes Format — dafür gibt es das Security-Audit. Überschneidungen wie HSTS oder veraltete TLS-Versionen fallen uns dabei auf und stehen im Report, ersetzen aber keine Sicherheitsprüfung.
Nur wenn die Zahlen es hergeben. siteway bekommt keine Provision von Hostern, und ein Umzug ist die teuerste aller Maßnahmen. In vielen Fällen liegt das Problem nicht am Anbieter, sondern an fehlendem Page-Cache, einer alten PHP-Version oder einer Redirect-Kette. Wenn der Tarif die Grenze ist, sagen wir das mit Messwerten — und nennen Alternativen, die zu deiner Anwendung passen.
// passt dazu
audits & umsetzung
// leistung · umsetzung
Wenn der Report steht und jemand ihn abarbeiten soll: Hier optimieren wir wirklich — bis LCP, INP und CLS im grünen Bereich sind.
weiterlesen →
// audit · speed
Die Etage darüber: Core Web Vitals und Bundle-Größe im Browser, gemessen mit Lighthouse. Zusammen ergibt das das ganze Bild.
weiterlesen →
// tool · kostenlos
Erster Eindruck in 30 Sekunden: URL rein, Werte raus. Sagt dir, ob es sich lohnt, genauer hinzuschauen — kostenlos.
zum tool →
// Wissen, woran es wirklich liegt?
Audit anfragen