Page Size Checker

Collez n'importe quelle URL dans le champ Page URL ci-dessus et cliquez sur vérifier. Le vérificateur de taille de page récupère l'URL, lit les en-têtes de réponse, et retourne la taille du document HTML brut, la taille câble gzip ou brotli, le temps de réponse en millisecondes, les valeurs Content-Encoding et Cache-Control, et un nombre de chaque CSS, JS, image, police et iframe externe déclaré. Il estime le poids total de page en utilisant les médianes du Web Almanac 2024 (2,4 MB médiane, 5 MB en p75) et signale si vous êtes léger, moyen, ou gonflé. Chrome DevTools montre les mêmes nombres dans l'onglet Network, mais vous devez charger la page, vider le cache, recharger en forçant, et lire à travers plusieurs panneaux. Cet outil donne la même réponse en deux secondes contre n'importe quelle URL publique.

La taille de page est la somme de chaque octet que le navigateur télécharge pour afficher la page : le document HTML plus chaque fichier CSS, fichier JS, image, police, vidéo, et actif iframe. Le nombre le plus utile est la taille câble compressée, puisque c'est ce qui traverse le réseau. Pour calculer manuellement, ouvrez Chrome DevTools, passez à Network, rechargez en forçant avec le cache désactivé, et lisez la barre du bas où Chrome imprime les requêtes et les octets totaux transférés. Le vérificateur ci-dessus fait la même arithmétique pour le doc HTML directement et estime le poids total à partir des actifs déclarés en utilisant les médianes du Web Almanac 2024, donc vous n'avez pas à attendre que chaque sous-ressource se termine.

Utilisez le champ ci-dessus. Déposez l'URL dans Page URL, cliquez sur vérifier, et lisez la carte de réponse. Le vérificateur rapporte les octets du doc HTML, les octets câble gzip, le temps de réponse, l'encodage, les en-têtes de cache, et l'inventaire des requêtes d'actifs par type. Il compare l'estimé total par rapport aux médianes du Web Almanac 2024 et marque la page en vert, orange, ou rouge. Pour un audit de rendu plus profond, lancez google-crawler-simulator qui exécute JavaScript et montre le DOM post-rendu, puis lancez alt-text-checker sur l'inventaire d'images. La combinaison vous dit exactement quels actifs compresser, différer, ou supprimer d'abord.

Visez un poids total inférieur à 1,5 MB sur les pages d'arrivée et de conversion. Le Web Almanac 2024 a mesuré la médiane de page à 2,4 MB et la p75 à 5 MB, avec la p90 au-dessus de 9 MB. Les pages sous 1 MB passent le seuil LCP de 2,5 secondes 82% du temps sur le mobile 4G. Les pages au-dessus de 3 MB le passent seulement 38% du temps. Dans le budget, gardez le HTML sous 100 KB compressé, JS sous 300 KB compressé, CSS sous 60 KB compressé, et la plus grande image unique sous 200 KB. Le vérificateur signale les pages qui dépassent ces seuils. Revérifiez après chaque déploiement car les scripts tiers et les plugins CMS ajoutent régulièrement du poids sans que personne ne le remarque.

LCP mesure combien de temps le plus grand élément visible prend pour être rendu. Sur la plupart des pages, cet élément est une image héros, une trame vidéo de bannière, ou un grand bloc de titre. Les pages lourdes retardent LCP car le CSS et JS bloquant le rendu dans l'en-tête repoussent la peinture plus tard, l'image LCP elle-même est souvent non optimisée, et la contention réseau prive la requête LCP de bande passante. Le seuil de Google est 2,5 secondes. Les données 2024 du HTTP Archive montrent que les pages au-dessus de 3 MB le manquent 62% du temps sur mobile. Corrigez LCP en préchargeant l'image héros, en la servant en AVIF ou WebP, en différant le JS non critique avec defer ou async, et en élaguant le CSS critique. Relancez le vérificateur après chaque changement.

