Page Size Checker

Füge jede beliebige URL in das Page URL-Feld oben ein und treffe überprüfen. Der Page-Size-Checker ruft die URL ab, liest die Response-Header und gibt die rohe HTML-Dokumentgröße, die gzip- oder brotli-Drahtgröße, Antwortzeit in Millisekunden, die Content-Encoding- und Cache-Control-Werte und eine Anzahl jedes extern deklarierten CSS-, JS-, Image-, Font- und iframe zurück. Es schätzt das Gesamtseitengröße mit Web Almanac 2024-Medianen (2,4 MB Median, 5 MB bei p75) und kennzeichnet, ob du schlank, durchschnittlich oder aufgeblasen sitzt. Chrome DevTools zeigt die gleichen Zahlen im Network-Tab, aber du musst die Seite laden, Cache löschen, hart neu laden und über mehrere Panels lesen. Dieses Tool gibt die gleiche Antwort in zwei Sekunden gegen jede öffentliche URL.

Die Seitengröße ist die Summe jedes Bytes, das der Browser herunterlädt, um die Seite zu rendern: das HTML-Dokument plus jede CSS-Datei, JS-Datei, Bild, Font, Video und iframe-Asset. Die nützlichste Nummer ist die komprimierte Drahtgröße, da das über das Netzwerk geht. Um manuell zu berechnen, öffne Chrome DevTools, wechsel zu Network, hart neu laden mit deaktiviertem Cache und lies die untere Leiste, wo Chrome Anfragen und Gesamtübertragene Bytes druckt. Der Checker oben macht die gleiche Arithmetik für das HTML-Dokument direkt und schätzt das Gesamtgewicht aus deklarierten Assets mit Web Almanac 2024-Medianen, sodass du nicht warten musst, bis jede Sub-Ressource fertig ist.

Verwende das Feld oben. Gib die URL in Page URL ein, treffe überprüfen und lies die Antwort-Karte. Der Checker zeigt HTML-Doc-Bytes, gzip-Draht-Bytes, Antwortzeit, Encoding, Cache-Header und das Asset-Anfrage-Inventar nach Typ. Er benchmarkt das geschätzte Gesamtgewicht gegen Web Almanac 2024-Mediane und kennzeichnet die Seite grün, bernstein oder rot. Für ein tiefergehendes Render-Audit führe den google-crawler-simulator aus, der JavaScript ausführt und das Post-Render DOM zeigt, dann führe dann den alt-text-checker auf dem Bild-Inventar aus. Die Kombination sagt dir genau, welche Assets zuerst komprimieren, aufschieben oder entfernen sollst.

Strebe ein Gesamtgewicht unter 1,5 MB auf Landing- und Conversion-Seiten an. Der Web Almanac 2024 maß die durchschnittliche Seite auf 2,4 MB und die p75 auf 5 MB, mit der p90 über 9 MB. Seiten unter 1 MB bestehen die 2,5-Sekunden-LCP-Schwelle 82 % der Zeit auf 4G-Mobilgerät. Seiten über 3 MB bestehen sie nur 38 % der Zeit. Halte HTML unter 100 KB komprimiert, JS unter 300 KB komprimiert, CSS unter 60 KB komprimiert und das größte einzelne Bild unter 200 KB. Der Checker kennzeichnet Seiten, die diese Schwellwerte überschreiten. Überprüfe nach jedem Deploy erneut, da Third-Party-Scripts und CMS-Plugins routinemäßig Gewicht hinzufügen, ohne dass es jemand bemerkt.

LCP misst, wie lange das größte sichtbare Element zum Rendern braucht. Auf den meisten Seiten ist dieses Element ein Hero-Bild, ein Banner-Video-Frame oder ein großer Headline-Block. Schwere Seiten verzögern LCP, weil Render-Blocking CSS und JS in dem Head den Paint später schieben, das LCP-Bild selbst oft unoptimiert ist und Netzwerk-Stau die LCP-Anfrage von Bandbreite verhungert. Googles Schwellwert liegt bei 2,5 Sekunden. Die 2024 HTTP Archive-Daten zeigen, dass Seiten über 3 MB es 62 % der Zeit auf dem Mobilgerät verfehlen. Repariere LCP durch Vorladen des Hero-Bildes, Bereitstellen als AVIF oder WebP, Aufschieben von unkritischem JS mit defer oder async und Trimmen von kritischem CSS. Führe den Checker nach jeder Änderung erneut aus.

