Je poursuis la lecture des vidéos et des présentations des conférences Velocity de juin dernier.
Au delà de Gzip
La première chose à activer sur les serveurs c’est gzip. Il s’agit de compresser tous les contenus texte en provenance du serveur avant de les faire transiter par le réseau. Si vous ne l’avez pas fait, activez gzip sur votre serveur web ! Tony Gentilcore nous parle de 70% de gain en volume de téléchargement. De mon expérience ça donne un peu plus mais même à 70 % c’est indispensable.
Là où Tony amène une information nouvelle, c’est que 15 % des clients ne déclarent pas supporter gzip, hors robots. Il blâme les mauvais proxys et les outils de sécurité privés comme Norton Internet Security, Zone Alarm, McAfee Internet Security, etc. Ces outils sont généralement des plaies, et pas que côté performance, et voilà qu’ils s’autorisent à modifier les entêtes HTTP envoyées par le navigateur. Bref, c’est 15 % des visiteurs qui auront une page non compressée et il va falloir trouver une solution.
Il propose donc de tenter de détecter le support gzip réel du navigateur via une iframe. Le contenu de l’iframe est envoyé zippé, quoi que déclare le navigateur. Si le navigateur décode le contenu, on lui pose un cookie pour retenir qu’il faut lui envoyer le contenu zippé malgré l’absence de l’entête HTTP appropriée.
J’aime bien l’idée de l’autodétection mais attention à ne la mettre en oeuvre que pour ces 15 % de clients mal configurés. Hors de question d’imposer une iframe aux autres.
Ajax à Facebook
La seconde présentation dont je voulais vous parler c’est celle de Facebook. Malheureusement, après avoir tenté plusieurs angles d’approche, je me rend compte que je suis incapable de vous en faire un résumé. Le plus simple est donc de vous laisser aller voir les fichiers ou la vidéo de la présentation. Ils présentent leur démarche pour améliorer les performances, et plus spécifiquement comment ils sont passés à un modèle pur Ajax pour la navigation (le conteneur HTML reste, le contenu est chargé via Ajax).
Je fais l’impasse sur la moitié de la présentation qui fait état de leurs outils de surveillance pour passer à la fin. On y trouve quelques graphiques qui montrent le nombre de pages vues suivant les performances obtenues. Comme Steve Souders le disait dans son résumé, ceux qui ont les moins bonnes performances sont aussi ceux qui visitent le moins de pages.
Comme on me l’a signalé il y a peu (merci Rik), il est possible que leur méthodologie soit aussi en cause (moins on visite de pages, plus la première page, cache vide, aura d’influence dans le calcul et moins bon sera le temps de chargement moyen, la courbe cumule alors un biais du à la mesure en plus de l’effet qu’on cherche à mesurer) mais il est tout de même intéressant de voir que le profil de chaque site est différent. Certains semblent plus dépendants des performances que d’autres.
Un peu de CDN
C’est ensuite Mike Brittain qui nous parle de CDN. Rien de bien nouveau à première vue mais le fichier de la présentation manque cruellement d’une bande sonore ou d’une vidéo, il y a peut être eu bien plus de choses intéressantes à l’oral.
Pour ceux qui n’ont pas travaillé avec un CDN vous y retrouverez tout de même un ou deux schémas explicatifs, et en particulier sur la notion de serveur d’origine pour un CDN (si le CDN n’a pas une ressource, il va la chercher sur vos propres serveurs pour la mettre en cache de son côté par la suite).
La dernière partie aurait elle aussi fortement bénéficiée d’un enregistrement sonore. On y parle de quelque chose qui est très efficace mais difficile à mettre en oeuvre : un squelette de page générique qu’on peut mettre en cache voire servir depuis le CDN et qui reçoit toutes les personnalisations et informations temps réel via des requêtes utilisateurs en javascript. Si vous avez des pages d’accueil lourdes que vous souhaitez mettre en cache, c’est la solution à tester (mais ça demande beaucoup de boulot).
Et du reflow
On va enchaîner avec Lindsey Simon, qui parle de reflow. Nous avons abordé la chose plusieurs fois ici mais je vous recommande de jeter un oeil à la présentation qui est un bon résumé. Il identifie comme problèmes majeurs impactant lors des reflow : le nombre d’éléments, la profondeur de l’arbre DOM, le nombre de sélecteurs CSS, la complexité des sélecteurs CSS, et le type de changement opéré (display block, visibilitiy hidden, etc.)
On y retrouve aussi la recommandation de faire les manipulations DOM lourdes hors de l’arbre général (fragment dom), hors du rendu (display none), hors du flux (position absolue), ou au moins en une fois en changeant les classes HTML plutôt que les attributs de style. On limite alors l’impact et le besoin d’un recalcul de toute la page.
Encore de la pub
Une des présentations que j’attendais c’est celle sur la performance des publicités. La présentation, conjointe avec plein de gens biens, est finalement décevante. On y explique très bien les problèmes, mais il manque les solutions. Il faut avouer que c’était un peu présenté comme un panel d’expert donc l’intéressant est à l’oral. On trouve juste deux liens sur des recommandations de bonnes pratiques. Ça peut toutefois être bien utile pour donner au moins un guide à vos agences de pub (si vous êtes en position d’imposer quelque chose, ce qui est rarement le cas). Par contre au moins ici il y a un enregistrement vidéo.
Gzip
Il ne faut pas oublier que le temps gagné sur le transfert avec gzip est compensé par le temps de compression coté serveur et décompression coté client.
Je pense qu’en fonction de l’application, ca peut être variable au final.
J’ai tendance à penser qu’il faudrait compresser les pages, mais pour les appels ajax je les laisserai en non compressé pour plus de réactivé personnelement (surtout si ce sont des requetes ajax très légère)
Après je ne sais pas si on peut fixer une limite de taille. Par exemple compresser tous les fichiers d’une taille supérieur à 100ko
Pour mod_gzip on peut fixer des tailles minimum et maximum. On met généralement le minimum en dessous de 1ko.
Le temps de zip sur le serveur et de dezip sur le client est généralement considéré comme quasi nul par rapport au traffic réseau. Il ne s’agit pas d’employer un dictionnaire de compression extraordinaire, un niveau de compression même assez faible réduira fortement des fichiers de type html/css/js sans impacter le cpu. Même pour les requêtes Ajax, il serait étonnant que ce temps soit significatif par rapport à la simple latence réseau dont tu vas souffrir.
Euh, c’est quoi ce conseil merdique de faire du javascript pour servir des pages selon l’utilisateur ??? La performance, oui. Au détriment de la qualité du web, non.
La navigation Ajax façon Facebook c’est la même chose. Ça peut être un bon conseil si on prévoit la version sans Javascript.
Tout est une question de mesure et de contexte Rik.
Là dans la présentation de Mike Brittain il marque bien ce qui est sur le CDN en statique et ce qui nécessite javascript. Pour la dernière catégorie on identifie plusieurs points :
– Les pubs et l’invite indiquant qu’on est connecté. Franchement ce n’est pas trop grave. La pulicité demandera de toutes façons js et l’invite de connexion, tant qu’elle fonctionne ce n’est pas forcément trop grave si l’affichage n’est pas là quand js est asbent. (tant qu’il reste un lien pour aller vers la page d’identification)
– Les « fresh data » : js permet d’avoir la version à jour quand j’utilise mes actions persos, sinon j’ai la version générique avec un cache, donc éventuellement des données de rating un peu vieilles. Est-ce vraiment grave ?
– Les actions utilisateurs, la version js sait probablement quelle est la note que j’ai déjà donné à la vidéo, si j’ai aimé ou détesté. Pour les autres on a le formulaire qui permet d’envoyer les infos mais pas forcément de retour sur ce qui a déjà été fait. C’est dommage mais pas dramatique.
Bref, il faut voir ce qui a été fait, comment, ce qu’on peut faire avec et ce qu’on peut faire sans. La démarche est intéressante, savoir s’ils ont fait les choses « bien » ou s’ils ont sabré la version sans js pour en faire quelque chose d’inutile, ça je ne sais pas. Le warning est utile, mais ne jetons pas le bébé avec l’eau du bain.
Pour facebook même chose. Je n’ai pas de compte, je n’en ai jamais eu, du coup je ne sais pas ce qu’ils avaient avant, si le modèle ajax a du sens ou pas, s’il y a des fallack sans js ou pas, etc. Je m’arrête à la démarche, après faire les compromis entre qualité, performance et cout, je ne peux pas les faire pour vous et les exemples sont rarement adaptables à autre chose qu’à leur cas particulier. Bref, il s’agit de montrer les démarche et les outils, savoir où et quand les utiliser, c’est à toi de décider en fonction de ton contexte.
Pas d’accord. La transmission de cette information doit se faire avec les précautions de rigueur. Rien dans les présentations ou ton compte rendu ne prévient que ces techniques sont à prendre avec des pincettes (pour moi les pincettes servent à ne pas toucher à ce déchet).
Facebook se retrouve avec toutes les CSS ajoutées au fur et à mesure et est obligé de namespacer. Je veux pas étudier la conso mémoire de malade que ça doit faire. Plutôt que de passer son temps à trouver des techniques pour contourner, ils feraient mieux de soigner à la base.
Pour le fallback Javascript, il y a encore peu, Facebook filait une belle page blanche. Cela a jamais d’après mon rapide test du jour, mais je n’ai pas testé plus qu’un affichage.
Enfin voilà, ces deux techniques, c’est vraiment pas pour généraliser, mais plutôt avec parcimonie.