Schwere-Ressourcen-Wieger

Google hat dokumentiert, dass es einzelne Ressourcen über 15 MB nicht analysiert (expliziter HTTP 416 von Googlebot). In der Praxis leidet bereits ab 2 bis 5 MB das Crawl-Budget, und die First-Paint-Latenz bricht ein. Die meisten SEO-Leader nutzen 2 MB als Vorab-Warnschwelle. Videos sind eine Ausnahme (sie werden ohnehin selten gecrawlt), aber ein 2-MB-Bild auf der Startseite ist in 99% der Fälle ein schlecht komprimiertes PNG/JPEG.

Unoptimierte Bilder zuerst, PNG, wo WebP/AVIF 5- bis 10-mal kleiner wären, Fotos ohne Grund in hoher Auflösung exportiert. Monolithische JS-Bundles als zweites, SPAs ohne Code-Splitting können 5-10 MB JS umsonst ausliefern. Selbst gehostete, nicht subsettete Fonts als drittes, eine vollständige .woff2-Datei wiegt 200-500 KB, subsettet (nur genutzte Glyphen) 20-50 KB.

Für Bilder: WebP/AVIF-Konversion mit einem Tool wie Squoosh oder einer Build-Pipeline (Astro/Next/Vite haben automatische Plugins). Für JS: Code-Splitting pro Route plus striktes Tree-Shaking plus Dependency-Inspektion mit Bundlephobia. Für Fonts: Subsetting (nur Latin Extended laden), woff2, plus font-display: swap. Und immer: Brotli-Kompression serverseitig (10-30% kostenlos vs gzip).

Wir scannen bis zu 40 Ressourcen pro Seite (Cloudflare-Workers-Subrequest-Limit). Wir machen HEAD-Requests parallel, um Content-Length zu lesen. Manche CDNs verweigern HEAD, dann machen wir ein GET mit Range: bytes=0-0. Ressourcen ohne Content-Length noch Content-Range erscheinen als "unbekannte Größe".