Le temps d’affichage des pages impacte le taux de transformation

Tout est dans le titre…

Un site dont les pages mettent trop de temps à s’afficher et hop, les visiteurs sont déjà ailleurs.

Des tests ont été fait… L’impact est carrément très important (à deux chiffres…) !

Alors ?

C’est un sujet clé qu’il faut prendre a bras le corps :

  • Limitez le poids de vos pages… Toutes vos pages !
  • Travaillez vos pages pour que, même incomplètes, elles s’affichent le plus vite possible ;
  • Optimisez votre architecture serveur pour que les réponses soient rapides. Ce point est assez technique… En général, beaucoup de choses se règlent au niveau de la base de données… et de la bande passante.

7 commentaires

  1. bonsoir Francois,

    Une grande partie de la rapidité des temps de réponse est lié à l’architecture de l’application qui motorise le site y compris tu as raison la base de données.

    Un des prérequis est de prévoir un modèle de données pour la publication différent de celui qui permet la manipulation des données.

    Si c’est le même modèle les temps de réponse augmenteront en flêche et ajouter des serveurs ne réglera le problême que provisoirement si la charge augmente.

  2. On ne rappellera jamais assez qu’une des raisons qui ont fait le succès de Google à ses débuts : 1 page de moins de 60ko à une époque où tous les moteurs de recherche avaient des têtes de « cabanes à Mickeys »

  3. Pour travailler sur différents langage de développement de sites web (J2EE, PHP, ASP…), il est flagrant que plus on rajoute de couche d’architecture, plus l’affichage des pages est ralenti.
    Une architecture avec un serveur d’application Glassfish, une base de données objets ORACLE, une abstraction des données gérées par Hibernate, sera plus lente à afficher des pages qu’une application PHP/MySql ou PHP/oracle.

  4. c’est tout le problème de la « logicielisation » des applications web en général: abstraction, modularité, maintenabilité, réutilisabilité, extensibilité.
    Ca devient comme une obsession quand on lit les soi-disant bonnes pratiques de développement, et au final, on se trouve avec des applications lourdes en charge serveur et donc plus lentes.

    Magento est l’exemple même de la killer app ultra gourmande. Une bien jolie application mais définitivement trop lourde.

  5. Comme d’habitude, il faut savoir s’adapter au besoin. Certes des applications comme Magento sont lourdes, mais c’est ce qui fait surtout sa force : le temps (donc l’argent) gagné en développement et en maintenance avec une application structuré est très largement supérieur au prix d’un serveur un peu plus performant :o)

Laisser un commentaire

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