Je me décide à passer un coup de peinture sur ce blog quasiment 2 ans après le CSS Summer Refresh organisé par Alsacréations. À vrai dire, j’avais ce projet dans les cartons depuis septembre 2008 mais le plus difficile a été de trouver le talent graphique. C’était également l’occasion de dire au revoir aux navigateurs Web de seconde zone, à savoir Internet Explorer 7 et moins.

Le besoin

Mon besoin était le suivant :

• Thème graphique
  • durable et peu lassant
  • usage de transparence
  • toujours sur des tons marrons
  • inspire la modernité tout comme le côté rustique et soucieux de la nature
  • structure en grille pour intégrer avec Blueprint
• Fonctionnalités
  • intégration d’un lifestream (intégré entre temps)
  • intégration de Feedburner via son API Awareness
  • intégration d’un bandeau Flickr qui s’étend sur toute la largeur de l’écran, peu importe la résolution employée
  • utilisation du blog comme vitrine : suppression de ma dernière page HTML manuelle (autrefois accessible sur oncle-tom.net)
• Compatibilité
  • navigateurs modernes … c’est à dire rien en dessous d’Internet Explorer 8
  • intégration avec HTML 5
  • pas d’utilisation de GIF mais de PNG 6 et PNG 24
• Autre
  • soucis de performance (peu d’éléments graphiques, utilisation des sprites)

Finalement c’est Lesly qui s’est chargé de la création graphique. Vous pouvez d’ailleurs consulter la maquette graphique originale sur son portfolio. Quant à moi, j’ai réalisé toute l’intégration CSS/HTML dans WordPress.

L’intégration

Tout d’abord, qu’est ce qui a changé par rapport à la maquette ?

• les polices de caractère : hormis le titre, seules des polices standards ont été employées. J’attendrai le support des polices personnalisées en CSS 3 à moins de partir sur une solution à base de SVG (encore que j’ai des doutes sur l’accessibilité d’une telle méthode) ;
• moins d’éléments graphiques : les punaises, les effets papiers ont été supprimés. Rien que le papier et le scotch de la partie « À propos » pesaient plus de 60Ko ;
• abandon temporaire du featured content : les solutions actuelles étaient trop lourdes et j’étais trop impatient pour passer quelques heures de plus … donc c’est temporaire
• l’ajout des pages en lieu et place du fil d’ariane : j’en avais besoin pour présenter différents contenus statiques ;
• le pied de page : peu de widgets WordPress offrent un degré de personnalisation suffisant pour arriver à ce résultat. C’est donc temporisé là aussi en attendant de trouver chaussure à mon pied

Aperçu pleine page

Pour le reste je me suis fait plaisir avec notamment l’utilisation de coins arrondis (border-radius) basés sur les implémentations de Gecko et Webkit. Désolé pour les utilisateurs d’autres navigateurs car j’en ai usé et abusé afin d’éviter l’utilisation d’images.

J’ai également joué avec l’API de WordPress pour générer les vignettes des articles. Je sais bien qu’on peut définir des tailles d’images mais ça ne vaut que pour les médias nouvellement mis en ligne. J’en ai profité pour n’afficher dans le listing que l’extrait du billet. Pas l’intro, seulement l’extrait (excerpt). J’ai lu récemment un article qui parlait de la chose et ça m’a paru plus approprié. Je peux désormais écrire le texte qui me convient pour attirer la lecture vers un article sans pour autant que ça ait de répercution sur son contenu une fois affiché en pleine page.

Je suis en revanche toujours dubitatif sur l’API de WP Cron : ma tâche a beau être enregistrée et planifiée, j’ai l’impression qu’elle ne s’exécute jamais … contrairement aux recherches de mises à jour de plugins & cie. Quelqu’un a déjà joué avec et rencontré pareil problème ?
Mise à jour : j’ai résolu le problème et détaillé la marche à suivre dans l’article affichage personnalisé de ses lecteurs Feedburner. Je planifiais une fonction et non un hook. Cela fonctionnait mais ne produisait fatalement pas de résultat

Au final je n’ai même pas eu à placer la moindre ligne de JavaScript : tout est fait à partir de sélecteurs CSS. Mon seul regret : l’absence de sélecteur adjacent … « précédent ». Pour le menu du haut, je voulais pouvoir styler les éléments de menus ayant comme élément suivant une liste d’élément (<ul>).

