Vérificateur de poids de page
Récupère une URL, pèse son HTML et inventorie chaque script, feuille de style, image et embed qu'elle référence, tes propres origines séparées des tierces.
Ce vérificateur de poids de page prend une URL, récupère le HTML côté serveur et transforme un simple chiffre de poids en quelque chose d'actionnable. Il pèse le markup qu'il a tiré, liste chaque asset que le document pointe (scripts, feuilles de style, images, médias, embeds et preload hints), additionne les octets de tes scripts et styles inline, signale le markup d'image négligé comme les dimensions manquantes, puis trie tes propres origines de celles de tout le monde. Il note la passe face à un budget de revue que tu choisis (page SEO légère, page d'outil ou page bourrée de médias), nomme le seul truc qui mérite ta prochaine heure, et lit les response headers pour que les indices de compression et de cache soient juste à côté du markup. C'est un premier passage, pas le dernier mot : une liste d'URLs prouve qu'un asset est référencé, pas ce qu'il pèse sur le réseau, donc tu confirmes le vrai waterfall dans un navigateur. Tu peux copier un rapport simple ou un CSV des ressources pour la passation.
Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.
Audit du poids HTML et inventaire des ressources
Un seul chiffre de poids de page ne m'a jamais rien appris sur ce qu'il fallait vraiment corriger. Ça m'a un peu rendu fou. Du coup cet outil récupère ton HTML, lit chaque asset que la page pointe (images, scripts, embeds, fonts, tout le bazar), les compte, sépare tes propres trucs de ceux des autres, puis te renvoie une courte liste de ce qu'il faut corriger en premier. Petit article de blog ou monstre bourré de médias, peu importe. Même traitement.
Premier passage. Pas le dernier mot. Il pèse le markup qu'il récupère et liste les assets que ce markup pointe. Pour les vrais octets transférés, le poids réel des images, les Core Web Vitals, il te faudra quand même un browser waterfall ou un vrai run en lab.
Ce qu'un vérificateur de poids de page peut te dire avant un waterfall complet
"Cette page est lourde", on le balance comme si un seul chiffre réglait tout. Ce n'est pas le cas. Ton HTML, les scripts, les images, les embeds, les fonts, chaque tag tiers, le comportement du caching, la vitesse à laquelle le serveur daigne répondre. Tout ça te plombe différemment. Et ça ne casse pas de la même façon non plus. Un vérificateur rapide gagne sa place quand il te pointe vers la couche qui mérite ta prochaine heure. Il ne remplacera pas un vrai profil de performance, et honnêtement je mentirais si je te disais l'inverse.
Donc je commence par ce que la page montre réellement dans son markup. Il pèse le HTML que j'ai récupéré pour l'audit, liste chaque URL d'asset que le document référence, additionne les octets de tes scripts et styles inline, signale les négligences sur les images comme les dimensions manquantes, puis trie tes propres origines de celles des inconnus. Il lit aussi les response headers qui sont revenus avec le HTML. Tes indices de compression et de cache finissent juste à côté du markup au lieu d'être à deux onglets de distance.
Pourquoi le poids du HTML compte encore sur une page moderne
Oui, les images et le JavaScript sont ce que les gens ressentent quand une page traîne. Bien sûr. Mais un document HTML obèse est un signe que j'ai appris à ne pas balayer. Les page builders. Des arbres de navigation gros comme un sitemap. Le même bloc FAQ collé trois fois, du JSON inline, des snippets de tracking, beaucoup trop de markup tassé au dessus de la ligne de flottaison. Tout ça rend le document plus lent à expédier et plus lent à digérer pour le navigateur. Sur une page SEO il y a une raison de plus de rester léger. Quand la source est propre, ton title, tes headings, tes liens et tes structured data ne sont pas enterrés sous une montagne de bruit de template. Les audits arrêtent d'être une chasse au trésor.
- Résumé te donne le nombre d'octets HTML, combien d'assets la page référence, plus le truc que je corrigerais en premier.
- Inventaire des ressources c'est la liste complète. Chaque script, feuille de style, image, embed, preload hint trouvé dans le markup.
- Mix des origines te dit vite si tu t'appuies lourdement sur les serveurs des autres.
- Signaux du markup c'est là que vivent les petits détails. Les octets inline, les dimensions d'image manquantes, le lazy loading, les headers du document lui même.
- CSV des ressources c'est ta feuille de passation pour quand il faut nettoyer un thème, un plugin ou un tag manager devenu incontrôlable.
Comment exploiter le résultat en tant que propriétaire de site
- Commence par l'action du haut. Puis va creuser ce qui a explosé le budget, que ce soit le HTML, les scripts, les images ou les serveurs des inconnus.
- Sur une page de contenu, dégage les plugins, les widgets et les sections dupliquées qui n'aident personne à lire réellement la chose.
- Sur une page d'outil, garde le code de l'app qui fait le boulot. Mais méfie toi des analytics en double, des bulles de chat et des librairies chargées pour une feature que tu utilises à peine.
- Sur une page bourrée de médias, ne sacrifie pas la qualité de tes images. Sers juste les bonnes dimensions et un format moderne, lazy load sous la ligne de flottaison, et fais tourner un embed de moins que ce que tu crois nécessaire.
- Tu as touché au code ou changé de thème ? Prouve le gain avec un response time check et un vrai profil navigateur. Ne me crois pas sur parole. Ne te crois pas toi même non plus.
Ce que cet audit ne prétend pas faire
Petit moment d'honnêteté. Je préfère te dire les limites plutôt que te regarder faire trop confiance au chiffre. Le nombre d'octets, c'est le texte HTML récupéré, point final. Une liste d'URLs d'assets prouve seulement qu'ils sont référencés. Elle ne dit rien sur ce que cette image ou ce script pèse réellement une fois compressé et sur le réseau. Le browser caching, la compression de ton CDN, le viewport, les responsive images, tout ce que le JavaScript va chercher plus tard. Chacun de ces éléments remodèle le vrai waterfall. J'ai tracé la limite là exprès, et c'est peut être juste moi qui suis prudent, mais je pense qu'un outil honnête sur ce qu'il ne voit pas vaut mieux qu'un qui fait semblant. Tu repars quand même avec une lecture plus fine que celle qu'un score de poids de page tout seul t'a jamais donnée.
Questions fréquentes
Une petite page HTML est-elle automatiquement rapide ?
Non. Je me suis fait avoir en supposant exactement ça. Un minuscule fichier HTML peut quand même traîner une hero image de 2 Mo, un gros JS bundle, toute une ad stack, une pile de widgets tiers. Regarde d'abord l'inventaire des ressources. Puis va le mesurer dans un vrai navigateur avant de célébrer quoi que ce soit.
Pourquoi compter les origines tierces ?
Chaque host externe que tu appelles, c'est un DNS lookup de plus, une connexion de plus à établir, une question de vie privée de plus. Et un truc de plus qui peut tomber et emporter une partie de ta page avec lui. Beaucoup d'entre eux méritent leur place. Le but n'est pas de tout dégommer. C'est de voir réellement ce que tu transportes au lieu d'en hériter un plugin à la fois sans jamais t'en rendre compte.
Faut-il mettre toutes les images en lazy load ?
Non. Mettre ta hero image en lazy load est un classique auto but qui flingue le LCP. Tout ce qui est visible en haut de la page devrait charger tout de suite. Garde le lazy loading pour ce qui se trouve sous la ligne de flottaison. Largeur, hauteur, dimensionnement responsive par contre ? Ça aide partout. Du haut jusqu'en bas.
Quel est un poids de page raisonnable ?
Pour une page de contenu j'essaie de rester sous 1 à 2 Mo et là je dors bien. Les images et le JavaScript sont presque toujours le gros du poids. Donc compresser tes images et couper les scripts morts, c'est là que le vrai poids s'enlève. Tripatouiller le markup ne bouge quasiment pas l'aiguille à côté de ça.
Pourquoi le poids de page affecte-t-il le SEO ?
Page plus lourde, chargement plus lent. C'est juste de la physique, et ça touche tes Core Web Vitals plus quiconque sur un téléphone en data mobile bancale. Google utilise bien la vitesse comme signal de ranking. Mais honnêtement la partie qui me tient le plus à cœur c'est celle ci : les pages lentes font fuir les gens avant qu'ils ne convertissent, et tu peux le voir se produire dans tes analytics.