Company News

Pourquoi ne devons-nous pas toujours blâmer notre hébergeur quand notre site Web tombe ?




Je voulais partager avec vous une anecdote dans laquelle la plupart des "non techniques" d'entre nous se reconnaîtront. Nous pensons que quand notre site Web crashe, nous devons forcément nous en prendre à notre hébergeur.

Ce post est un compte-rendu de conversation lors du test de performance que j'ai fait pour un ami dont le site Web était en panne, et où j'ai pu démontrer que son hébergeur n'était pas responsable de ses problèmes sur son site Web.

Je pense que cet exemple reflète parfaitement pourquoi les marketeurs, les designers et certains développeurs devrait être plus attentifs à la complexité d'un site Web avant de distribuer les blâmes.

Cet article est paru dans MarketingMag.com.au mais a été retravaillé pour notre blog.

Tout commence par un coup de téléphone...
Attention les échanges contiennent des grossièretés.

J'ai reçu un appel hier d'une ancienne collègue qui subissait de gros problèmes de performance impactant l'expérience de ses utilisateurs. Elle est maintenant Digital Marketing Manager dans un grand cabinet de recrutement international… et dire qu'elle est une fanatique de la performance digitale est un euphémisme...
Voici un résumé de la conversation :
"Dave, j'ai besoin d'aide. Notre site est piraté en permanence, il est tombé déjà 2 fois sur des périodes prolongées. C'est inacceptable car nos consultants ne peuvent pas soumettre leurs rapports à temps. On doit tout faire manuellement et tout le monde me pointe du doigt !"
C'est alors qu'elle s'est mise à accuser son hébergeur…
"Notre hébergeur est naze. Peux-tu m'en recommander un bon ? Le site est sans arrêt en panne et il est lent"
OK. Le site est en panne et il est lent. Ça doit être l'hébergeur. Jugement facile, mais pas forcément correct.

Quid d'un test de performance du test pour diagnostiquer le problème ?

Ma suggestion, plutôt que de pousser le problème à un autre potentiel responsable, a été de mettre en place un test de performance avec Dynatrace Synthetic Monitoring.

J'ai réalisé quelques tests basics, avec 2 lieux de connexions, en utilisant Chrome. Je cherchais en particulier :

  • Le temps de réponse et la disponibilité
  • Les variations de performance (le temps de réponse est-il fluctuant ou constant ?),
  • S'il y a un problème, quelle en est la cause ? (Un plugin de partie tierce, la taille des images, objet défaillant)

En particulier, j'ai regardé les éléments suivants :

  • La Homepage
  • Une autre landing page (je voulais comprendre si le problème impactait une page isolée ou l'ensemble du site),
  • La page d'accueil d'un des plus gros concurrents (il est important de se comparer continuellement, peu importe qu'on soit confrontés à des problèmes de performance ou pas),
  • Le site du concurrent de manière globale (c'est une autre façon de se comparer, en plus des métriques).

Cette image montre les temps de réponse pour la Homepage, une autre landing page, le site global et la concurrence. En moyenne, les temps de réponses étaient très élevés et on pouvait également voir des pics de mauvaise performance.

En l'espace de 12 heures j'ai pu identifier clairement le problème :
1. Le temps de réponse de la Homepage était en moyenne de 16 sec. (Ouille)
2. Une panne majeure a eu lieu à 22h pour au moins 1h.

Donc, qu'est ce qui cause le problème ?
Les problèmes de performance proviennent d'un plugin d'une partie tierce, par de l'hébergeur.

Allez en profondeur dans vos data et découvrez l'origine des problèmes de temps de réponse et de pannes.

Ce graph montre qu'un plugin de tierce partie est la cause majeure des délais de temps de chargement du site.

J'ai pu également regarder l'objet sur une période définie pour voir à quel point il a été gênant sur l'ensemble du site. Nous pouvons alors voir l'impact d'un plugin tiers au fil du temps, en analysant l'analyse des tendances.

Et maintenant qu'est-ce qu'on fait ?
Rapidement, j'ai été capable de mettre en évidence le problème. Maintenant, je peux l'aider à utiliser ces informations pour reconstruire son site.

Les principaux enseignements sont les suivants :

  • Le site est mal construit et a des problèmes de temps de réponse.
  • Les sites lents causent de nombreux abandons et des plaintes utilisateurs. Nos datas montrent que 40% des utilisateurs abandonneront après 3 sec.
  • Le principal problème vient d'un plugin tierce. Il est en effet très facile, avec WordPress, d'ajouter des fonctionnalités au site en utilisant des plugins, mais vous devez toujours prendre en compte l'impact sur la performance.
  • Ne faites pas de supposition alors que vous pouvez obtenir des données factuelles permettant d'isoler la cause exacte des problèmes.
  • La gestion des performances vous aide à comprendre quels sont vos problèmes de performance afin que vous puissiez prendre des décisions basées sur des data qui vous permettront de résoudre vos problèmes.
  • Etablissez des normes sur vos performances souhaitées en continue. En moyenne (en Australie), le temps de chargement dans le retail est de 5.9 sec ; utilisez ces données pour engager vos équipes marketing et vos développeurs dans votre stratégie de performance digitale. Dès que vos données commencent à glisser, vous savez que vous avez un problème...



A propos

Dave Anderson

Dave est Marketing Director APAC chez Dynatrace, basé à Melbourne en Australie. Dave a une grande expérience dans le digital marketing, que ce soit du côté client ou du côté web agency. Dave nourrit une grande passion pour les analyses techniques, le coding, les médias sociaux, le développement de sites Web et le design. Ainsi, il est capable de transformer des théories compliquées en des perspectives simples. Il se dit lui-même "geek", il est musicien, accro au café et fanatique de sport, et jamais ennuyeux !