Au final

J’ai mis à peu près 2 jours pour tout intégrer et optimiser. Je n’ai pas encore tenté l’optimisation à coup de PNG 8 grâce aux quelques Ko gagnés avec pngcrush. Il faudrait également que je réunisse quelques images dans un seul et même sprite pour gagner encore quelques dizièmes de seconde en temps de chargement.

Rapport YSlow

J’en ai profité pour tester l’utilisation de mod_expires et mod_gzip chez OVH en mutualisé (avant de tout migrer sur serveur dédié) : ça marche plutôt très bien. Si ça vous intéresse, je peux en faire un billet dédié. D’ici là, n’hésitez pas à bouquiner High Performances Web Sites qui reste une référence en la matière. J’attends d’ailleurs sa suite avec impatience : Even Faster Web Sites: Essential Knowledge for Frontend Engineers.

Quoiqu’il en soit, le fait d’avoir eu la pleine utilisation des sélecteurs CSS a été géniale : la vie est grandement facilitée. inline-block évite de nombreuses bidouilles à base de flottants. J’ai hâte qu’une version de Blueprint sorte en se basant uniquement sur les sélecteurs avancés et non des flottants pour disposer de mises en forme plus complexes tout en étant facile d’accès.

Si vous rencontrez des problèmes, surtout n’hésitez pas à les signaler, par le biais des commentaires ou par email

En attendant, je retourne sur mon projet éprouvant du moment !

High Performance Web Site, sous-titré Essential Knowledge for Frontend Engineers, est ce genre de livre à lire au moins une fois à défaut de le posséder. Il résume en à peu près 120 pages 14 points d’optimisation d’un site Web.

C’est d’autant plus intéressant que l’approche se base sur les mécanismes et non sur de l’optimisation de code. Ainsi dans la plupart des cas, vous n’aurez « que » du paramétrage serveur à faire.

Ce livre fait étrangement penser aux conseils de haute performance prodigués par le Yahoo! Developer Network et repris par l’extension Firefox pour Firebug, j’ai nommé YSlow.
C’est normal : ce livre est écrit par un ingénieur de Yahoo!, probablement un de ceux qui ont participé à la rédaction du guide de performances.

Pourquoi acheter High Performance Web Sites ?

On serait tenté de ne pas acheter le livre puisqu’une bonne partie de ses conseils sont repris sur le guide de haute performance cité plus haut.

Sachez toutefois que cet ouvrage va plus loin dans le détail, prend bien le temps de présenter ses tests de performance pour illustrer et de justifier l’application de leurs méthodes. La plupart des relevés de mesure sont effectués sur une dizaine de sites allant de Google à Amazon.

J’achèterais ce livre si j’étais :

• un administrateur système chargé d’héberger 1 ou plusieurs sites Web
• un technicien/webmaster en charge d’un site à plus ou moins fort trafic
• un développeur Web soucieux des performances de ses productions
• toute personne avare en kilo-octets superflus
• toute personne voulant accélérer les temps de réponse de son ou ses sites Web

Les 14 points d’optimisation

High Performance Web Sites axe son discours sur 14 points :

1. Limiter le nombre de requêtes HTTP
2. Utiliser un Content Delivery Network (CDN)
3. Utiliser une entête Expires
4. Compresser les composants avec Gzip ou Deflate
5. Placer les feuilles de style en début de page
6. Placer les scripts JavaScript en bas de page
7. Éviter les expressions CSS (Internet Explorer)
8. Placer les scripts JavaScript et les feuilles de style dans des fichiers externes
9. Réduire le nombre d’appels à des DNS différents
10. Minifier le JavaScript et les CSS
11. Éviter les redirections
12. Supprimer les doublons de scripts
13. Configurer ETags
14. Permettre la mise en cache des appels Ajax

Il prend cependant le soin de bien expliquer les mécanismes d’HTTP et les intérêts à améliorer les performances frontend.

Le livre termine sur un comparatif des 14 points sur 10 sites, notation YSLow comprise, dont Amazon, Google, CNN, eBay, Wikipédia et Yahoo!.

La mise en pratique

J’étais déjà sensibilité à presque tous les points pour avoir lu ces fameuses 14 règles en utilisant l’extension YSlow et Firebug. Cependant après la lecture du livre j’ai eu davantage de clés et des exemples probants pour me convaincre de les mettre en œuvre.

