Optimiser le temps de chargement de votre site e-commerce

Je vous parlais il y a quelques temps de l’importance du temps de chargement en chiffres

et notamment « 32 % des utilisateurs [quittent un site Internet s’il est considéré trop lent] au bout d’une fourchette de temps allant d’une à cinq secondes. »

Mais alors, que peut-on y faire, comment savoir ce que l’on peut exiger de ses développeurs / de son agence.

Il existe des solutions :

  • Faire un simple test qui va décortiquer le chargement de votre page ;
  • Suivre l’évolution du temps de chargement ;
  • Demander à vos dévs d’être transparents sur les temps de génération avec du reporting ;

Faire un simple test qui va décortiquer le chargement de votre page

avec GTmetrix.com par exemple (ou WebPagetest.org qui permet de sélectionner une localisation en plus, Page Speed Insights by Google

Regardez surtout bien la timeline pour vérifier de quels éléments proviennent la lenteur du chargement.

Ne vous fiez pas trop à Google Analytics qui a mis à disposition une sous-rubrique dédiée à la vitesse du site dans la rubrique « contenu » mais qui ne semble pas vraiment fiable.

Actions / Réactions

Ce que ces outils mettront en avant sont souvent des problèmes mineurs. Ce qui est important (checklist à voir avec vos dévs) :

  • faire servir vos médias (images, Javascript et CSS) par un serveur à part
    • qui serve mieux les images (utiliser nginx par exemple)
    • sur un domaine ou sous-domaine différent (pour pouvoir spécifier que les cookies doivent se limiter au contenu et ne pas envoyer d’entêtes contenant les cookies aux fichiers médias)
    • tout cela permettra d’augmenter en plus le nombre de téléchargements parallèles sur votre site et donc améliorera de fait encore le temps de chargement
  • que la majorité de vos images de présentation (les éléments de décorations, les pictos, etc.) soient regroupées tdans des sprites (lire article sur Alsacreations) (cela diminue le nombre d’images à télécharger et donc le nombre de connexions nécessaires)
  • pour vos fichiers JS et CSS, utiliser l’outil minify
  • que le temps de génération de la page elle-même ne soit pas trop long, dans l’idéal de max 500ms, de façon plus réaliste jusqu’à 1 ou 1,5s.
  • tous les tags que vous pouvez avoir doivent être chargés après que la page soit affichée, cela évitera par ailleurs de bloquer le chargement de votre page lors de toute indisponibilité d’un de vos multiples tags. Des outils existent pour cela : Eulerian Tag Master et Lengow Tag Capsule par exemple

Suivre l’évolution du temps de chargement

GTmetrix vous propose une fois le test lancé un onglet « historique » qui vous permettra de voir l’évolution entre vos différents tests sur une même URL.

Google Webmaster Tools propose dans sa rubrique « Labos » une page « Performances du site », vouée à disparaître mais qui existe toujours, qui vous fournit un graphique bien utile.

Demander à vos dévs d’être transparents sur les temps de génération avec du reporting

Demandez à vos développeurs de pouvoir consulter à la demande le temps de chargement de telle ou telle page. Ce mode de reporting ne doit pas être activé en permanence, il nuirait à vos performances, mais vous devez pouvoir le visualiser à n’importe quel moment pour n’importe quelle page.

Ce reporting vous permettrait de voir par exemple le temps de génération de votre entête, du menu, du contenu du moteur d’affinage de votre page catégorie, de génération du listing produit, de génération du pied de page…

Plus que de vous permettre à vous de voir exactement ce qu’il se passe, c’est un formidable outil pour vos développeurs pour pouvoir identifier exactement où se trouve un point de lenteur sur telle ou telle page.

Vous pouvez ainsi leur dire « la page catégorie est trop longue, merci de voir d’où cela vient ». Premier réflexe qu’ils n’auraient pas sans cela, ils activeront cet outil et le rendront plus fin jusqu’à trouver le vrai point de ralentissement à optimiser.

Cette méthode de management vous permet de vous assurer que vos techniciens ont toute latitude pour effectuer les optimisations nécessaires.

Le problème vient bien souvent de requêtes non optimisées vers la base de données ou de requêtes imbriquées dans des boucles. Il faut à tout prix éviter cela. Faire intervenir des personnes extérieures pour auditer le code quand on a une équipe junior peut s’avérer bénéfique pour tout le monde.

Fasterize, la société qui promet de vous aider

pour ceux qui n’ont pas de grosses équipes ou de gros moyens techniques, Stéphane RIOS, un ancien CTO de chez RueDuCommerce, a lancé Fasterize, qui promet de vous aider en se mettant entre votre serveur et le web pour appliquer un peu d’optimisation avant de servir la page Web.

Le concept, vraiment intéressant est à découvrir ici : http://www.fasterize.com/fr

Pour les teckos

pour les afficionados de la technique, ceux qui aiment bien rentrer dans le lard du souci, ceux qui sont pas du genre à ne pas toucher à la mécanique de leur porsche, ceux à qui on ne la fait pas…

Petit article sur mon blog plus technique : http://www.astucesdewebmaster.com/architecture/mon-site-est-lent-que-faire-serveurs-dedies-391

 

Publié

dans

par

Romain Boyer

Étiquettes :

, ,

Commentaires

9 réponses à “Optimiser le temps de chargement de votre site e-commerce”

  1. Avatar de médaille chien
    médaille chien

    Point crucial pour le site d’un e-commerçant ! J’utilise page Speed, il fournit d’excellente informations, après il faut les mettre en pratique….c’est déjà moins facile ! ^^

  2. Avatar de Gebruik
    Gebruik

    Rien sur les problématiques de cache côté serveur ?
    Les solutions que vous proposez, même si elles ont un grand intérêt, ne suffisent généralement pas : mauvais usage bibliothèques JS (c’est assez fréquent de voir du jQuery, Mootools et une bouse faite maison sur le même site), images non sémantiques utilisées avec des balises (alors qu’elles auraient tout intérêt à l’être en CSS pour des raisons de cache), les sites e-commerce particulièrement sont des usines à gaz.
    Un travail de fond sur le caching et le pré-caching côté serveur offrent des résultats qui vont bien plus loin.

  3. Avatar de Romain BOYER
    Romain BOYER

    Alors, là on va chercher plus loin.
    Disons que si le code source est trop long à générer (ce qu’on voit donc avec les outils cités plus haut), et qu’on identifie des zones qui ont intérêt à être cachées, on peut le faire de différentes manières :
    – cache maison (ne pas recalculer le même contenu à chaque chargement de page et le conserver dans un dossier de cache pour le re-servir ensuite jusqu’à ce qu’il soit désuet)
    – cache intégré (smarty par exemple), qui intègre une composante de cache qui permet d’éviter de recalculer une partie du contenu
    – cache serveur (APC, eAccelerator)

    Je n’ai abordé le sujet qu’en surface, pour que des décisionnaires puissent prendre des mesures en cas de besoin, il était donc utile et indispensable de rester plus en surface.
    Une fois qu’on a identifié tel ou tel ralentissement, de façon précise, on peut laisser le soin aux dévs de se débrouiller pour trouver la bonne méthode d’optimisation.

    Par ailleurs, sur les bonnes méthodes (ne pas mettre du MT avec du JQuery), je n’ai pas croisé ce cas si souvent et il y a tellement de façons de mal faire qu’il est impossible de faire une liste de ce genre.

    Qu’entends-tu par « images non sémantiques utilisées avec des balises (alors qu’elles auraient tout intérêt à l’être en CSS pour des raisons de cache) » ?

  4. Avatar de Christophe
    Christophe

    J’ai une question toute bête…. D’où proviennent vos sources pour le chiffre avancé au début de votre article, c’est à dire les « 32% » d’internautes qui quitteraient un site dans un délai de 1 à 5 secondes.
    1 seconde, cela me parait vraiment très (trop?) bas!

  5. Avatar de Romain Boyer
    Romain Boyer

    je cite mon précédent article où je dis que ma source (qui a répondu en commentaire) n’a pas précisé ses sources

    précédent article : https://www.info-ecommerce.fr/1016/temps-de-chargement-et-retombees-sur-le-taux-de-conversion

    source originale : http://www.wikigento.com/latence/seo-vitesse-de-chargement/

  6. Avatar de Nicolas L.
    Nicolas L.

    En vrac, on pourrait ajouter :
    – utiliser du HTML 5 : on ne gagne pas en temps de génération, mais si c’est bien fait, on peu gagner en temps de rendu dans le navigateur. C’est toujours plus agréable d’avoir une page qui s’affiche d’un coup, plutôt que bloc par bloc
    – utiliser la dernière version du langage (souvent php sur le web) et des frameworks : chaque version est plus rapide que la précédente. Etre en PHP 5.4 est beaucoup plus rapide que d’être en 5.2 par exemple. C’est le temps de calcul qui y gagne, ainsi que la consommation mémoire des serveurs.
    – Reverse proxy : la solution ultime pour avoir une grosse tenue en charge et un temps de « calcul » hyper rapide. On peut citer Varnish par exemple.
    – Base de données : là encore, c’est souvent mysql qui est utilisé. Mais le moteur innodb de mysql 5.1 (standard sur du Debian par exemple) est bien moins performant pour des accès concurrents que des versions plus récentes. Et si en plus il est configuré correctement, il y a un levier important de gain de performance.

  7. Avatar de Romain Boyer
    Romain Boyer

    Merci pour ces précisions utiles pour les plus techniciens d’entre nous.

  8. Avatar de Benoit Gaillat
    Benoit Gaillat

    Sur Info-ecommerce j’ai codé les petites images en base64, ça marche pas avec tous les navigateurs mais ça génère 0 appels serveur et c’est pas technique ni difficile à mettre en place

  9. Avatar de Guillaume Ziegler
    Guillaume Ziegler

    En retour d’expérience, je dirais que le meilleur en efficacité/ temps passé est mod_pagespeed qui permet d’optimiser facilement les serveurs Apache, ce module est très complet et on en parle assez peu.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *