Performance web : optimiser son code HTML et CSS

De la compression du code HTML à la normalisation des CSS, voici quelques bonnes pratiques indispensables pour réduire le poids des pages web, et améliorer leur vitesse de chargement et d'exécution par les navigateurs.

Comme nous l’avons vu dans l’article Pourquoi optimiser un site web ?, améliorer la vitesse de chargement des pages d’un site à au moins quatre impacts directs : le nombre de visiteurs (et par effet de levier le référencement), un manque à gagner économique et un impact environnemental réel. Ensuite, nous avons vu dans l’article Optimiser l’utilisation des images d’une page web comment améliorer la performance du poste le plus gourmand en ressources inutiles, les images, avec la prétention de réduire, parfois, de plus de 75% le volume global.

Pour le dernier article de cette série, je vous propose quelques techniques concernant le code HTML des pages.

 

Améliorations HTML

Pour commencer cette partie, rappelons une trivialité : chaque balise HTML est prévue pour un usage.

Il n’est en effet pas rare de constater que certains développeurs préfèrent alourdir leurs pages en déclarant des propriétés spécifiques alors qu’un certain nombre existent déjà. Prenons l’exemple des titres qui sont normalement définis par des balises H1, H2, H3, etc. Il est pourtant courant de trouver des définitions CSS du type titre1, titre2, titre3 appliquées à des paragraphes. Ces manières de procéder sont à proscrire car, en plus de provoquer des descriptions supplémentaires (et donc alourdir le poids des pages), elles pénalisent dans le même temps votre référencement naturel.

La meilleure pratique est plutôt de trouver les éléments communs à tous les navigateurs et de ne décrire ensuite, pour les balises ad-hoc, que les propriétés spécifiques. Pour définir les éléments communs aux feuilles de style des navigateurs, vous pouvez, par exemple, consulter la page Default CSS Rules of HTML Elements in Various Browsers.

Pour s’affranchir des écarts de définition par défaut des navigateurs, certains concepteurs appliquent systématiquement un reset CSS. Cette façon de procéder est tout à fait justifiable pour avoir la parfaite maîtrise de mises en forme complexes, mais est-elle aussi pertinente pour des designs simples de pages ? Une évaluation de la surcharge CSS ne prend pas nécessairement beaucoup de temps et peut révéler une source d’optimisation potentielle.

Commun à IE 6 et 7  
Commun à IE 8 et 9
h1 {
display: block;
font-size: 24pt;
font-weight: bold;
margin: 14pt 0;
}

h2 {
display: block;
font-size: 18pt;
font-weight: bold;
margin: 14pt 0;
}

h3 {
display: block;
font-size: 13.55pt;
font-weight: bold;
margin: 14pt 0;
}
h1 { 
display: block;
font-size: 2em;
font-weight: bold;
margin: 0.67em 0;
page-break-after: avoid;
}

h2 {
display: block;
font-size: 1.5em;
font-weight: bold;
margin: 0.83em 0;
page-break-after: avoid;
}

h3 {
display: block;
font-size: 1.17em;
font-weight: bold;
margin: 1em 0;
page-break-after: avoid;
}

Pour une page utilisant une taille de police par défaut de 12 pt, les rendus par défaut des titres à l’écran peuvent être considérés comme similaires. Les écarts pour des tailles de 11 à 13 pt sont très certainement tout aussi acceptables.

Les différences ne concernent que les marges supérieures et inférieures, la gestion des sauts de page lors des impressions ainsi que d’éventuels changements du zoom, mais nous sommes, pour ces derniers éléments, dans une gestion évoluée des pages.

Firefox, Firefox 2 et 3   
Opera 10.51              
Chrome et Safari
h1 {
display: block;
font-size: 2em;
font-weight: bold;
margin: 0.67em 0;
}
h2 {
display: block;
font-size: 1.5em;
font-weight: bold;
margin: 0.83em 0;
}