Beide sind Text-Kompressionsalgorithmen, die auf der HTTP-Ebene angewendet werden. Gzip ist der Web-Standard seit den 1990er Jahren und wird von jedem Browser unterstützt. Brotli wurde 2015 von Google veröffentlicht und wird ab 2026 in 96 % der Browser versendet. Brotli komprimiert Text durchschnittlich 15-25 % kleiner als gzip für HTML, CSS und JS, mit der Lücke am breitesten bei hochrepetitivem Markup. Die meisten CDNs (Cloudflare, Fastly, CloudFront) aktivieren brotli standardmäßig für statischen Text und fallen auf gzip für ältere Clients zurück. Der Checker zeigt das tatsächliche Content-Encoding, das dein Server zurückgab. Wenn es gzip oder leer anzeigt, wechsle dein CDN zu brotli für einen sofortigen 15-25 % Drop in Text-Gewicht ohne Code-Änderung.

Befasse dich zuerst mit den schwersten Kategorien. Bilder sind normalerweise der größte Posten: Konvertiere Hero-Fotos zu AVIF mit WebP-Fallback (AVIF ist durchschnittlich 50 % kleiner als JPEG in der gleichen Qualität), Größe zu tatsächlichen Display-Dimensionen und Lazy-Load alles unter dem Falz mit loading="lazy". JavaScript kommt als nächstes: Code-Split nach Route, Aufschieben von Third-Party-Scripts bis nach First Paint und Entfernen ungenutzter Abhängigkeiten. CSS: Bereinige ungenutzte Selektoren mit PurgeCSS oder Tailwinds JIT, Inline kritisches CSS in dem Head und lade den Rest asynchron. Fonts: Subset zu den Glyphen, die du verwendest und Self-Host mit font-display: swap. Ein typisches Bloat-Audit reduziert das Gesamtgewicht 40-60 % im ersten Pass.

Ja, schwer. Auf einer schnellen 4G-Verbindung (12 Mbps) dauert das Herunterladen einer 5-MB-Seite etwa 3,5 Sekunden, bevor das Rendering beginnt. Auf einer langsamen 3G-Verbindung (1,6 Mbps) dauert die gleiche Seite 25 Sekunden. Google's Lighthouse simuliert genau ein "Slow 4G"-Profil, weil echte mobile Netzwerke langsamer sind als Carrier-Marketing suggeriert. Der 2024 Web Almanac fand heraus, dass 53 % der Mobilbenutzer Seiten aufgeben, die länger als 3 Sekunden zum Laden brauchen. Schwere Seiten drainieren auch gemessene Datenpläne bei einem einzelnen Besuch. Strebe unter 1 MB auf Mobile-First-Templates an und verbinde den Checker mit dem google-crawler-simulator, um zu bestätigen, dass der Mobile-Bot die gleiche schlanke Payload sieht.

Verwende AVIF als primäres Format mit WebP-Fallback für die 4 % der Browser, die AVIF nicht unterstützen. AVIF komprimiert Fotos 50 % kleiner als JPEG bei gleichwertiger visueller Qualität und 20-30 % kleiner als WebP. Für einen 400-KB-Hero JPEG wiegt die AVIF-Version normalerweise 90-130 KB. Verwende das <picture>-Element mit <source type="image/avif"> und <source type="image/webp"> dann einen JPEG-<img>-Fallback. Für Icons und einfache Grafiken verwende SVG: Es skaliert unendlich, wiegt unter 5 KB für die meisten Icons und komprimiert gut mit brotli. Vermeide PNG außer für Screenshots, die verlustfreie Transparenz brauchen. Ersetze GIF mit einem stummen Autoplay-MP4 oder WebM, das 90 % weniger wiegt.

Ja. Eine vollständige Font-Gewicht von Google Fonts oder Adobe Fonts wiegt oft 80-120 KB, weil es jeden lateinischen, kyrillischen, griechischen und vietnamesischen Glyphen plus den vollständigen Satzzeichen-Satz enthält. Die meisten Seiten verwenden nur Lateinisch Basic. Subsetting fällt die Datei auf 18-25 KB, eine 75-85 % Einsparung pro Font. Tools wie glyphhanger oder Fontsource handhaben Subsetting automatisch. Self-Host die Subsetted-Datei mit font-display: swap, sodass Text sofort in einem Fallback-Font rendert und neu angestrichen wird, wenn der benutzerdefinierte Font lädt. Begrenzen Sie Gesamtgewichte auf zwei oder drei (ein Body, ein Heading, optional ein Display). Jedes zusätzliche Gewicht ist ein weiteres 18-25 KB plus eine Render-Blocking-Anfrage, es sei denn, es ist vorgeladen.

