Performance web » Building High Performance HTML Pages

Mode de rendu des tableaux

Éric — Mon, 29 Sep 2008 10:00:24 +0000

Pour ceux qui doutes Microsoft en parle dans son article sur les performances, mais ce point là est généralement bien accepté car la différence de performance est parfois flagrante. Sitepoint en parle aussi d’ailleurs : Le mode de rendu des tableaux impacte les performances.

Rendu fixe ou dynamique

Les tableaux HTML ont deux modes de rendu. Le premier mode utilise un calcul simple pour déterminer la taille horizontale des différentes cellules. On regarde la taille appliquée à la colonne, ou éventuellement à la première cellule de la colonne. Les cellules fusionnées ou sans taille explicite se répartissent à égalité la place restante. On parle d’un cadre fixe.

Le second mode rendu utilise un algorithme bien plus complexe. Il utilise le contenu de chaque cellule pour décider quelle taille elle prendra. On prend en compte la quantité de contenu, la taille souhaitable pour la cellule, et la taille minimum. L’algorithme est complexe, il nécessite de travailler sur des parties complexes du rendu de chaque cellule, il nécessite de recalculer le rendu complet du tableau dès qu’un contenu change dans une cellule ou au fur et à mesure que le HTML est téléchargé. On parle là d’un cadre automatique, ou dynamique.

Les performances

Vous vous doutez bien que le navigateur ne fait pas le même travail dans les deux cas, et pas avec les mêmes performances. Malheureusement c’est ce second mode de rendu, le dynamique, qui est utilisé par défaut. Utilisez la directive CSS table-layout:fixed et d’un coup votre navigateur sera soulagé.

Vous ne verrez pas la différence pour un petit tableau de chiffres mais si vous utilisez les tableaux pour déterminer l’agencement général de la page, si vous imbriquez des tableaux les uns dans les autres, si vous utilisez de très grands tableaux de données avec des centaines de lignes et colonnes, ou si vous utilisez du contenu complexe dynamique dans vos cellules, vous sentirez peut être la différence de performance.

Erreurs de syntaxe

Éric — Fri, 26 Sep 2008 10:00:02 +0000

J’ai beaucoup parlé de CSS, de réseau, de javascript, et j’entend parfois dire que le HTML lui n’a aucune importance. Ce n’est malheureusement pas vrai. Il y a au moins trois points à regarder dans le HTML : la qualité syntaxique du code, le mode de rendu des tableaux, et le nombre de noeuds DOM.

Je vous détaille le premier ici, les deux autres bénéficieront d’un billet dédié afin de mieux organiser les commentaires.

La syntaxe HTML

On vous dira par endroits que faire du code valide, suivant la norme HTML strictement, permettra d’améliorer les performances, d’améliorer votre référencement, et de faire le café. Ce n’est pas tout à fait vrai, mais un peu quand même (sauf pour le café).

Si vous avez des erreurs de syntaxe à répétition dans votre code, le navigateur va tenter de vous corriger. Suivant les cas il est possible qu’il arrête son rendu progressif et attende la fin du document pour savoir quelle correction appliquer et calculer l’ensemble de la page. Il est aussi possible qu’il tente une correction puis change d’avis quand il reçoit le reste du HTML, provoquant un recalcul du rendu. Dans les deux cas vous avez des problèmes de performance.

C’est d’ailleurs vrai même entre deux pages HTML bien formées : bien que facultatif, fermer toutes vos balises explicitement peut aider le navigateur à faire son travail plus facilement. C’est au point que Microsoft met ça en septième position dans son article Building High Performance HTML Pages (réaliser des pages HTML hautes performances).

Normalisez vos liens

Éric — Tue, 02 Sep 2008 10:00:35 +0000

Je viens de croiser une liste de recommandations Microsoft pour la performance des sites web. On y retrouve plusieurs choses connues et une recommandation sur la cohérence des liens. La page MSDN donne l’exemple d’un même lien avec deux casses différentes. Certains serveurs ignoreront la casse ou corrigeront le lien mais cela restera deux ressources différentes sur le client, avec des entrées séparées sur le cache, donc au moins une requête HTTP inutile.

Dans la réalité la plupart des serveurs web tournent avec un dérivé d’Unix où la casse est importante. Nous aurons un lien cassé et rien de plus. Par contre la recommandation, elle, est plus que pertinente :

Hésitez entre http://example.org/ et http://example.org/index.html, votre navigateur utilisera deux ressources et deux entrées de cache séparées. Au revoir les requêtes conditionnelles HTTP pour économiser le transit réseau.

Insérez des paramètres inutiles ou changeant dans vos liens avec ?exemple=1 et vous voilà avec encore une ressource différente pour le navigateur alors que ça pointe au même endroit.

Hésitez entre http://example.org/rep/ et http://example.org/rep et c’est encore pire. Non seulement ce sont deux ressources différentes pour le client, mais pour le serveur aussi. Ce dernier va opérer une redirection HTTP complète, et vous allez faire deux requêtes HTTP là où une seule aurait suffit (c’est géré par la directive DirectorySlash pour Apache par exemple). Si vous pointez vers un répertoire ou à la racine d’un site, votre adresse doit toujours se terminer par /.

Pour une même ressource, assurez vous que vous utilisez toujours exactement la même adresse, sans variations.