Votre site est lent? Optimisez-le!

La majorité des sites Internet sont lents. La majorité des blogs ne sont pas optimisés et performants

Tout le monde a déjà lu ou bien s’est rendu compte de cela.
Tout éditeur de contenu, blogueur, photographe “trouve” un jour ou l’autre que son site n’est pas assez rapide sans forcément savoir par où commencer pour régler le problème.
Quelquefois sans même savoir s’il y a un problème.

Vous trouvez que votre site est lent: c’est bien souvent le cas. Explications

Cet article va essayer de vous aider à identifier ces problèmes de performances, les outils permettant de les mettre en lumière.

Avant de rentrer dans le vif du sujet, quelques précisions.

Dans cet article, je vais principalement m’intéresser et détailler la performance et les contraintes du point de vue “Front end”. liées aux ressources et au rendu dans les navigateurs Internet.
Cette partie étant standardisée (par le W3C), les bonnes pratiques sont partagées et implémentées largement par les éditeurs.

La partie “Backend” peut, elle aussi, engendrer des problèmes de performances. Ces problèmes étant directement liés à une technologie, un serveur applicatif voire à sa version.
Ils apparaissent en amont dans la chaîne et doivent être traités par des stratégies différentes et taillées sur mesure.
Je ne rentrerai pas en détail ici dans les méandres et souffrances des différents produits.

Je vous invite également à lire l’article précédent “Comment est construit ce site photo? Outils, technologies, optimisations et bonnes pratiques” qui vous présente comment ce site photo est réalisé sans Content Management System (WordPress, Drupal, Joomla) et sans plateforme (500px, Wix, SlickPic, Duda).
Dans le but de réduire le nombres de couches techniques et par la même occasion ne pas multiplier les sources pouvant engendrer des problèmes de performance.
Dans le cas précis de Lanuit.Paris, éviter la maintenance inutile d’une architecture backend n-tiers (serveur applicatif, base de données, hebergement spécifique dédié).

Le chargement d’un page internet est le résultat d’une chaîne.

Lorsque vous tapez une adresse dans votre navigateur:

• vous lui donnez l’ordre de contacter un hôte sur le réseau (un serveur sur un port donné)
• qui va prendre un certain temps pour répondre (temps de latence réseau et temps de traitement serveur)
• qui va vous envoyer un premier message (code source) avec le contenu de la page (HTML et Javascript)
• ce contenu va lui même référencer d’autres ressources (CSS, Javascript, images, polices de caractères, vidéos) que votre navigateur va devoir également télécharger
• Selon la vitesse de votre connexion et du poids des ressources téléchargées, ceci peut être plus ou moins long.
• Le navigateur n’affiche pas les ressources au fur et à mesure et dans l’ordre où il les reçoit
• Il doit suivre une logique d’interprétation et d’exécution : certaines ressources peuvent bloquer et retarder l’affichage de la page de la même manière que l’interprétation de certaines librairies.

Vous ne le saviez peut-être pas mais l’apparente lenteur de votre site peut provenir plusieurs sources et les couches peuvent s’accumuler.
La solution ne consiste pas à corriger à un seul endroit.

Je vais également en profiter pour tordre le cou à une légende urbaine:
Non, très souvent, “prendre un serveur plus puissant” ne sert à rien, surtout pour les sites de contenu.

Pour les plus téméraires, je vous invite à lire ce document très complet et très technique sur la manière dont un moteur de rendu fonctionne.
Lien : Critical Rendering Path

Fort heureusement, il n’est pas nécessaire de connaître tout cela en détails pour optimiser son site internet.
La lecture de cette documentation nous rappelle toutefois quelques fondamentaux du web.

Nommer l’évidence et la traiter en priorité

Les pratiques les plus directes et les plus simples à appliquer concernent la maîtrise des ressources (taille, nombre, utilité)

• Adapter la taille des images à la cible (ordinateur, tablette, smartphone)
• Ne pas embarquer et charger de fonctionnalités inutiles (non exploitées par une page donnée)
• Alléger les feuilles de style
• Utiliser un jeu minimal de polices de caractères
• Sélectionner les librairies externes avec précaution et parcimonie
• Activer la compression des ressources

La frugalité est un élément important. Il est central pour moi.
C’est pourquoi la majorité des CMS (WordPress, Drupal, Joomla) obtiennent d’assez mauvais résultats. Ils privilégient la mise à disposition et la profusion de fonctionnalités en négligeant bien souvent le rendu.
La règle du “qui peut le plus, peut le moins” est l’ennemie dans ce cas précis.

