Petit-déj Globalis à propos de l’optimisation FrontEnd

Jeudi dernier la société Globalis organisait un petit déjeuner intitulé “Contexte et enjeux de l’optimisation FrontEnd” auquel j’ai participé.

L’optimisation FrontEnd est ici comprise essentiellement comme un moyen d’accélérer la vitesse de chargement d’une page Web, d’un point de vue technique (temps de chargement global), mais aussi du point de vue de la vitesse ressentie par l’utilisateur (attente avant début d’affichage des premiers éléments par exemple).

Je vous propose un petit résumé de cette conférence agrémenté de quelques remarques personnelles.

Les gens de Globalis ont eu la sympathie de m’envoyer le fichier PDF de leur présentation et m’ont autorisé à le publier sur ce blog : Présentation Globalis : Contexte et enjeux de l’optimisation FrontEnd

Présentation du contexte

La société Globalis :

• 13 ans d’expérience
• Spécialiste PHP
• 25 experts
• Créateur de PHPIndex

Pourquoi optimiser la vitesse des pages ?

• Améliorer l’agrément et la qualité perçus par l’utilisateur
• Le temps d’affichage des pages est pris en compte par Google pour le référencement
• L’aspect Green IT

Remarque : c’est bien la première fois que j’entend parler du Green IT comme argument pour optimiser la vitesse d’affichage des pages. Perso, je pense qu’on est très très loin de voir des entreprises se soucier de l’environnement dans la mise en œuvre d’un site Web !

Remarque 2 : JP vient de me faire remarquer un article de Search Engine Land qui confirme et détail la prise en compte de la vitesse des pages dans le rankink de Google. Vous pouvez aussi voir la déclaration officielle sur le blog de Google.

Où l’effort doit-il porter ?

• Si les pages d’un site ne s’affichent pas assez vite, il est tentant pour certains décideurs de se contenter de “mettre de plus gros serveurs”. Plus concrètement, essayer d’optimiser les ressources hardware qui, par nature, sont très facilement interchangeables.
• Concrètement ce n’est pas forcément la meilleure solution pour un site. Surtout que les problèmes de lenteur proviennent plus souvent aujourd’hui du client (ordinateur, connexion et navigateur de l’internaute) que du serveur (le serveur n’envoi pas immédiatement les données car ils prend du temps à les calculer ou à les récupérer dans une base…)
• Il est donc souvent plus efficace de revenir sur la conception d’un site que d’essayer de gagner quelques millisecondes sur le temps de réponse du serveur.

Remarque : je suis assez d’accord avec ce constat, même si ça n’empêche pas certaines applications Web d’être mal développées côté serveur et de répondre plus lentement qu’elle ne devraient (code qui n’optimise pas ses requêtes SQL par exemple). On ne parle pas non plus, bien entendu, des sites sous-dimensionnés (trop de visiteurs simultanés) victimes de leur succès…

Quelques chiffres éloquents

Les pages sont en moyenne 10 fois plus lourdes aujourd’hui qu’il y a 15 ans !

• 1995 : 25 ko / 5 ressources appelées dans la pages (images, feuilles de styles…)
• 2010 : 250 ko / 42 ressources

79% des internautes considèrent qu’une page est trop lente si elle prend plus de 2 secondes à charger.

Google Maps a amélioré sa vitesse d’affichage de 30% en passant de 100 ko à 70 ko.

On considère qu’on a un gain significatif à partir de 100ms. C’est le temps minimum de chargement de chaque requête faite par le navigateur, quelque soit le type et le poids de la ressource chargée ! Il est facile de comprendre alors que le premier conseil d’optimisation est de diminuer au maximum le nombre de requêtes…

Conseils d’optimisation

3 grands axes d’optimisations :

• Diminuer le nombre de requêtes
• Alléger le poids des ressources
• Améliorer la vitesse ressentie par l’utilisateur

Diminuer le nombre de requêtes

• Paramétrer le cache des ressources statiques pour qu’elle ne soit pas rechargées par le navigateur inutilement
• Utiliser la technique des sprites en CSS pour factoriser les images
• Packager les ressources => regrouper les fichiers CSS en un et les fichiers JS en un. Il y a des outils pour automatiser ça

Alléger le poids des ressources

