Cookies necessaires
Toujours actifs. Ils assurent le fonctionnement technique du site et la memorisation de votre choix de consentement.
“ Et ce n'est pas toujours la faute du JavaScript ”
Ces chiffres, je les connais par cœur. Et pourtant, j'ai longtemps cru que la performance web, c'était l'affaire des développeurs back-end, des DevOps ou des experts JavaScript. Jusqu'au jour où j'ai réalisé quelque chose d'essentiel : la performance commence dans le HTML, bien avant d'ouvrir les DevTools.
“ Un site e-commerce perd en moyenne 1 % de chiffre d'affaires pour chaque 100 ms supplémentaires. 40 % des visiteurs quittent une page qui met plus de 3 secondes à charger. Et 60 % abandonnent dès 5 secondes. ”
Les études parlent d'elles-mêmes, et les données récentes de 2024-2026 confirment une tendance sans appel : l'utilisateur moderne ne tolère plus la lenteur.
Et ce n'est pas tout. Google intègre désormais les Core Web Vitals dans son algorithme de classement. LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint) : ces métriques mesurent directement ce que l'utilisateur ressent. Et devinez qui impacte directement ces trois métriques ? L'intégrateur HTML/CSS.
On lit beaucoup d'articles sur la performance qui parlent de CDN, de compression gzip, de lazy loading côté JavaScript. C'est vrai et utile. Mais dans mon travail quotidien d'intégrateur, j'ai appris que les fondations commencent bien plus tôt.
Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle d'une page. Quand une image charge et fait "sauter" le contenu vers le bas, c'est du CLS. Et la cause numéro un ? Une balise <img> sans attributs width et height. Le navigateur ne connaît pas les dimensions de l'image avant qu'elle soit chargée, donc il ne peut pas réserver l'espace. Résultat : tout bouge. C'est une erreur de base, mais elle reste l'une des plus fréquentes sur le terrain.
Le LCP (Largest Contentful Paint) mesure le temps d'affichage du plus grand élément visible. Et rien ne le plombe plus vite qu'une font chargée sans font-display: swap. Le navigateur attend le chargement complet de la police avant d'afficher le texte. L'utilisateur voit une page blanche ou un texte invisible. C'est du FOIT (Flash of Invisible Text), et c'est entièrement dans les mains de l'intégrateur.
Chaque fichier CSS chargé dans le <head> bloque le rendu de la page tant qu'il n'est pas entièrement téléchargé et analysé. Un seul fichier CSS mal optimisé ou un @import imbriqué, et tout le rendu attend. La solution est dans l'ordre des <link>, dans la stratégie de chargement, dans l'utilisation de media="print" pour les styles non critiques. C'est du HTML pur. Pas de JavaScript.
Google recommande de ne pas dépasser 1 500 nœuds dans le DOM, avec une profondeur maximale de 32 niveaux. J'ai audité des pages avec 5 000, 8 000, parfois 12 000 nœuds. Des <div> imbriqués à l'infini, des balises sémantiquement inutiles, des composants générés automatiquement qui doublent la structure. Un DOM lourd ralentit le parsing initial, alourdit les calculs de style et impacte directement l'INP. L'HTML sémantique n'est pas juste une question d'accessibilité : c'est aussi une question de performance.
Je vais être honnête : j'ai moi-même commis certaines de ces erreurs. On intègre vite, on livre, on passe au projet suivant. La performance, c'est souvent la dernière case cochée avant la mise en ligne, quand ce n'est pas carrément oubliée.
J'ai vu des projets entiers pénalisés par Google à cause d'un score LCP à 6 secondes. En cherchant la cause : une image hero de 2,4 Mo sans attributs de dimensions, chargée en eager par défaut. Deux lignes de HTML à corriger. Deux lignes.
J'ai aussi vu des développeurs passer des heures à optimiser leur bundle JavaScript alors que le vrai problème venait d'une Google Font chargée sans font-display: swap et d'un <link rel="preconnect"> manquant. Encore du HTML/CSS. Pas du JS.
Et il y a un autre angle que j'ai appris à regarder : l'état actuel du web en 2025-2026. Les connexions médianes et lentes n'ont connu aucune amélioration depuis fin 2024. Pendant ce temps, le poids médian des pages mobiles est 2,5 fois supérieur à ce qu'il était il y a dix ans. On construit des sites de plus en plus lourds pour des connexions qui ne s'améliorent pas. Ce n'est pas un problème d'infrastructure. C'est un problème d'intégration.
Je ne dis pas que le JavaScript n'a pas son rôle à jouer dans la performance. Bien sûr que si. Mais ce que je constate, après des années d'intégration, c'est que notre partie du travail — le HTML, la structure, les attributs, l'ordre des ressources — est souvent négligée parce qu'elle semble "simple".
Elle ne l'est pas. Elle est fondamentale.
Un site accessible, un dark mode bien implémenté, un design inclusif pour les daltoniens — tout ça perd sa valeur si la page met 5 secondes à charger. La performance est le socle sur lequel repose toute expérience utilisateur.
Alors la prochaine fois que vous ouvrez Lighthouse et que le score est mauvais, avant de blâmer le JavaScript : jetez un œil au HTML. La réponse y est souvent.
#PerformanceWeb #CoreWebVitals #HTML #CSS #IntégrationWeb #DéveloppementWeb #UX #WebPerf #FrontEnd #LCP #CLS #INP
Et vous, avez-vous déjà trouvé une source de lenteur dans votre HTML que personne n'avait vue ? Partagez en commentaire 👇