Comment peut-on mesurer la performance de son site Internet?

Il existe des outils à la fois en ligne en embarqués dans les navigateurs (sur ordinateur) qui permettent de tester et valider différents points.

YSlow! est un ancien outil développé par Yahoo! qui semble toujours fonctionner.
Le standard aujourd’hui est LightHouse ou son équivalent en ligne Google PageSpeed.

Est-on condamné à passer par les outils de Google?

Il existe aujourd’hui trois éditeurs principaux de navigateurs Internet :

• Google qui fournit la technologie de moteur de rendu “Chromium” utilisée dans Chrome et désormais Microsoft Edge
• Mozilla qui fournit la technologie “Gecko” utilisée dans Firefox
• Apple qui fournit “Webkit” utilisée dans les navigateur Safari

Chrome détient aujourd’hui plus de 65% du marché, suivi par Safari, les autres se partageant les quelques pourcents restant.
Source: StatCounter Usage Navigateurs

Néanmoins, Google ne décide pas totalement seul des fonctionnalités et améliorations à apporter aux moteurs de rendu.
Le World Wide Web Consortium (W3C) guide et pilote, entre autre, les innovations et améliorations futures à implémenter dans les navigateurs.

Exemple d’utilisation de Google PageSpeed sur Lanuit.Paris: le cas du “preload”

PageSpeed/LightHouse est un outil que j’utilise systématiquement pendant les développements et après chaque mise en ligne de nouvelle version.

J’ai, par exemple, utilisé sur la “home page” de ce site la fonctionnalité de “preload” des feuilles de style. Cette amélioration qui fait partie d’une préconisation du W3C.

Les éditeurs suivent généralement les recommendations du W3C. Pas forcément tous au même rythme.
Certaines nouvelles fonctionnalités ne sont pas nécéssairement ou difficilement rétrocompatibles.
Ce qui peut provoquer une dégradation ciblée de l’expérience utilisateur, le temps que les navigateurs en question se mettent à niveau.

L’adoption de ces nouvelles fonctionnalités sur son site internet nécéssite de prendre des décisions.

• Assurer les deux modes de fonctionnement (ancien et nouveau). Devoir maintenir deux versions et augmenter le niveau de complexité du code (pour assurer une période de transition). Dans ce cas précis, ajouter du Javascript, tester le user-agent, injecter le comportement de manière conditionnelle.
• Attendre que tous les navigateurs soient à niveau pour bénéficier des améliorations et pénaliser tout le trafic.

Heureusement, il existe un outil qui permet de comparer les différentes “roadmaps” des navigateures et aide à prendre ce type de décision: “CanIuse.com”

Dans le cas de l’implémentation de “preload”, tous les navigateurs sauf Firefox implémentent déjà cette fonctionnalité.
Firefox a prévu de l’activer d’ici peu.

Firefox représentant moins de 4% du trafic potentiel, j’ai décidé de délivrer l’amélioration en connaissance de cause.
Délivrer une meilleure expérience à une plus large audience en pénalisant l’expérience utilisateur d’une petite partie des visiteurs.

Cette technique de “preload” m’a permis de passer sous la barre de la seconde sur l’indicateur “First Contentful Paint”.
Concrètement, cela signifie les premiers éléments de la page d’accueil s’affichent sur l’écran en moins d’une seconde sur les trois versions (ordinateur, tablette et mobile).

Améliorer les performances: pour le visiteur mais aussi un peu pour l’environnement

Générer des ressources moins lourdes ou inutiles depuis les serveurs, éviter de transporter sur les réseaux des kilobytes inutiles.
Éviter aux navigateurs, de télécharger, d’exécuter ou de lire du code non indispensable.
Tous ces efforts allègent la chaîne de traitement et peuvent contribuer à réduire les besoins de stockage et l’énergie dépensée.
Le faire à son échelle et à grande échelle semble une bonne idée.

LaNuit.Paris est-il un site optimisé et performant?

Dans un prochain article, j’essaierai de détailler les différentes étapes qui m’ont permis d’améliorer ce site.
Les actions clés et les indicateurs qui me permettent d’affirmer qu’avec une interface utilisateur simple et user-friendly, on peut créer un site plus rapide et performant que la majorité des site de contenu présents en ligne.

Tout cela, en se concentrant sur l’essentiel et sans concession sur la qualité des photographies proposées.

N’hésitez pas à me contacter si vous avez des questions en envoyant un email à photo@lanuit.paris