HTMLminify ou la mort des standards W3C
Thomas SOUDAZ dans Référencement le 11 avril 2010 à 12 h 23 min
Les référenceurs dignes de ce nom savent que la performance web (comprendre le temps de chargement des pages d’un site) est l’un des nombreux critères pris en compte par Google dans son algorithme de classement des résultats.
En 2009, Matt Cutts, chef de la cellule antispam et porte parole officiel de Google, s’était exprimé une première fois sur le sujet, indiquant que le temps de chargement n’affectait pas encore les résultats. Plus récemment Matt indiquait que si les sites lents n’étaient pas forcément pénalisés en revanche les sites rapides pouvaient obtenir un petit bonus sur la note finale de performance qui détermine l’ordre des résultats.
Le 9 Avril 2010 dans un billet collégial signé par les principaux ingénieurs de Google l’information a été officialisée : la vitesse de chargement est un des critères pris en compte par l’algorithme de Google. Et s’il est une chose que tout SEO black, grey et white hat doit faire c’est bien de maximiser les leviers « on page ». Outre le référencement naturel, optimiser la performance d’un site permet également : d’améliorer considérablement l’expérience utilisateur, de faire baisser le taux de rebond, d’éviter d’avoir un malus en SEA, d’améliorer les taux de conversion, en clair d’améliorer la profitabilité d’un site.
La quasi totalité du web n’est pas correctement optimisée (à part peut-être quelques Gurus de la perf et les SERPs de Google), il existe de très nombreux leviers d’optimisation du temps de chargement des pages et si je n’ai pas vocation à tous les développer sur cet article je vous invite à consulter les deux documentations les plus abouties sur le sujet :
- Web Performance Best Practices par Google
- Best Practices for Speeding Up Your Web Site par Yahoo!
Mise en garde
L’optimisation du HTML ne fait pas parti des « Quick Wins » de la performance sauf si vous travaillez sur des pages html statiques là ça peut allez assez vite, ne songez à « minifier » votre code Html qu’à partir du moment ou vous aurez pris sérieusement en main la performance de vos pages et que vous aurez déjà atteint une note supérieure à 90/100 sur PageSpeed ou un A sur YSlow. La plupart du temps vous ne réduirez la taille de votre document HTML « que » de 5% à 20%.
Le HTML n’est pas un langage de programmation optimisé
N’en déplaise aux ayatollahs des standards W3C, qu’il s’agisse du html3, 4, 5, ou du xhtml; le html n’est pas optimisé et possède de nombreuses balises et attributs redondants et inutiles.
L’équipe de développement à l’origine du projet HTMLminify chez Google a donc identifié plusieurs éléments HTML qui lorsqu’on les retire n’ont aucun impact sur l’affichage et laisse la page tout à fait accessible, à noter que ces optimisations sont appliquées sur les pages de résultats de Google depuis un an déjà.
Que fait HTMLminify ?
un listing détaillé des optimisations faites avec HTMLminify est présent dans le code source de l’addon firefox PageSpeed, l’original est accessible sur Google Code html.compactor, mais puisque c’est en anglais je vous en propose la traduction :
- Retrait des « guillemets » lorsque cela est possible, ainsi <a href=test.html> est bon, tandis que un <a href="un test.html"> devra conserver les guillemets à cause de l’espace.
- Sauf exceptions, les espaces, sauts de ligne excessifs et tabulations entre les balises HTML sont retirés.
- Retrait des commentaires (sauf exceptions).
- Retrait des balises inutiles qui n’altèrent pas le rendu de la page.
la liste complète des balises : <html>, <head>, </head>, </body>, </html>, </li>, </dt>, </dd>, </p>, </optgroup>, </option>, </colgroup>, </thead>, </tbody>, </tfoot>, </tr>, </th>, vous noterez que bon nombre de ces balises sont des balises de fermeture. - Passage en minuscule des noms de balise.
- Retrait des attributs par défaut comme <input type=text> ou <script type=’text/javascript’>
- Réduction des attributs quand une seule valeur est possible par exemple <option selected=selected> peut s’écrire <option selected>.
- Classement des attributs de balise pour une meilleure compression.
- Retrait des espaces, tabulations et sauts de lignes dans le CSS
- Retrait des espaces, tabulation et sauts de lignes dans le Javascript
- Utilisation des caractères non encodés ainsi « ‘ » ne s’ecrira pas « ' »
Mais développer en « HTMLminifié » est assez fastidieux cela implique d’avoir déjà une excellente maîtrise du HTML et de ses standards mais surtout une rigueur sans faille lorsqu’il s’agira de tester vos pages sur les différents navigateurs et systèmes d’exploitations existants.
L’addon PageSpeed, téléchargeable sur le site de Google, vous sera d’une grande aide puisqu’il propose après un scan une version optimisée des pages qu’il audite, cela permet d’optimiser les pages statiques très simplement pour les pages construites dynamiquement il faudra faire preuve de patience et optimiser chaque parcelle de code.
Les risques
J’insiste sur le fait que le HTMLminify n’est pas à mettre entre toutes les mains, d’abord parce qu’avec ce genre d’optimisations, les intégrateurs travaillent sans filet, une fois mises en place les moulinettes de validation W3C ne pourront plus vous aider à corriger le code HTML de vos pages. Autre difficulté, si vous poussez la logique de réduction du code à l’extrême en supprimant la plupart des sauts de ligne, le html deviendra presque illisible, à force vous retrouverez rapidement vos marques mais ce genre de condition de développement ne facilite pas le travail collaboratif, heureusement beaucoup de logiciels indentent automatiquement le code.
La performance web revêt un enjeu business décisif et force est de constater que les standards web ne répondent pas à ce besoin d’efficacité, les techniques d’optimisation type HTMLminify vont à mon avis connaître un véritable succès dans les années qui viennent, les référenceurs devront rajouter une corde à leur arc s’ils veulent rester au top.
Pour aller plus loin, il est possible de suivre et de participer au groupe Google PageSpeed, on y découvre notamment que lors d’un appel à un fichier .js ou .css inférieur à 500 octets il est préférable d’inclure le code sur la page (inline .js et inline .css) pour faire l’économie d’un aller/retour d’entête HTTP. Enfin je vous invite à consulter les pages de recherche Google qui sont extrêmement bien codées minifiées à l’octet près…
Excellent!
Je ne connaissais pas du tout.
Tiens, j’édite mon billet d’hier sur le sujet pour ajouter ton lien
Pour virer les indentations à l’affichage, il suffit d’ajouter un ob_start et ensuite ereg replace CHR(10)
Enfin c’est mat technique.
Je voulais dire saut de ligne.
@LaurentB thx pour le BL et le RT
@Robien, pas mal la technique. Petite précision, lu sur le groupe google page speed un Googler, Richard Rabbat explique qu’il faut un saut de ligne tous les 500 caractères en ce qui concerne le code javascript, et cela pour que le code reste compatible avec les vieux parser de javascript.
Superbe article, merci thomas.
Sympa l’article, mais, parce que j’aime les « mais »,
retirer du code provoque un ralentissement du rendu d’une page, le navigateur doit boucher les trous avant d’envoyer la page. Je te dis ça parce que je l’ai expérimenté avec mon site corp fullajax, je pensais pouvoir faire gagner du temps à mes vieux P3 sous ubuntu, mais au final j’ai gagné que des freezes de quelques secondes qui me faisait perdre tout le temps gagné. Tout est question de mesure, une page bourrée de tableaux par exemple, si on retire toutes les balises fetmantes, aura un temps de rendu significativement supérieur à une page codée proprement . Mais quel intérêt alors dans une page à la mesure? aucun…
Tu ne parle pas du Gzip, mais je vais encore dire que c’est pareil, trop de GZip tu le Gzip, parce qu’une page Gzipée il faut la décompresser et donc perdre des secondes à ça.
Personnellement je ne l’ai pas comprise comme ça la nouvelle politique de google, je pense plutôt que c’est sur le temps de réponse de nos servers qu’ils faut se pencher, poser du cache par exemple, il y a aussi le temps de réponse de certaines affils qui pourrissent le temps d’affichage de nos sites, et puis les libs Js inutile aussi qu’on retrouve souvent en collection sur les WP de newb
petit astuces en passant pour les Antivétroissémites la balise < code > reset le html, en mettant un code tordu dans du « code » une erreur ne se répercutera pas sur le reste de la page.
Content de voir que tu as un blog
Faut-il, au nom de la sainte performance, « sacrifier » tous les intérêts apportés par les standards, à savoir : l’accessibilité en premier lieu, mais aussi l’assurance d’un code (sensé être) interprété de la même manière partout ?
Développons. Je vois en effet beaucoup de points négatifs à ce procédé, pour bien peu d’avantages. En réalité, le seul avantage, c’est de gagner une quantité infime de poids du HTML, et donc de vitesse de chargement de la page. Et, comme vous le précisez déjà, ce temps économisé est relativement infime en comparaison avec d’autres optimisations possibles, notamment au niveau du code exécuté du côté du serveur, ou de la mise en cache. (Je parle ici dans le cadre d’un gros site web, si c’est pour un petit site vitrine ne contenant que du HTML pur, aucun intérêt de minimiser, les performances seront déjà bien supérieures à celles des sites plus gros. )
Par contre, des inconvénients, il y en a. Premièrement, le non-respect des standards. Ils ont beau ne pas être suffisamment optimisés, ils ont une raison d’être : l’accessibilité. Respecter les standards, c’est s’assurer que tous les visiteurs, même les visiteurs handicapés, pourront accéder à votre site dans les meilleures conditions.
Les deux autres problèmes majeurs, vous les abordez déjà : la minimisation du code le rend totalement illisible, donc totalement indébugable, et totalement incompréhensible par d’autres développeurs. Et ceci casse un des fondements du web : son ouverture. Quiconque visitant un site web et découvrant une fonctionnalité intéressante en HTML / CSS / JS pourra regarder, lire, comprendre, et reprendre le code à l’origine de cette fonctionnalité. En détruisant la structure du code, vous rendez ceci impossible, ou bien plus compliqué. J’ai abordé cette problématique sur mon blog récemment, dans le cadre de la minimisation des fichiers CSS, je vous invite à aller lire mon article si cela vous intéresse.
Je comprend qu’on veuille supprimer des caractères superflus dans un fichier HTML / CSS / JS, je le fait moi-même sur mes sites. J’ai par contre beaucoup de mal avec le projet HTMLminifier, qui détruit la structure du code HTML et le rend totalement incompatible avec les standards. Le résultat a beau être le même sur la majorité des navigateurs et des machines, je suis persuadé qu’à terme, cela portera atteinte à la qualité de la navigation d’un visiteur avec une configuration plus particulière.
De plus, j’insiste sur le fait que la compression du code HTML ne doit être utilisée qu’en dernier, les gains de performances étant bien moindre que pour d’autres méthodes. Je n’ai pas de lien sous la main, mais Google saura, je pense, vous renseigner sur ce sujet.
Pour finir, je pense que nous avons deux approches différentes, et qu’à un moment dans la vie d’un site, il faut choisir entre performances ultimes et accessibilité. Personnellement, je prend l’accessibilité, mais je comprend que vous fassiez l’autre choix !
Merci pour cet article fort intéressant et instructif !
@pagetro : oui retirer du code peut provoquer un ralentissement du rendu de la page (mais concernant les balises suscitées je ne pense pas que cela soit le cas).
C’est le cas par exemple des attributs width et height au sein les balises < img >, les retirer oblige le navigateur à recalculer la dimension de l’image et cela ralenti l’affichage.
Si on élargie un peu la problématique il est vrai que bien souvent (c’est le cas de la compression Gzip que tu cites), il faut arbitrer entre temps de chargement et temps de traitement sur la machine cliente, d’ailleurs dans l’immense majorité des cas un code HTML non valide, avec des balises manquantes va littéralement pourrir le temps de traitement du navigateur. C’est précisément pour ça que le HTMLminify doit être utilisé par des développeurs/intégrateurs de bon niveau.
D’ailleurs en minifiant une page qui comporte déjà des erreurs vous avez toutes les chances d’obtenir l’effet inverse que celui escompté, la compression HTMLminify part du principe qu’à la base vos pages sont propres.
@adrian Tu soulèves là un point crucial, mais, est-ce que ces optimisations nuisent vraiment à l’accessibilité ?
Si un spécialiste de l’accessibilité qui possède le ou les logiciels adéquats (dédié aux aveugles par exemple) pouvait nous dire s’il éprouve des difficultés à lire les pages de résultats de Google je suis assez preneur de l’information.
En ce qui concerne la lisibilité d’un code sans saut de ligne et mal indenté, je ne saurais que trop conseiller aux curieux d’installer Firebug
@Adrian Gaudebert — à première vue, la suppression des balises mentionnées ici ne porte pas vraiment préjudice aux standards, en tout cas en ce qui concerne HTML5 : la fermeture des balises y est optionnelle ; les balises html, body et head sont implicites, etc. L’important est de s’assurer qu’on a pas mis une classe aux balises html et/ou body.
Et bien moi, à titre personnel, je viens d’apprendre plein de choses.
Je sais que notre responsable du Dev à mis en place pas mal de choses sur les sites dynamiques de nos clients et qu’il va me dire « Mais oui, je savais ». Mais pour ma part, je ne savais pas, merci.
Sinon, je me méfies tout de même toujours des effets d’annonce de Google. Sur le plan de la rapidité d’affichage, les compromis que nous ferons seront toujours en direction du visiteur, pas des moteurs, parce qu’en bout de course, ce sont tout de même eux qui font manger nos clients., et donc nous mêmes indirectement.
Pour les blogs WordPress, l’utilisation de l’extension W3 Total Cache permet de gagner un temps de chargement considérable, notamment de par l’utilisation de la minimalisation HTML, CSS, JS, et leur éventuelle concaténation.
Une optimisation efficace ne passe pas forcément par une optimisation aussi « barbare ». Ce que je vois ici, c’est que Google nous incite à travailler pour lui en leur offrant des pages moins gourmandes en ressources pour le crawling. D’ailleurs, une politique d’optimisation aussi agressive est un problème qui les concerne, pas nous : le nombre de pages vues fait que la moindre optimisation signifie une diminution des coûts matériels, par contre sur nos propres sites, les différences sont mineures.
@Tom sur un double cœur (Pc moderne) tu ne le sentira pas, mais sur un mobile ou un vieux Pc ça freez je te le garanti
A mon avis, et Thomas l’explique bien dans son article, la minification du HTML est une étape réservée aux très gros sites qui ont déjà épuisé toutes les autres formes d’optimisations possibles. 80% du temps de réponse, en moyenne sur la majorité des sites, dépend des autres composants de la page (images, scripts, styles, …) qui, s’ils sont minfiés, compressés, optimisés, …, amélioreront les performances beaucoup plus qu’une minification de la page HTML.
Personnellement, je ne suis pas favorable à cette technique, on y perd tellement en souplesse, en lisibilité de code, en accessibilité et surtout en temps de mise en place. Convaincre un client des bénéfices de l’optimisation des performances de son site est déjà une épreuve ardue, le forcer à modifier l’ensemble de son code HTML pour grapiller quelques millisecondes est une autre paire de manches!
je ne sais pas pour les vieux PC, (bien que j’ai un environnement de test assez proche de celui que tu décris avec mon ordi du boulot :p) en tout cas la version mobile des SERPs de Google accessible avec un UserAgent iPhone par exemple est relativement bien compressé au niveau des sauts de lignes/identation mais n’utilise pas HTMLminify (le code est un peu plus standard friendly), c’est peut-être un compromis à creuser.
Méthode bien radicale et chronophage pour le gain au final…des méthodes alternatives sont peut être à privilégier.
Je pense notamment à l’utilisation de CSS3, qui selon les cas permet d’alléger le poids des pages de manière conséquente, et aide ainsi à un satisfaire à ce nouveau critère qu’est la vitesse de chargement. Merci en tout cas pour la présentation de cette méthode.
Personnellement cette technique me laisse perplexe et je pense que le ratio gain de performance/perte de confort de travail n’est pas intéressante.
Je rejoins « Adrian » dans ces remarques et surtout je pense que l’optimisation du nombre de feuilles CSS et du nombre de scripts ou librairies javascript appelées ainsi que leur optimisation et leur concaténation apportent déjà un gain important (sans parler du cache, de la compression, d’une bonne optimisation des images, etc.).
L’intérêt c’est le confort de l’utilisateur et, en effet, il est intéressant qu’un acteur majeur du web freine cette course au débit qui laisse penser aux développeurs et autres administrateurs de sites qu’il peuvent envoyer des pages d’accueil énormes, des photos très lourdes et des animations flashs à rallonge sous prétexte de haut débit.
Non tout le monde n’a pas une connexion dégroupée à 20Mb (même si en ce qui me concerne j’ai cette chance) et certains sites deviennent vraiment compliqués à consulter quand vous passez sous les 2Mb.
En revanche, en arriver à ces extrêmes me semble excessif et je ne pense pas que les 1 ou 2% gagnés changent quelque chose pour le visiteur. Si on doit sacrifier les standards et le confort qu’ils apportent pour faire plaisir à Google et soulager ses serveurs trop peu pour moi.
Un site optimisé le mieux possible, avec du bon contenu et agréable à consulter pour le visiteur sera toujours plus efficace (et mieux référencé) sans forcément nécessiter d’en arriver à ces extrêmes.
@vince il est clair que maximiser l’optimisation a un coût humain et technique, et gagner 1 ou 2%, voir 3/4% si la plupart des optimisations sont déjà faites ça ne change pas grand chose si on se borne à la vision micro – Mais sur des dizaines / centaines de milliers de visiteurs on peut commencer à se poser très sérieusement la question
.
Très intéressant, au passage je découvre ton blog grâce à Laurent. W3C contre allègement du html, tel est le débat….
Avec Caféine, cela devient quand meme un point important
Yvan,
En voilà une belle atrocité pour gagner quelques cacahouètes… Pour gagner en perfs, il y a une foule d’autres choses à prendre en compte avant d’en arriver à de pareilles hérésies contre-nature.
Consternant.
Google n’est pas le seul à recommander d’optimiser les performances de ses pages. Yahoo! fait aussi un gros travail sur le sujet : http://developer.yahoo.com/performance/.
Et bien sûr, j’abonde fortement dans le sens du respect des standards : il y a beaucoup d’autres points à travailler avant d’en arriver à ses aberrations.
Je découvre ce blog et cet article sur les standards W3C et le HTML. Très instructif
bon je vais vérifier ca avec pagespeed …
la problématique est maintenant de savoir prioriser ou mettre en poids sur chacun de ces paramètres …
merci pour cet éclairage !
@ bientôt
Sebastien
Merci à Laurent qui m’a fait découvrir ton blog. Un billet très intéressant pour les développeurs qui se préoccupent du seo.
Ca donne vraiment a reflechir surtout une raison d’optimiser encore encore son site…
Effectivement, difficile une fois cette opération effectuée de comprendre grand chose lorsqu’on ouvre le code source de la page !