On peut appliquer la majorité des points et les points pertinents en 1 heure. En effet, tout site ne peut se permettre d’utiliser un CDN pour accélérer les temps de réponse autour du globe.

Personnellement j’ai mis en place une compression Gzip directement au niveau d’Apache au lieu d’utiliser une compression effectuée en PHP (avec Gzip aussi). J’ai couplé cet effort avec la minification JavaScript et la désactivation des ETags.

J’avais déjà au préalable externalisés mes CSS et JavaScript, placé au bon endroit (mais seulement les appels externes au DNS principal en bas de page) et sans doublon.

C’est bête à dire mais le résultat s’est vraiment senti avec des chargements de page incroyablement plus rapides. YSlow est effectivement un compagnon idéal pour la mise en application de ces éléments avec son analyse des performances et des composants.

Conclusion

J’ai dévoré High Performance Web Sites grâce à sa simplicité de rédaction, les nombreux exemples et surtout, les explications enrichissantes. Elles sont mises en application sur Yahoo! et certes, même si on peut se dire qu’on n’a pas de site de leur envergure, leurs conseils sont toujours bons à prendre.

High Performance Web Sites est un concentré de bonnes pratiques, simples à mettre en œuvre. Pourquoi s’en priver ?

Ces optimisations ne sont évidemment pas les seules à mettre en place pour que tout fonctionne bien : il faut aussi produire du code HTML propre, du JavaScript optimisé, du code application qui ne soit pas redondant.

C’est un bon début et des pratiques à généraliser.

Firebug fait partie de mes extensions préférées depuis un bon moment. Je l’estime aujourd’hui même plus importante que l’extension Web Developer, c’est dire.

J’ai pourtant constaté que la plupart de ses utilisateurs la sous-exploitait en se limitant à la console pour consulter les erreurs et éventuellement à l’inspecteur HTML pour remonter rapidement dans l’arborescence des balises en 1 clic. C’est bien mais pas assez.
Firebug est tout simplement énorme ! Suffisamment énorme pour gagner un temps incroyable dans le développement d’applications JavaScript et pour mieux comprendre les incohérences des CSS dans une page, entre autre.

Je vous offre aujourd’hui mon cadeau de Noël pour gagner en productivité et maîtriser cet outil ô combien indispensable.

Le plus amusant dans l’histoire c’est que le site officiel de Firebug dévoile (succinctement certes) tous les petits plus qui simplifient la vie. Je vais m’atteler à les éplucher en fonction des domaines d’utilisation :

1. pour le HTML et les CSS
2. pour le JavaScript
3. pour gagner en performances

Firebug pour le HTML

L’inspection HTML

J’apprécie l’inspection HTML car elle me permet de retrouver simplement le code lié au visuel. Après avoir activé l’inspecteur, je survole l’élément sur lequel je veux travailler, je clique dessus et le volet Firebug se fige dessus en m’indiquant toutes ses propriétés CSS, le modèle de boîte et ses propriétés DOM. On en reparle tout de suite après.
L’inverse est également possible. C’est à dire qu’en survolant le code, la correspondance visuelle dans la page est établie. C’est rudement pratique pour repérer des éléments qui sortent du flux. Ça l’est d’autant plus que les différentes marges (internes, externes, bordures) sont elles aussi mises en surbrillance.

Le gros atout de cet inspecteur c’est également l’édition à la volée de toutes les balises ! Idéal pour tester diverses classes d’un objet ayant un impact visuel fort sur son affichage. Cet outil présente un gain de temps énorme par rapport à la modification du code dans son éditeur et un petit coup de touche F5 dans la foulée.

Il faut également retenir que toute balise est sélectionnable en cliquant sur son nom (div, h3 etc.). Cela a a pour effet de mettre à jour le panneau latéral de Firebug. Panneau latéral qui est également fort utile.

L’inspection CSS, Layout et DOM

Le panneau latéral de l’inspecteur HTML se compose de 3 onglets, tous très utiles.

Inspecteur CSS

Les propriétés CSS affichées concernent uniquement l’objet actif et c’est ce qui en fait sa force. Ce panneau indique en effet la cascade CSS en cours ce qui permet de comprendre rapidement pourquoi sa feuille de style n’est pas appliquée comme il faudrait. Elle a la bonne idée de mentionner quelle feuille de style est utilisée et quelle ligne. De quoi corriger ça dans son éditeur favori rapidement.