h3 {
display: block;
font-size: 1.17em;
font-weight: bold;
margin: 1em 0;
}
h1 { 
display: block;
font-size: 2em;
font-weight: bold;
margin: 0.67em 0;
}
h2 {
display: block;
font-size: 1.5em;
font-weight: bold;
margin: 0.83em 0;
}
h3 {
display: block;
font-size: 1.17em;
font-weight: bold;
margin: 1em 0;
}
h1 {
display: block;
font-size: 2em;
font-weight: bold;
margin: 0 0.67em 0;
}
h2 {
display: block;
font-size: 1.5em;
font-weight: bold;
margin: 0 0.83em 0;
}
h3 {
display: block;
font-size: 1.17em;
font-weight: bold;
margin: 0 1em 0;
}

Pour Firefox, Opera, Chrome et Safari, les définitions par défaut ne diffèrent que pour les marges des 2 derniers navigateurs et sont assimilables à celles d’Internet Explorer pour les versions 8 et 9. 

Note : les définitions spécifiques au Quirks mode déclarées par défaut pour Chrome et Safari ne sont pas prises en considération.


Si votre site utilise des affichages évolués, ou que vous souhaitez une maîtrise "absolue" de l’affichage, la normalisation CSS semble alors plus appropriée que les techniques de reset CSS. Vous pouvez par exemple utiliser normalize.css qui pallie, de manière optimisée, les écarts entre navigateurs.

Un autre aspect apparemment anodin concerne la page HTML codée, dans laquelle un développeur sérieux va placer des indentations, retours de lignes et commentaires. Par exemple, une indentation peut-être réalisée avec une tabulation (1 octet) ou 4 espaces consécutifs (4 octets). L’écart unitaire de 3 octets peut sembler insignifiant, mais qu’en est-il sur une page de plusieurs centaines de lignes ? Ajoutons à cela les espaces laissés en fin de ligne, la surabondance de sauts de lignes utilisés pour aérer le code et les nombreux commentaires… Nous pouvons ainsi facilement récupérer des centaines, voire plusieurs kilos octets sur une page, sans aucune conséquence négative pour l’internaute ni perte de la lisibilité nécessaire à la maintenance.

Pour réaliser cette optimisation, il me parait utile, comme pour les fichiers JavaScript et CSS de maintenir deux versions, l’une dédiée au développement, l’autre rationalisée pour la production avec des outils comme HTML Compressor, Text Fixer ou Absolute HTML Compressor si vous préférez un outil installé sur votre poste de travail.

Avec ces nouveaux éléments dévoilés, vous continuerez à améliorer la vitesse de chargement de vos pages, tout en tenant compte d’impératifs souvent contraires entre les environnements de production et les besoins de maintenance.

Votre plan d’actions peut, sans difficulté, être construire en utilisant les têtes de chapitre comme points de repères fiables.

Les gains obtenus seront, en proportion, fort probablement inférieurs à ceux liés à l’optimisation des images (traité dans un précédent article), mais n’oublions pas notre leitmotiv : à chaque seconde de chargement supplémentaire, c’est 10 internautes qui fuient !

Dans un article à suivre (très rapidement), j’évoquerai un nouvel aspect de l’optimisation du temps de chargement des pages d’un site web, sous l’angle des serveurs qui délivrent le contenu.

 

Conclusion

Avec l’ensemble des articles publiés, vous détenez maintenant les clés essentielles de l’optimisation du poids des pages de votre site web.  En appliquant et en adaptant de manière pertinente toutes les pistes évoquées, vous devriez être surpris voir étonné des gains accumulés.

Tout est fini, nous pouvons nous dire au revoir ? Pas tout à fait. Un dernier aspect reste à évoquer ! Alors, à très bientôt pour découvrir ce qu’il est encore possible de faire en manipulant quelques paramètres du côté du serveur web.

Autour du même sujet