Checklist HTML de vitesse de page

Collez le HTML d'une page pour repérer scripts bloquant le rendu, images sans dimensions ni lazy loading, viewport manquant, @import, document.write et plus.

Ouvrez la page, utilisez « Afficher le code source » (Ctrl+U), copiez tout et collez-le ici.

Taille du HTML 0.4 Ko · 11 éléments · 2 scripts · 1 feuilles de style · 3 images
Améliorations possibles : 8
Impact élevé1 script(s) bloquant le rendu dans <head>

Ajoutez defer (ou async pour les scripts indépendants) afin que le navigateur affiche la page avant le téléchargement du script.

<script src="https://cdn.example.com/analytics.js">
Impact moyen1 image(s) sans width ni height

Indiquez width et height (ou aspect-ratio en CSS) pour que le navigateur réserve l’espace et que la mise en page ne bouge pas (CLS).

<img src="/hero.jpg" alt="Hero">
Impact faible1 image(s) hors du premier écran sans loading="lazy"

Ajoutez loading="lazy" aux images invisibles dans le premier écran.

<img src="/b.png" alt="B" width="300" height="200">
Impact faible3 image(s) en JPEG/PNG/GIF

Servez du WebP ou de l’AVIF (par ex. avec <picture>) : généralement 25 à 50 % plus léger à qualité égale.

<img src="/hero.jpg" alt="Hero">
<img src="/a.png" alt="A" width="300" height="200">
<img src="/b.png" alt="B" width="300" height="200">
Impact faible1 iframe(s) sans loading="lazy"

Ajoutez loading="lazy" aux intégrations comme les vidéos et les cartes.

<iframe src="https://www.youtube.com/embed/xyz">
Impact élevéPas de balise meta viewport

Ajoutez <meta name="viewport" content="width=device-width, initial-scale=1"> pour un affichage correct sur mobile.

<meta name="viewport">
Impact faibleAucune déclaration de charset dans <head>

Ajoutez <meta charset="UTF-8"> comme premier élément de <head>.

<meta charset="UTF-8">
Impact faible1 origine(s) tierce(s) sans preconnect

Ajoutez <link rel="preconnect"> pour les origines tierces importantes afin d’ouvrir les connexions plus tôt.

cdn.example.com
Vérifications réussies (8)
  • ✓ Peu de feuilles de style bloquantes
  • ✓ Aucun CSS @import
  • ✓ Les règles @font-face inline définissent font-display
  • ✓ La première image n’est pas chargée en différé
  • ✓ Pas de document.write()
  • ✓ Le code inline est léger
  • ✓ Taille du DOM raisonnable
  • ✓ Taille du HTML raisonnable
Il s’agit d’une liste de contrôle statique du HTML collé : la page n’est pas chargée, le JavaScript n’est pas exécuté et la vitesse réelle n’est pas mesurée. Utilisez Lighthouse ou PageSpeed Insights pour les mesures en laboratoire et sur le terrain (Core Web Vitals).

Qu'est-ce que Checklist de vitesse de page ?

Cet outil examine le code HTML d'une page selon une liste de problèmes courants de performance front-end et explique comment corriger chacun : scripts et feuilles de style bloquant le rendu, @import CSS, @font-face sans font-display, images sans dimensions ni chargement différé, image principale en lazy loading, formats d'image anciens, iframes sans chargement différé, viewport ou charset manquant, document.write, gros code inline, preconnect manquant et DOM ou HTML trop volumineux.

Comment utiliser Checklist de vitesse de page

  1. Ouvrez votre page, utilisez Afficher le code source (Ctrl+U) et copiez tout.
  2. Collez le HTML et cliquez sur Analyser.
  3. Examinez les constats triés par impact, avec les balises fautives affichées en exemple.
  4. Développez « Contrôles réussis » pour voir ce qui est déjà correct.

Exemple

Entrée
The sample page (analytics.js without defer, hero.jpg without size, iframe without lazy, no viewport)
Sortie
8 possible improvements: 1 render-blocking script, 1 image without width/height, 1 below-the-fold image without lazy loading, 3 JPEG/PNG images, 1 iframe without lazy loading, no viewport, no charset, 1 third-party origin without preconnect

Quand utiliser Checklist de vitesse de page

Utilisez-le pour une revue statique rapide de gabarits ou de pages, ou quand vous ne pouvez pas lancer Lighthouse. Il ne mesure ni les temps de chargement réels ni les Core Web Vitals et ne voit pas les ressources ajoutées par JavaScript ; utilisez Lighthouse ou PageSpeed Insights pour des données de laboratoire et de terrain.

Comment fonctionne Checklist de vitesse de page

Le HTML est analysé dans votre navigateur avec un analyseur de balises léger après suppression des commentaires. Chaque règle inspecte des balises et attributs précis : par exemple des balises <script> externes dans <head> sans async, defer ou type=module, des <img> sans width et height, des images après les deux premières sans loading="lazy", ou plus de 1 500 éléments au total. Les origines tierces des scripts et feuilles de style sont comparées aux liens preconnect et dns-prefetch. Aucune page n'est chargée et aucun JavaScript n'est exécuté.

Cas d'utilisation courants

  • Trouver les scripts qui bloquent le rendu dans l'en-tête d'un thème.
  • Repérer les images causant des décalages de mise en page faute de width et height.
  • Vérifier que l'image principale n'est pas en lazy loading (mauvais pour le LCP).
  • Relire des gabarits d'e-mail HTML ou de pages d'atterrissage avant le lancement.

Questions Fréquentes

Est-ce la même chose que Google PageSpeed Insights ?

Non. PageSpeed Insights charge la page et la mesure. Cet outil ne lit que le HTML collé : il est instantané et privé, mais ne peut pas mesurer la vitesse.

Pourquoi la première image ne doit-elle pas être en lazy loading ?

La plus grande image au-dessus de la ligne de flottaison est généralement l'élément du Largest Contentful Paint. Le lazy loading la retarde jusqu'à la mise en page, ce qui pénalise le LCP.

Tous les scripts doivent-ils utiliser defer ?

Les scripts qui ont besoin du DOM et s'exécutent dans l'ordre doivent utiliser defer ; les scripts indépendants comme l'analytique peuvent utiliser async. Le code critique inline doit rester petit.

Explorer d'autres catégories