Les deux sont des algorithmes de compression texte appliqués au niveau HTTP. Gzip est la norme web depuis les années 1990 et est prise en charge par chaque navigateur. Brotli a été publié par Google en 2015 et se livre dans 96% des navigateurs en 2026. Brotli compresse le texte 15-25% plus petit que gzip en moyenne pour HTML, CSS, et JS, avec l'écart le plus large sur le balisage hautement répétitif. La plupart des CDN (Cloudflare, Fastly, CloudFront) activent brotli par défaut pour le texte statique et retombent à gzip pour les clients plus anciens. Le vérificateur rapporte le Content-Encoding réel que votre serveur a retourné. S'il affiche gzip ou vide, passez votre CDN à brotli pour une baisse immédiate de 15-25% du poids texte sans changement de code.

Abordez d'abord les catégories les plus lourdes. Les images sont généralement le plus grand poste : convertissez les photos héros en AVIF avec recours WebP (AVIF fait en moyenne 50% plus petit que JPEG à la même qualité), redimensionnez aux dimensions d'affichage réelles, et chargez paresseusement tout ce qui est sous le pli avec loading="lazy". JavaScript vient ensuite : divisez le code par route, différez les scripts tiers jusqu'après la première peinture, et supprimez les dépendances inutilisées. CSS : purgez les sélecteurs inutilisés avec PurgeCSS ou Tailwind's JIT, incorporez le CSS critique dans l'en-tête, et chargez le reste en async. Polices : subensemblez aux glyphes que vous utilisez et auto-hébergez avec font-display: swap. Un audit de gonflage typique réduit le poids total de 40-60% à la première passe.

Oui, gravement. Sur une connexion 4G rapide (12 Mbps), une page de 5 MB prend environ 3,5 secondes à télécharger avant le début du rendu. Sur une connexion 3G lente (1,6 Mbps), la même page prend 25 secondes. Google Lighthouse simule un profil « Slow 4G » précisément parce que les réseaux mobiles du monde réel sont plus lents que ce que le marketing des opérateurs prétend. Le Web Almanac 2024 a trouvé que 53% des utilisateurs mobiles abandonnent les pages qui prennent plus de 3 secondes à charger. Les pages lourdes drainent aussi les forfaits de données mesurées sur une seule visite. Visez moins de 1 MB sur les modèles mobile-first et associez le vérificateur au google-crawler-simulator pour confirmer que le bot mobile voit la même charge utile légère.

Utilisez AVIF comme format primaire avec recours WebP pour les 4% des navigateurs qui manquent le support AVIF. AVIF compresse les photos 50% plus petit que JPEG à qualité visuelle équivalente et 20-30% plus petit que WebP. Pour un JPEG héros de 400 KB, la version AVIF pèse généralement 90-130 KB. Utilisez l'élément <picture> avec <source type="image/avif"> et <source type="image/webp"> puis un recours JPEG <img>. Pour les icônes et les graphiques simples, utilisez SVG : il met à l'échelle infiniment, pèse moins de 5 KB pour la plupart des icônes, et se compresse bien avec brotli. Évitez PNG sauf pour les captures d'écran qui ont besoin de transparence sans perte. Remplacez GIF par une MP4 ou WebM en sourdine en lecture automatique, qui pèse 90% moins.

Oui. Un poids complet de police depuis Google Fonts ou Adobe Fonts pèse souvent 80-120 KB car il inclut chaque glyphe Latin, Cyrillique, Grec, et Vietnamien plus l'ensemble complet de la ponctuation. La plupart des sites utilisent seulement Latin basique. Le subsetting réduit le fichier à 18-25 KB, une économie de 75-85% par police. Les outils comme glyphhanger ou Fontsource gèrent le subsetting automatiquement. Auto-hébergez le fichier subensemblé avec font-display: swap pour que le texte s'affiche immédiatement dans une police de secours et se peigne à nouveau quand la police personnalisée charge. Limitez les poids totaux à deux ou trois (un corps, un titre, optionnel un affichage). Chaque poids supplémentaire est un autre 18-25 KB plus une requête bloquant le rendu sauf préchargé.

