Nouveau site de Paris 7 : Peut mieux faire
lundi 13 février 2012 à 23:54L'Université Paris 7 (Diderot) a récemment refait l'apparence son site. L'annonce dit : Nouvelle ergonomie, nouveau graphisme, pour un site web plus lisible, plus facile d'utilisation, plus dynamique aussi
. Si l'ergonomie du site n'est effectivement pas trop mauvaise, même si on se perd un peu dans l'arborescence des pages (Essayez, à partir de la page d'accueil, d'arriver sur la rubrique consacrée aux stages, sans passer par la recherche. Bonne chance); par contre au niveau de l'accessibilité et des performances, c'est la catastrophe. Bien que le site prétend se mettre progressivement en conformité
avec le RGAA depuis au moins 2008, on remarque que le champ de recherche ne comporte pas de libellé (<label>), et ce depuis au moins 2006, époque à laquelle la page du service de communication était ornée d'un beau gif animé. Le site n'est évidemment pas valide WCAG niveau A (pas d'attribut alt sur des images qui servent de lien), et on notera que certaines parties du site ont une taille de police spécifiée en pixels, donc la taille ne bouge pas si on augmente la taille de la police via le menu du navigateur.
Sans surprise, le site n'est pas valide HTML, avec 196 erreurs, dont la majorité est en fait issue du fait que certaines URL contiennent le caractère "&" au lieu de "&", son code HTML.
Performances générales
Au niveau des performances, WebPageTest nous indique que le start render est à 2 secondes et le temps de chargement total est de 7.2 secondes la première fois (respectivement 0.8 secondes et 2.8 secondes la seconde, avec le cache), pour un total de 54 requêtes. On note que lorsqu'on tente d'accéder à l'URL principale du site, i.e. www.univ-paris-diderot.fr, on est redirigé deux fois avant d'arriver sur la véritable page d'accueil. La connexion est Keep-Alive (bon point), mais aucune ressource (même les scripts, le HTML ou les feuilles de style) n'est compressée.
Styles
La page comporte 7 feuilles de styles, dont deux quasiment identiques (site.css et sitefr.css), non minifiées, et surtout pas adaptées aux terminaux mobiles (pas de @media-query, et des éléments de 900px de largeur), la fenêtre devient d'ailleurs trop petite en dessous de 930 points. Cinq d'entre elles sont chargés classiquement dans le <head>, et deux autres dans le corps de la page (non valide).
Scripts
La page comporte 9 scripts externes, dont un qui n'existe pas (Erreur 404. Si on tente de l'ouvrir dans le navigateur, on tombe sur une page 404 personnalisé, qui tente d'afficher des images qui… n'existent pas), et jQuery version 1.6 (importé deux fois !) minifié (c'est le seul script qui l'est), ainsi qu'une version 1.7. À l'exception de quelques uns chargés dans le <body>, tous les scripts sont chargés en tout premier dans le <head>, alors que ceux-ci ne sont pas tous nécessaires au rendu de la page. On trouve par ailleurs un script inline téléchargé sur EasyScript, qui n'est jamais utilisé (il permet d'ouvrir une pop-up pour afficher une image), et du Google Analytics en bas de page.
Parmi ces scripts chargés en tout début de page, en dehors des deux nécessaires au diaporama, aucun n'est nécessaire au rendu, donc ce placement est tout sauf justifié. Dans les détails, parmi les scripts existants, on trouve d'abord jQuery, puis un script (copié sans citer la source) permettant de faire des diaporamas, puis un script utilisant le précédent qui démarre un diaporama une fois la page entièrement chargée, et enfin un dernier qui n'a pas d'autre fonction que d'ajouter/enlever une classe aux éléments du menu survolés avec la souris (:hover ? Connaît pas). Notons qu'en dehors de jQuery, aucun de ces scripts n'est optimisé (les sélecteurs jQuery sont utilisés à outrance sans utiliser de mise en cache, on trouve de multiples mot-clefs var, et la taille d'un tableau n'est pas mise en cache lors du parcours de celui-ci avec une boucle for), et on trouve des incohérences, par exemple le script menu.js modifie à l'arrache les classes d'un élément (via une expression régulière), alors que jQuery, inclut un peu au dessus, propose les méthodes .addClass() et .removeClass().
Images
Les images ne sont pas servies via un (sous-)domaine différent, donc chaque requête envoit les cookies pour rien. Les dimensions réelles de l'image ne sont pas indiquées dans le code HTML, ce qui aurait pu éviter un temps de calcul supplémentaire de la part du navigateur.
Proposition
Inspiré par le concours WebPerf Contest qui a eu lieu en 2010 et dont l'objet était l'optimisation d'une page du site de la Fnac, et suite aux multiples observations faites dans toute la partie supérieure du billet, je me suis lancé un petit défi dont le but est d'optimiser la page d'accueil du nouveau site de Paris 7, en appliquant toutes les bonnes pratiques possibles de façon à ce que le site soit plus performant. Les règles sont les mêmes que pour le concours, l'apparence du site doit rester la même, toutes les fonctionnalités actuelles doivent rester disponibles (en l'occurrence, c'est plus simple, il n'y a aucune requête AJAX); Le but principal étant d'optimiser la page, mais tout ce qui peut améliorer l'expérience utilisateur (notamment au niveau de l'accessibilité) est un plus, du moment que ça ne prend pas des jours à réaliser.
1- Récupérer la page d'accueil ainsi que tous les composants externes
J'ai simplement utilisé Chromium pour enregistrer la page avec ses dépendances (images, fichiers CSS et Javascript). Certains fichiers n'ont pas été téléchargés (les fichiers chargés via des scripts, notamment), pour ceux-ci il a fallu les chercher à la main en regardant les erreurs 404 générées.
2- S'organiser
J'ai créé un dépôt sur Github pour tout versionner afin d'organiser le travail, et de garder un historique des optimisations. J'ai également créé deux sous-domaines (static1 et static2) sur mon site en vue de les utiliser pour les médias (en l'occurrence, uniquement des images).
3- Nettoyer
Il a d'abord fallu nettoyer un peu tous ces fichiers, les feuilles CSS étaient par exemple remplies de commentaires. Ainsi, (presque) tous les commentaires des scripts, du fichier HTML principal et des feuilles CSS ont été supprimés. Certains scripts étaient inutiles et ont été retirés, tandis que les autres ont été fusionnés de telle façon qu'il n'en reste que 2 (sur les 7 originaux). Du côté CSS, on est passé de 7 feuilles de style à 5.
4- Préserver la compatibilité
La page originelle affiche une image aléatoire (parmi 5) en haut, ceci a été préservé, ainsi que la présence d'un cookie (j'ai simplement utilisé un cookie de session).
5- Réduire
La majeure partie de l'optimisation consiste à réduire, d'une part, le poids total des éléments de la page, et de l'autre le nombre de requêtes. J'ai optimisé les images PNG avec les outils optipng et pngcrush, tandis que pour les JPG, j'ai utilisé jpegtran. Ces outils sont lossless, i.e. il n'y a pas de pertes de données. J'ai également utilisé l'option -quality de l'outil convert (qui fait partie d'imagemagick) pour réduire (avec perte de qualité) certaines images qui n'avaient pas besoin d'être de grande qualité (les icônes, notamment). Les images statiques (i.e. qui sont toujours sur la page d'accueil, quel que soit son contenu) comme les drapeaux ou les logos Facebook/Twitter ont étées combinées en une seule, en utilisant la technique des CSS Sprites. Les feuilles CSS et les scripts ont été optimisés puis minifiés.
6- Mettre en cache
Les images ont été réparties sur trois sous-domaines différents; les PNG sur static1.bfontaine.net/up7opt/, les JPG et GIF sur static2.bfontaine.net/up7opt/, tandis que la favicon et les images de fond du diaporama ont été gardées sur le sous-domaine principal. Ceci permet de paralléliser les chargements et de supprimer les cookies dans les requêtes d'images (sur les autres sous-domaines). les feuilles CSS et les scripts sont également mis en cache.