Ou pas. En effet l’inspecteur CSS permet, tout comme l’inspecteur HTML, de modifier les propriétés à la volée et sans fioriture. Si je précise sans fioriture c’est parce que l’éditeur à la volée de Web Developer rend parfois l’affichage de la page bancale en décalant des éléments. Là vous pouvez totalement compter sur l’éditeur intégré et ce n’est pas un luxe !
Désactiver, supprimer, modifier ou ajouter des propriétés sont quelques-unes des actions que vous pourrez effectuer à même la page.

Là encore c’est une des parties où les gains de temps sont énormes. On peut en effet modifier ses CSS et les tester tout en observant l’impact immédiat de ses modifications.

Inspecteur du modèle de boîte (Layout)

Le modèle de boîte CSS peut vite devenir pénible à gérer et plus particulièrement quand on visualise mal le cumul des différentes marges.
Dans tous les cas c’est appréciable de pouvoir constater les marges en présence et encore, de pouvoir modifier leurs dimensions à la volée. Firebug a la bonne idée de colorer les marges intérieures (padding), extérieures (margin) et les bordures (border) d’une couleur différente.

Il a également la bonne idée d’afficher une double règle millimétrée au survol du panneau layout. Très pratique dans le cas de design en grilles ou nécessitant un certain rythme de visualisation.

Inspecteur DOM

Ah l’inspecteur DOM ! S’il n’existait pas il faudrait l’inventer. Firefox proposait déjà un tel outil à la différence près qu’il était moins pratique d’utilisation.
L’inspecteur DOM m’est moyennement utile dans le cas d’une simple inspection du code HTML bien que ce soit toujours pratique de visualiser la présence ou pas d’objets JavaScript dans tel ou tel élément. C’est fortement appréciable pour la librairie Prototype étant donné les dégâts causés par son extension du DOM à gogo.

Firebug pour le JavaScript

L’inspecteur JavaScript

C’est l’autre outil indispensable de Firebug. Avec lui, c’en est fini des alert(mavariable);. L’inspecteur DOM prend avec lui toute son utilité.

J’illustre sur l’image ci-dessus l’utilisation des points d’arrêt (breakpoints). Il suffit d’un clic à gauche d’un numéro de ligne pour en placer/retirer un. Concrètement quand l’exécution du JavaScript arrivera au premier point d’arrêt, elle va se stopper.
Quel intérêt ? Observer. En agissant ainsi, vous avez la main sur toutes les variables connues au sein de votre code/fonction. Très utile pour connaître les paramètres passées à la fonction et détecter les erreurs. C’est pour cette raison que les alert() deviennent inutiles : tout est à portée de main. Vous ne pesterez plus contre un undefined mal placé

En parallèle de ça, l’inspecteur DOM est à utiliser pour visualiser d’un coup d’œil les différentes variables actives ainsi que leur arborescence. Comme tout est cliquable, l’inspecteur vous transporte sur n’importe quel objet pour en étudier le contenu.

La console Firebug alias console.*

La console Firebug est l’autre tueuse d’alert() et s’utilise de deux manières.

La plus accessible est d’interagir avec. Vous saisissez votre code, la console l’exécute et retourne le ou les résultats. Encore une fois les objets sont cliquables et navigable au travers de l’inspecteur DOM.
La console est utile pour utiliser des fonctions sorties du contexte de l’initialisation : il devient tout à fait possible de piloter des éléments après le chargement de la page. Ça évite encore une fois des F5 inutiles et consommateurs de temps.

L’autre manière d’utiliser la console c’est de ne pas l’utiliser. Ou pas de manière active tout du moins puisqu’elle est également un objet JavaScript (console) utilisable dans votre code auquel sont rattachées plusieurs fonctions au nom explicite :

• console.log() : affiche une information standard
• console.info() : affiche une information de type « information »
• console.warn() : affiche une information de type « avertissement »
• console.error() : affiche une information de type « erreur »
• console.debug() : débogue le contenu d’un objet directement dans la console

Autrement dit, si l’inspecteur ne suffisait pas, au lieu de lancer un alert(mavariable) (potentiellement dangereux dans une grande boucle qui n’a jamais cliqué 50 fois sur « OK » à cause de ça ?), il vaudra mieux utiliser console.log(mavariable). Il y a de quoi faire, surtout avec la possibilité de créer des groupes de messages et l’utilisation de la syntaxe printf.

