Pesée des ressources lourdes

Google a documenté qu'il n'analyse pas les ressources individuelles dépassant 15 MB (HTTP 416 explicite côté Googlebot). En pratique, dès 2-5 MB, le crawl budget en prend un coup et la latence first-paint s'effondre. La majorité des leaders SEO utilisent 2 MB comme seuil de pré-alerte. Les vidéos sont une exception (elles sont rarement crawlées de toute façon) mais une image de 2 MB sur la home, c'est 99% du temps une image PNG/JPEG mal compressée.

Images non optimisées en premier — PNG là où WebP/AVIF feraient 5-10× moins, photos exportées en haute définition pour rien. Bundles JS monolithiques en deuxième — les SPA non code-splittées peuvent envoyer 5-10 MB de JS pour rien. Polices auto-hostées non sous-settées en troisième — un fichier .woff2 complet pèse 200-500 KB, mais sous-setté (juste les glyphes utilisés), 20-50 KB.

Pour les images : conversion WebP/AVIF avec un outil comme Squoosh ou un build pipeline (Astro/Next/Vite ont des plugins automatiques). Pour le JS : code-splitting par route + tree-shaking strict + inspection des dépendances avec Bundlephobia. Pour les fonts : Subset (ne charger que les caractères latins étendus) + woff2 + font-display: swap. Et toujours : compression Brotli côté serveur (10-30% de gain gratuit vs gzip).

On scanne jusqu'à 40 ressources de la page (limite des sous-requêtes Cloudflare Workers). On fait des requêtes HEAD en parallèle pour récupérer le Content-Length. Certains CDNs refusent le HEAD ; dans ce cas on fait un GET avec Range: bytes=0-0. Ressources sans Content-Length ni Content-Range apparaissent comme "taille inconnue".