Lorsque vous lancez un nouveau site, vous pouvez estimer son potentiel via divers outils. Une fois construit, vous pouvez améliorer sa visibilité pour attirer de nouveaux visiteurs. Après, le succès réside dans le nombre de lecteurs fidèles et non pas dans les visites éphémères, où l'utilisateur repart aussi vite qu'il est arrivé. Beaucoup d'éléments rentrent en compte pour parvenir à cette fidélité et l'un d'entre eux est toujours d'actualité : Le temps de réponse de vos pages.

Bien entendu, nous pourrions traiter en premier lieu de la disponibilité d'un site car tomber sur un serveur qui ne répond plus est beaucoup perturbant que d'observer une légère impression de ralentissement. Cependant, nous tombons là dans des problématiques, qui se résolvent via des investissements dans des serveurs doublés ou des technologies musclées pour obtenir une haute disponibilité. Cela requiert des moyens que même une petite entreprise ne peut pas toujours se permettre.

Non, le sujet abordé reste le simple chargement des pages. La remarque peut prêter à sourire dans l'internet actuel où l'ADSL et les fibres optiques ont relayé la quasi-totalité des  modems 56K au placard. Là, où vous faisiez attention à éviter une image de fond, vous vous lâchez maintenant en proposant de la vidéo et des flux audio, quand ce n'est pas une animation Flash, maintenant que le support est largement diffusé et lisible chez les utilisateurs.

Et pourtant, vous devriez encore vous méfiez du comportement des utilisateurs. Alors qu'avec un 56k, il était admis qu'une page commence à être longue à charger au bout de cinq secondes, les codes se sont durcis considérablement dans l'univers des autoroutes de l'information. Dès que vous dépassez la seconde pour charger une page, vous avez l'impression d'attendre et même si le chargement ne dure qu'un dixième de seconde, vous le sentirez encore. Obtenir un résultat en dessous de ces cent millisecondes est une gageuse quand vous savez que le réseau à un temps de latence normal de quelques dizaines de millisecondes pour atteindre des serveurs distants.

Ceux qui se sont mis à concevoir des sites dynamiques à coups de PHP ou de système de gestion de contenu clef en main, ont pu constater que les performances sont difficiles à tenir à terme, quand le contenu et le nombre de lecteurs augmente. La faute à la génération à la volée des pages avec moult interrogations d'une base de données. A moins d'avoir une bête de course,  le serveur met quelques temps à mouliner et sert la page moins vite qu'un moteur web qui ne crache que des pages statiques.

Là, la parade consiste à optimiser son code et à jouer habillement des options de cache disponibles suivant les systèmes. Une fois vos solutions élégantes mises en place pour écourter la génération, vous pensez sans doute avoir fait le maximum. Erreur et même pire : Les spécialistes de chez Yahoo, très portés sur ce sujet, nous avancent que le temps de construction des pages ne contribuent qu'à 20% du temps d'attente et que les 80% restant résultent de l'affichage de la page créée, donc du transfert du résultat vers le navigateur.

La remarque surprend car vous avez plutôt tendance à remarquer que votre site rame quand la base est surchargée et que le serveur n'arrive pas à suivre. Pourtant lorsque tout va bien et que les temps de réponse sont en dessous de la seconde, vos performances sont peut être deux fois moindre qu'elles ne devraient l'être, si vous vous en étiez souciés.

La littérature sur le web vous présente de nombreuses règles, qui sont plus ou moins empiriques, à l'image des recettes pour bien référencer son site. Non seulement, certaines écoles s'affrontent quant à certains points mais en plus, les situations diffèrent suivant les sites. Une règle peut être intelligente à suivre dans 90% des cas mais votre page peut se trouver dans les 10% restant, où il ne faut surtout pas l'appliquer.

Une partie des recommandations concerne le paramétrage de serveur avec des caches ou des modules de compression à activer, pour ne citer que les items les plus simples à manipuler au niveau du serveur. D'autres conseils insistent sur l'envoi de l'en-tête des pages avant d'avoir fini de les générer complètement. Tout ceci peut vous dépassez mais retenez que la plupart des conseils sont beaucoup plus simples à mettre en oeuvre et ne concernent que le code de la page web elle-même.