Et top du top, en cas d’erreur JavaScript, la console affiche un petit cercle rouge qui rappelle fortement le point d’arrêt. Normal puisque c’en est un. Un clic et on évite de rechercher la ligne problématique dans le code. Encore une fois, du temps de gagné.

Firebug pour les performances

Après avoir bien développé, Firebug propose de mieux développer. L’extension magique propose quelques outils sympathiques pour rapidement déceler les problèmes, notamment de scripts trop gourmands ou à optimiser.

Le traceur réseau

Avec le traceur réseau c’est simple, tout ce qui est chargé sur la page est chronométré. Si un élément est systématiquement long à charger en tête de liste, pourquoi ne pas essayer de le déplacer dans le bas de la pile ? Je pense notamment aux appels vers des fichiers JavaScripts externes. Les appeler en bas de page permet d’éviter des gels de page. C’est ce que YSlow nous recommandera

Outre une petite prévisualisation des contenus, le traceur affiche aussi les statuts des contenus s’ils sont différent du statut 200 (found). Et de surligner ça en rouge en cas de fichier introuvable.

J’aime beaucoup le traceur pour le suivi des requêtes XHR (appels AJAX). Un clic sur un appel affiche à la fois les entêtes, les données transmises au serveur et sa réponse. Fini les requêtes AJAX qui ne produisent rien sans qu’on puisse savoir pourquoi. Le clic droit sera également un fidèle allié, notamment pour ouvrir l’appel AJAX dans un nouvel onglet. C’est plus lisible pour déboguer quand même

Le profileur JavaScript

Le profileur (profiler) JavaScript s’utilise un peu à la manière de la console : de manière active ou au travers de l’objet console.

Le profileur enregistre tout ce qui se passe entre le moment où il est enclenché et le moment où il est stoppé. Il va ainsi dénombrer toutes les appels (calls), leur durée d’exécution et leur fichier d’origine, entre autre. L’idée est bien entendu de voir ce qui consomme le plus d’appels et de temps pour savoir si ce comportement est normal ou pas. À ce stade là, difficile de pousser la granularité du profileur plus loins.

Sauf en utilisant le profileur directement dans le code comme on a déjà pu le faire pour les logs. console.profile() et console.profileEnd() seront vos amis. C’est vraiment l’idéal pour profiler l’exécution d’une fonction, voire même les portions de code exécutée en son sein.

L’extension YSlow

L’extension YSlow est une extension pour Firefox mais elle nécessite toutefois la présence de Firebug. Elle s’articule autour de trois critères.

Il y’ a d’une part la surveillance des performances. YSlow se base sur la liste des bonnes pratiques établies par Yahoo! (14 à l’heure actuelle). YSlow passe ces critères en revue et accorde une note en conséquence. Si certaines sont difficiles à tenir, c’est un bon moyen de s’intéresser à de nouvelles pratiques d’optimisation et de performances.

Le second critère est affiché dans le panneau stats. Il s’agit de la capture d’écran ci-dessus. Certes il s’agit d’un simple tableau mais dont les chiffres sont intéressants à étudier. YSlow analyse la page pour un premier et un second chargement. La différence entre les deux ? C’est que le cache est passé par là et normalement, je dis bien normalement, le second chargement se doit d’être beaucoup plus rapide.
Si ce n’est pas le cas, il y a de l’optimisation à faire et cela peut aussi signifier du côté serveur Web. Pas forcément du développement donc.

Enfin on termine sur une partie complémentaire aux stats : les composants (components). Elle distille des informations plus verbeuses que le traceur réseau de Firebug en se focalisant sur les E-Tag, la présence ou pas de compression, la date de validité du cache ainsi que la taille des objets.

Conclusion

J’espère avoir éclairé quelques lanternes sur l’utilisation de Firebug. Cette extension est suffisamment puissante pour gagner en confort de développement ; il serait dommage de s’en priver. On gagne du temps, du confort et surtout, de la qualité de développement.
À noter qu’il existe aussi Firebug Lite. Il s’agit d’un script JavaScript compatible avec les principaux navigateurs du marché mais comme le Lite l’indique, les fonctionnalités sont plutôt limitées. Seule la console JavaScript persiste.