Lancez un outil de purge CSS contre votre build en production. PurgeCSS analyse les modèles HTML et JS pour les noms de classe et supprime n'importe quel sélecteur dans votre CSS qui ne référencé jamais. Le compilateur JIT de Tailwind le fait automatiquement. Pour le CSS écrit à la main, les frameworks comme Next.js, Astro, et SvelteKit lancent une étape de purge au moment du build. Les économies sont généralement dramatiques : un site Bootstrap qui livre le framework complet de 200 KB peut tomber à 8-15 KB après purge. Incorporez le CSS critique pour le contenu au-dessus du pli dans l'en-tête (généralement 10-15 KB) et chargez le reste avec <link rel="stylesheet" media="print" onload="this.media='all'">. Revérifiez avec le vérificateur de taille, puis lancez h1-checker pour confirmer que le HTML plus léger a toujours une structure de titre valide.

Le chargement paresseux différe le téléchargement des actifs hors écran jusqu'à ce que l'utilisateur fasse défiler près d'eux. L'attribut HTML natif loading="lazy" fonctionne sur <img> et <iframe> dans 95% des navigateurs et nécessite zéro JavaScript. Sur une page d'article longue avec 30 images, le chargement paresseux différe généralement 25 d'entre elles, réduisant la charge initiale de 60-80% et abaissant LCP de 1-2 secondes. Appliquez-le à chaque image et iframe sous le pli, mais jamais à l'image LCP elle-même, car le chargement paresseux du héros retarde la métrique que vous essayez d'améliorer. Combinez avec la conversion de format d'image (AVIF ou WebP) pour des gains composés. Le vérificateur signale les pages avec des nombres d'images élevés ; si vous voyez 40+ images sur une seule page, le chargement paresseux est votre plus grand gain disponible.

La taille du doc HTML est les octets de la réponse HTML elle-même : le balisage que le serveur a retourné avant que le navigateur récupère n'importe quelle sous-ressource. Le poids total de page est la somme du doc HTML plus chaque fichier CSS, fichier JS, image, police, vidéo, et iframe que la page charge. Une page peut avoir un doc HTML de 8 KB et un poids total de 6 MB si elle charge des images lourdes et des scripts. Ou elle peut avoir un doc de 250 KB plein de contenu en ligne et un total de 400 KB. Le vérificateur rapporte la taille du doc HTML directement de la réponse et estime le poids total à partir du nombre d'actifs déclarés en utilisant les médianes du Web Almanac 2024. Le nombre du doc HTML importe le plus pour le budget de crawl ; le poids total importe le plus pour LCP.

Les en-têtes cache-control disent au navigateur combien de temps garder un actif avant le redemander. Un en-tête de cache-control: public, max-age=31536000, immutable dit au navigateur de garder le fichier pendant un an et de ne jamais revalider. Les visiteurs répétés téléchargent zéro octet pour cet actif. Le vérificateur rapporte la valeur Cache-Control sur la réponse HTML pour que vous puissiez vérifier votre configuration CDN. Le HTML lui-même devrait généralement être court-caché (300-600 secondes) puisque le contenu se met à jour fréquemment. Les actifs statiques (JS, CSS, polices, images) avec noms de fichier hachés devraient être cachés un an car un changement de contenu crée un nouveau nom de fichier. Sans mise en cache appropriée, chaque chargement de page est une charge froide.

Content-Encoding est l'en-tête de réponse HTTP qui dit au navigateur comment le corps a été compressé. Les valeurs courantes sont gzip, br (brotli), deflate, zstd, ou vide (non compressé). Le vérificateur rapporte ce que votre serveur a retourné. S'il affiche gzip sur une réponse texte, vous économisez 70-80% de bande passante par rapport à non compressé. S'il affiche br, vous économisez un supplémentaire 15-25% en plus de gzip. S'il est vide sur une réponse HTML, CSS, ou JS de plus de 5 KB, votre serveur ou CDN est mal configuré et chaque visiteur paie le poids complet non compressé. Les formats binaires (JPEG, PNG, WebP, AVIF, MP4) sont déjà compressés au niveau du format et retournent généralement un Content-Encoding vide.