• Utiliser la compression GZip (via un module Apache ou un paramétrage PHP) peut réduire jusqu’à 80% la taille d’une ressource statique
• Utiliser le format adapté pour les images (plutôt JPG pour les photos, PNG pour les graphismes avec des aplats…)
• Packager les ressources => les outils de packging permettent aussi de “minifier” (ou compacter) les fichiers pour en réduire la taille (la librairie javascript jQuery passe de 155 ko à 25 ko en version packagée…)
• Diminuer la taille des cookies (je suis très dubitatif là-dessus)
• Eviter d’utiliser des cookies pour les ressources statiques (une solution pour cela est d’utiliser un sous-domaine spécifique qui n’utilise pas de cookies pour appeler ces ressources)

Améliorer la vitesse ressentie par l’utilisateur

En gros, ça revient à démarrer l’affichage de la page le plus vite possible.

• Afficher la page dès le début du parsing HTML (peut de gens s’en souviennent, mais c’était une des raisons “pratiques” de ne pas utiliser les tableaux HTML pour la mise en forme d’une page, car certains navigateurs n’affichent pas un tableau tant que son contenu n’a pas été chargé complètement…)
• Charger les scripts en bas de page (au lieu de la balise head…) (perso je ne trouve pas ça très propre et je préfère les solutions telle que l’injection DOM qui permettent de paralléliser les chargement JS sans affecter celui de la page)
• Ne pas utiliser de “filtres” tels que les fichiers HTC pour Internet Explorer (ils en existe pour gérer les PGN avec couche de transparence alpha par exemple), car ils ralentissent beaucoup l’interface (ils sont notamment recalculés lors d’un simple scroll…)
• Précharger les ressources quand c’est possible (la page d’accueil Google contient par exemple une image utilisée avec la technique des sprites pour des éléments graphiques qui ne sont utilisés que dans les pages de résultats)
• Technique de “post-load” (j’ai pas trop creusé le sujet, il a des plugins pour ça…)
• Paralléliser les téléchargement (notamment pour les images, IE6 par exemple ne sait charger que 2 images à la fois sur un même domaine. Une solution complexe à mettre en œuvre consiste à utiliser 2 ou 3 sous domaines différents pour les images…)

Conclusion

Les deux “experts” qui ont fait l’essentiel de la présentation lors du petit déjeuner semblaient assez jeunes (ce qui n’est pas un défaut en soit ! :p) et étaient très enthousiastes vis à vis de ces techniques d’optimisation…

Ils avaient bien raison, car dans le fond leur propos est juste et le panel de techniques d’optimisation évoqué semble correspondre à l’état l’art aujourd’hui.

Néanmoins je relève qu’ils ont très peut parlé des problèmes de mise en œuvre de ces techniques dans des contextes réel.

Grossièrement, pour avoir une bonne checklist de toutes ces techniques, il suffit d’utiliser le plugin YSlow de Yahoo! (se prononce “Why slow ?”). Il s’agit d’un plugin pour Firebug qui est lui-même un plugin Firefox (véritable “must have” pour les Webdesigner). YSlow analyse la page et lui donne une note basée sur la prise en compte des techniques d’optimisation Frontend recommandés par Yahoo. Ces techniques recoupent en majeur parties celles évoquées lors du petit déjeuner de Globalis.

Le problème aujourd’hui n’est donc pas tellement de savoir quoi optimiser, mais plutôt de savoir le faire efficacement et dans la durée.

Je pense que j’ai pas mal soulé nos hôtes ce matin là en insistant beaucoup par exemple sur la technique des sprites CSS qui est effectivement idéal pour un site dont les images ne bougent pas trop, mais ça devient une autre paire de manche de l’utiliser sur un site mis à jour fréquemment… J’ai eu l’expérience par exemple d’un site où toutes les images au départ étaient des sprites, mais par la suite on s’est mis a ajouter des images petit à petit (un bouton par ci, un visuel par là…). Et comme le travail se fait souvent dans l’urgence, on n’a pas toujours pris la peine d’incorporer la nouvelle image (ou l’image mise à jour) dans la composition de sprite globale. On tend donc à perdre les bonnes habitudes et, en l’occurrence, à augmenter petit à petit le nombre de requêtes par page…

J’en retiens donc qu’il faut bien se pencher sur les techniques automatisables (comme le packaging des fichiers), mais qu’on manque un peu de maturité pour les autres techniques, comme les sprites ou le chargement des images via des sous-domaines distincts.

Et vous ? Utilisez-vous des techniques d’optimisation Frontend ? Si oui lesquelles ? Rencontrez-vous des difficultés ? Connaissez-vous d’autres techniques ?

N’hésitez pas à participer avec vos commentaires ! ;-)