Führe ein CSS-Purge-Tool gegen deinen Production-Build aus. PurgeCSS scannt HTML- und JS-Templates auf Klassennamen und löscht jeden Selector in deinem CSS, der nie referenziert wird. Tailwinds JIT-Compiler tut das automatisch. Für handgeschriebenes CSS führen Frameworks wie Next.js, Astro und SvelteKit einen Purge-Schritt zur Build-Zeit durch. Die Einsparungen sind normalerweise dramatisch: Eine Bootstrap-Seite, die das vollständige 200-KB-Framework versendet, kann nach dem Bereinigen auf 8-15 KB fallen. Inline kritisches CSS für Inhalt über dem Falz in dem Head (normalerweise 10-15 KB) und lade den Rest mit <link rel="stylesheet" media="print" onload="this.media='all'">. Überprüfe mit dem Size Checker erneut, dann führe dann den h1-checker aus, um zu bestätigen, dass das schlankere HTML immer noch eine gültige Heading-Struktur hat.

Lazy Loading schiebt das Herunterladen von Off-Screen-Assets auf, bis der Benutzer ihnen nahe scrollt. Das native HTML-Attribut loading="lazy" funktioniert auf <img> und <iframe> in 95 % der Browser und erfordert null JavaScript. Auf einer langen Artikel-Seite mit 30 Bildern schiebt Lazy Loading normalerweise 25 davon auf, reduziert die Initial-Payload um 60-80 % und fällt LCP um 1-2 Sekunden. Wende es auf jedes Bild und iframe unter dem Falz an, aber niemals auf das LCP-Bild selbst, da Lazy Loading des Heroes die Metrik verzögert, die du zu verbessern versuchst. Kombiniere mit Bildformat-Konvertierung (AVIF oder WebP) für zusammengesetzte Gewinne. Der Checker kennzeichnet Seiten mit hohen Bilderanzahlen; wenn du 40+ Bilder auf einer einzelnen Seite siehst, ist Lazy Loading dein größter verfügbarer Gewinn.

HTML-Doc-Größe ist die Bytes der HTML-Antwort selbst: Das Markup, das der Server vor dem Browser-Abrufen sub-Ressourcen zurückgab. Gesamtseitengröße ist die Summe des HTML-Docs plus jede CSS-Datei, JS-Datei, Bild, Font, Video und iframe, das die Seite lädt. Eine Seite kann ein 8-KB-HTML-Dokument und 6-MB-Gesamtgewicht haben, wenn es schwere Bilder und Scripts lädt. Oder es kann ein 250-KB-HTML-Dokument voll Inline-Inhalt und 400-KB-Gesamtgewicht haben. Der Checker zeigt HTML-Doc-Größe direkt von der Antwort und schätzt Gesamtgewicht von der deklarierten Asset-Anzahl mit Web Almanac 2024-Medianen. Die HTML-Doc-Nummer ist am wichtigsten für Crawl-Budget; Gesamtgewicht ist am wichtigsten für LCP.

Cache-Control-Header sagen dem Browser, wie lange ein Asset behalten wird, bevor er es erneut anfordert. Ein Header von cache-control: public, max-age=31536000, immutable sagt dem Browser, die Datei ein Jahr lang zu behalten und niemals revalidieren. Wiederholte Besucher laden null Bytes für dieses Asset. Der Checker zeigt den Cache-Control-Wert auf der HTML-Antwort, damit du deine CDN-Konfiguration verifizieren kannst. HTML selbst sollte normalerweise kurz gecacht werden (300-600 Sekunden), da der Inhalt sich häufig aktualisiert. Statische Assets (JS, CSS, Fonts, Bilder) mit gehashten Dateinamen sollten ein Jahr gecacht werden, da eine Inhaltsänderung einen neuen Dateinamen erstellt. Ohne richtiges Caching ist jeder Seitenladevorgang eine Cold Load.

Content-Encoding ist der HTTP-Response-Header, der dem Browser sagt, wie der Body komprimiert wurde. Häufige Werte sind gzip, br (brotli), deflate, zstd oder leer (unkomprimiert). Der Checker zeigt, was dein Server zurückgab. Wenn es gzip auf einer Text-Antwort anzeigt, sparst du 70-80 % Bandbreite gegenüber unkomprimiert. Wenn es br anzeigt, sparst du zusätzliche 15-25 % oben auf gzip. Wenn es leer auf einer HTML-, CSS- oder JS-Antwort über 5 KB ist, ist dein Server oder CDN falsch konfiguriert und jeder Besucher zahlt das volle unkomprimierte Gewicht. Binärformate (JPEG, PNG, WebP, AVIF, MP4) sind bereits auf der Formatebene komprimiert und geben normalerweise leere Content-Encoding zurück.