Sachez en plus que des outils existent pour analyser le temps de chargement d'une page, en distinguant le cas d'un fichier qui est chargé la première fois du cas où les images sont déjà en cache par exemple. Citons parmi eux, Yslow, toujours porté par la fameuse équipe de spécialistes chez Yahoo. Yslow a la forme d'un prolongement d'extension sur le navigateur Firefox. Il donne une note quant aux principales règles énumérées et il déduit quelques statistiques dont un graphique des temps de chargement des différents éléments de la page.

Prenons le cas de la page d'accueil d'Animint, avec l'apparence actuelle mais sans optimisation particulière. Première alerte, les appels aux javascripts sont en haut de la page. Normal, étant donnés qu'ils étaient dans l'ent-tête et que point de vue codage, cela me parait toujours plus propre de les placer ici sans avoir à rajouter des codes d'exclusion pour ruser avec le format XHTML strict.

Cependant, pour éviter des conflits potentiels au moment de l'interprétation, un navigateur se concentre pour télécharger séquentiellement les scripts, voir pire, il peut bloquer le chargement en parallèle des autres éléments.  Ainsi pendant que le long appel à Google Analytic se fait, les images ne se chargent pas et l'utilisateur attend.

Placer les scripts à la fin du code, les font se charger en dernier et toute la page a le temps d'apparaître avant qu'ils ne s'exécutent. Le bémol est qu'il n'est pas toujours possible de déplacer tous ses scripts en bas et dans le cas d'un outil de statistiques, si nous tombons sur un visiteur qui clique plus vite que son ombre, sa visite peut ne pas être comptée car le script n'a pas le temps d'enregistrer la visite avant que l'utilisateur s'en aille.

Autre point à mentionner : Les images. N'étant pas un ayatollah de la page ultra light, je considère comme acceptable la taille des images de la page d‘accueil d'Animint, surtout dans notre monde moderne fait d'ADSL et de fibres optiques. Elles représentent un peu plus de cent kilos octets en comptant les images de fond utilisées dans les feuilles de style, qui permettent d'avoir les cadres arrondis jaune, vert ou bleu, ou encore la barre de navigation avec les visages de personnages d'anime.

Là, où le bat blesse, c'est le nombre total d'images en lui-même, des images dont la plupart sont justement appelés par les fichiers CSS. A chaque chargement, il faut plus d'une quarantaine d'aller retours avec le serveur pour appeler ci et là, une image ou un autre type de fichier et ceux, rien que pour la page d'accueil.

Le fait que les images soient mises en cache par défaut dans le navigateur ne change rien car faute d'indication sur le temps d'expiration des éléments, le navigateur demande quand même au serveur si elles ont bougé. Une grosse partie de ces requêtes s'effectue en parallèle mais il y a une limitation au nombre de requêtes possibles en même temps, qui fait qu'elles se suivent par lot, et forcément cela allonge le temps de chargement.

Le moyen pour optimiser ce point est ultra classique et consiste à regrouper les diverses icônes dans une seule image – appelée sprite dans ce cas -, qui est chargée une seule fois puis montrée par portion suivant l'icône que nous souhaitons faire apparaître. Ainsi, les divers bords des cadres sont concentrés dans une seule image et au gré des éléments de la feuille de style, je fais apparaître une portion limitée de l'image générale.

Là encore, il existe quelques petits bémols : Il faut savoir assembler ses icônes intelligemment pour ne pas aboutir à un énorme fichier dont le chargement serait plus long que des appels séparés aux images. L'utilisation d'un sprite complexifie ensuite la gestion des styles et j'ai d'ailleurs un problème pour faire afficher correctement les bords de cadres sous Internet Explorer, en faisant appel à cette méthode au sein de la feuille de style d'origine de la page d'accueil. Le recours au sprite a cependant l'avantage d'être compatible avec tous les navigateurs récents, en pratique.

Pour Animint, le nombre d'appels au serveur au niveau de la page d'accueil a été divisé par deux, rien qu'en regroupant quelques icônes et les bords de cadre, si nous considérons le cas d'un visiteur qui n'est jamais venu avant.  La méthode d'optimisation est triviale si vous faites souvent appel aux images de background dans vos feuilles de style.