# Page-Size-Monitoring & Defacement-Schutz | Uptimeify > Ein 200 OK heißt nicht gesund: überwache die HTML-Größe pro Endpunkt und erkenne leere Renderings, Code-Wucher und Defacement. Source: https://uptimeify.io/de/monitoring/website-monitoring/page-size-check Ein Statuscode sagt nur, dass der Server geantwortet hat, nicht, dass die richtige Seite ausgeliefert wurde. Überwache die HTML-Payload-Größe pro Endpunkt und fang partielle Renderings, injizierten Code und aufgeblähte Releases ab, bevor dein Kunde die Regression sieht. Jetzt kostenlos testen HTML-Payload kostenlos messen ## Page-Size-Monitoring. 200 OK ist kein Gesundheitszeugnis. Für den technischen Ansprechpartner ### Byte-Messung & Baseline-Logik: So ist es verdrahtet So ist es verdrahtet. Zur Page Size Check Dokumentation https://docs.uptimeify.io/de/monitoring/monitoring-types/page-size Quelle roher HTML-Body bei jedem Check in Bytes gemessen. Metrik Die Content-Größe wird pro Run erfasst, unabhängig vom Status-Code der Antwort. Baseline Pro Endpunkt wird ein erwarteter Byte-Korridor zum Vergleich etabliert. Scope Misst das HTML-Dokument, das der Server zurückgibt, bevor clientseitige Assets laden. Payload Layer ## Die Byte-Größe nicht. Der Statuscode lügt. Eine Seite kann sauber mit 200 antworten und trotzdem kaputt sein: halb gerendert, mit fehlendem Content-Block oder stillem Backend-Fehler. Page Size Check misst, was wirklich rausgeht: die tatsächliche Größe des Response-Bodys. Damit bekommst du ein strukturelles Signal dafür, ob das ausgelieferte HTML noch der Seite entspricht, die dein Kunde erwartet. - **HTML-Payload in Bytes**, damit du dich nicht länger auf den Statuscode als einziges Health-Signal verlässt, sondern auf die Substanz der Antwort schaust. - **Strukturelle Drift-Erkennung**, damit du fehlende Content-Blocks, kaputte Templates und stille Fehler bemerkst, bevor sie zum Ticket werden. - **Baseline pro Endpunkt**, damit jede kritische Seite im Kundenportfolio ihren eigenen erwarteten Byte-Korridor hat, statt einer pauschalen Faustregel. Für den technischen Ansprechpartner ### Threshold-Auswertung & Run-Logik: So ist es verdrahtet So ist es verdrahtet. Zur Page Size Check Dokumentation https://docs.uptimeify.io/de/monitoring/monitoring-types/page-size Min zu klein leere States, partielle Renderings, Template-Fehler. Max zu groß Code Bloat, injizierte Snippets, ausufernde Embeds. Korridor Der Monitor schlägt nur fehl, wenn die Payload deinen gewählten Byte-Bereich verlässt. Auswertung Jeder Run wird live gegen den Korridor geprüft, kein historischer Graph nötig. Threshold Layer ## Ein Korridor, zwei Wächter. Min und Max. Zu klein und zu groß sind verschiedene Defekte. Du setzt für kritische Landingpages, Logins oder Checkout-Routen klare Unter- und Obergrenzen. Uptimeify prüft jeden Run gegen diesen Korridor und markiert Anomalien sofort, ohne dafür historische Graph-Daten zu speichern. - **Min-Threshold**, damit du leere States, partielle Renderings und Template-Fehler erkennst, sobald eine Seite plötzlich unter ihre normale Größe rutscht. - **Max-Threshold**, damit dir abnormes Payload-Wachstum durch unoptimierte Assets, injizierte Snippets oder ausufernde Embeds nicht entgeht. - **Limit-Korridor**, damit der Monitor nur dann auslöst, wenn die Payload wirklich außerhalb deiner Grenzen liegt, statt bei jeder harmlosen Schwankung. Für den technischen Ansprechpartner ### Größen-Spitzen & Integritätssignal: So ist es verdrahtet So ist es verdrahtet. Zur Page Size Check Dokumentation https://docs.uptimeify.io/de/monitoring/monitoring-types/page-size Defacement Plötzliche Payload-Spitzen gehen oft mit injizierter Malware oder unautorisierten Skripten einher. Leeres Rendering Ein Abfall unter die normale Größe markiert nicht gerenderte Content-Blocks. Performance Bloat, der Core Web Vitals und Crawl-Effizienz schaden würde, wird früh erkannt. Signal Eine Größen-Anomalie öffnet einen Incident, bevor sie kundenseitig sichtbar wird. Integrity Layer ## Beides fängst du an der Größe ab. Defacement und Bloat. Page Size Check schützt Integrität und Performance zugleich. Du erkennst Defacements, gebrochene Rendering-Pfade und aufgeblähte Releases an ihrer Byte-Signatur, bevor daraus ein sichtbarer Incident wird, den dein Kunde zuerst meldet. - **Defacement-Schutz**, damit du verdächtige Payload-Spitzen erfasst, die oft mit Malware, Spam-Links oder unautorisierten Skripten einhergehen. - **Schutz vor leeren Renderings**, damit du Seiten erkennst, die unter ihre Normalgröße fallen, weil Content-Blocks fehlen, obwohl der Server erfolgreich antwortet. - **Performance-Limit**, damit versehentlicher Code Bloat nicht still deine Core Web Vitals, Crawl-Effizienz und User Experience beschädigt. ### SLA- & Vertrags-Vorlagen Service Level Agreement Vorlagen, um professionelle Grenzen mit deinen Kunden zu definieren. ### Preisrechner Finde den Sweet Spot für deine Wartungspläne. Berechne Margen basierend auf Prüffrequenz und Support-Aufwand. ### White-Label Pitch Decks Präsentationen, die nicht-technischen Kunden 24/7-Monitoring erklären. Schließe mehr Wartungsverträge ab. ### Churn-Proof Reporting Guide Nutze automatisierte Berichte, um proaktiv Wert zu kommunizieren, damit Kunden nie fragen, wofür sie bezahlen. Sichere dir dein Success Kit und starte noch heute mit der Skalierung. Success Kit sichern & Monitoring starten Bereit, Monitoring in ein Profit-Center zu verwandeln? Jedes Uptimeify-Abonnement enthält Zugang zu unserem Success Kit, eine Sammlung erprobter Ressourcen, um dein Monitoring profitabel zu machen. ## Wir überwachen nicht nur. Wir helfen dir beim Verkaufen. → Für den technischen Ansprechpartner ### Byte-Messung & Threshold-Logik: So ist es verdrahtet Verwendet wird der `Content-Length`-Header der Antwort, sofern vorhanden; fehlt er (etwa bei chunked Transfer oder dynamischem Rendering), zählen wir ersatzweise die tatsächlich empfangenen Body-Bytes. Der Wert wird gegen ein pro Endpunkt definiertes Min/Max-Intervall geprüft: darunter „zu klein", darüber „zu groß", dazwischen gültig. Der Size-Check ist über `checkSizeEnabled` einzeln schaltbar und läuft als Teil der kombinierten Prüfung neben Status, SSL und Response-Time. Ein Korridor-Verstoß kippt den Status unabhängig vom HTTP-Code. Was misst Page Size Check genau? Die tatsächliche Größe des HTTP-Response-Bodys in Bytes, also wie viel HTML deine Seite pro Aufruf wirklich ausliefert. Damit hast du ein strukturelles Integritätssignal jenseits des Statuscodes: Eine Seite kann 200 OK melden und trotzdem halb gerendert oder aufgebläht sein, und genau das macht die Byte-Messung sichtbar. Warum reicht ein 200-Statuscode nicht als Health-Signal? Ein 200 bestätigt nur, dass der Server geantwortet hat, nicht, dass die richtige Seite ankam. Fehlt ein Content-Block, bricht ein Template ab oder injiziert jemand fremden Code, bleibt der Statuscode oft trotzdem grün. Die Payload-Größe verschiebt sich in all diesen Fällen, deshalb fängst du strukturelle Defekte über die Bytes ab, die der Statuscode durchwinkt. Wie setzt du Min- und Max-Grenzen für eine Seite? Du legst pro Endpunkt einen Byte-Korridor mit Unter- und Obergrenze fest. Die Untergrenze fängt leere States und partielle Renderings ab, die Obergrenze abnormes Wachstum durch Bloat oder Injections. Jeder Run wird gegen diesen Korridor geprüft. Der Monitor schlägt nur an, wenn die Größe außerhalb deiner definierten Grenzen liegt, damit du keine Fehlalarme bei harmlosen Schwankungen bekommst. Hilft Page Size Check gegen Defacement und injizierten Code? Ja. Unautorisierte Skripte, Spam-Links oder fremde Embeds vergrößern die Payload messbar, oft bevor die Manipulation optisch auffällt. Eine Größen-Spitze über deine Obergrenze löst sofort aus, damit erkennst du eine Kompromittierung am Byte-Signal, statt erst, wenn ein Kunde die verunstaltete Seite meldet. Speichert Uptimeify dafür historische Größen-Verläufe? Nein. Die Prüfung ist zustandslos: Jeder Run wird gegen deinen festen Byte-Korridor geprüft, nicht gegen einen gleitenden historischen Graphen. Du brauchst keine Größen-Zeitreihen vorzuhalten, der Korridor allein liefert das Ergebnis „im Limit\" oder „außerhalb\". FAQ ## Häufig gestellte Fragen Setz pro kritischer Seite einen Byte-Korridor und lass Uptimeify jeden Run gegen deine Grenzen prüfen. Leere Renderings, Bloat und Defacements meldest du, bevor sie zum Incident werden, unter deiner Marke. ## Bereit, defekte Releases vor deinem Kunden zu sehen?