Votre boutique est lente : la boutique ou le serveur ?

Un client vous écrit que le site est lent. Vous l'ouvrez, il met cinq secondes, et quelque chose en vous dit qu'un module est en cause. Alors un dimanche après-midi, vous commencez à désinstaller au hasard, en espérant tomber juste.

Cet après-midi-là ne règle presque jamais rien, parce que « c'est lent » recouvre en réalité deux problèmes différents, et un seul des deux se résout en touchant la boutique.

Les deux choses que l'on appelle « lenteur »

Imaginez un restaurant. Il y a le temps entre la commande et le moment où la cuisine sort le plat, et le temps entre la sortie du plat et son arrivée sur votre table.

Dans une boutique en ligne, c'est pareil :

• La cuisine, c'est le serveur : il reçoit la demande, interroge la base de données, assemble la page et la livre.
• Le serveur de salle, c'est le navigateur de votre client : il télécharge images, polices et scripts et les affiche à l'écran.

Si la cuisine met trois secondes à commencer à dresser, peu importe la vitesse du serveur de salle. Et c'est là que passent la plupart des dimanches après-midi : à déplacer la décoration de la table alors que le problème est aux fourneaux.

Comment savoir en deux minutes de quoi il s'agit

Aucun outil exotique n'est nécessaire. Quatre vérifications à faire vous-même :

1. Entrez dans votre back-office. S'il traîne lui aussi —et là, il n'y a ni grandes photos, ni bannières, ni scripts marketing— le problème est en dessous, dans la machine.
2. Testez à onze heures du matin puis à vingt heures. Si à midi ça vole et le soir ça bloque, vous partagez la cuisine avec beaucoup de monde.
3. Chargez deux fois de suite la même page. Si la première met une éternité et la seconde va bien, c'est une affaire de cache : votre boutique refait chaque plat de zéro.
4. Regardez le poids d'une fiche produit. Si une seule photo pèse quatre mégaoctets, voilà votre serveur de salle chargé jusqu'aux sourcils — et cela, oui, se corrige dans la boutique.

Si le back-office est lent, cessez de chercher des modules à désinstaller : le goulot d'étranglement est le serveur.

Ce que l'on trouve d'habitude en dessous

Après quelques sauvetages, la liste se répète :

• Un hébergement « illimité » qui ne l'est pas. Les offres mutualisées limitent processus et mémoire par compte ; quand votre boutique en demande plus, elle ne plante pas, elle attend. Et cette attente, c'est votre site qui traîne.
• Une version de PHP ancienne. Passer d'une vieille version à l'actuelle, sans rien toucher d'autre, réduit souvent de moitié le temps de fabrication de la page.
• Le serveur refaisant un million de fois le même travail, parce que personne n'a activé le cache qui conserve le travail déjà fait.
• Une base de données que personne n'a balayée depuis quatre ans : des millions de lignes de journaux, des paniers abandonnés de 2021, des statistiques que plus personne ne regarde.
• La sauvegarde lancée à dix-neuf heures. Autrement dit, le processus le plus lourd de la journée en pleine heure de vente.
• Des images telles que sorties de l'appareil photo, quatre ou cinq mégaoctets, que le visiteur mobile télécharge en entier.

Rien de tout cela ne se règle en désinstallant des modules, et tout se règle en une matinée quand on sait où regarder.

Ce que nous faisons quand nous gérons le serveur

Nous administrons les serveurs sur lesquels vivent les boutiques de nos clients. Ce n'est pas seulement « louer une machine » : c'est que la machine soit dimensionnée, à jour et surveillée.

• La dimensionner pour votre boutique réelle, pas pour l'offre à la meilleure marge : combien de produits, combien de trafic, combien de commandes à l'heure de pointe.
• La tenir à jour : version de PHP, extensions, base de données et correctifs de sécurité, sans que la boutique tombe le jour de la mise à jour.
• Le cache à sa place, pour que le serveur ne refabrique pas chaque page de zéro, et des images servies légères et dans des formats modernes.
• Une maintenance planifiée de la base de données, les tâches lourdes la nuit, jamais pendant vos heures de vente.
• Une surveillance avec alertes : nous apprenons qu'il y a un problème avant que votre client ne vous écrive.
• Des sauvegardes que l'on restaure, pas seulement que l'on fait. Une sauvegarde que personne n'a essayé de restaurer n'est pas une sauvegarde, c'est un dossier.

Et sans attaches bizarres : le serveur et les domaines sont à vous, avec vos accès. Si un jour vous voulez partir ailleurs, vous partez. Et si vous voulez que nous nous occupions aussi de la boutique — mises à jour des modules, surveillance et heures pour les imprévus —, c’est la maintenance PrestaShop.

Ce que l'on remarque quand c'est bien monté

D'abord, au quotidien : le back-office cesse de traîner, mettre cent produits en ligne cesse d'être un après-midi perdu, et les e-mails de commande partent quand ils doivent partir.

Ensuite, pendant les campagnes : le jour où vous envoyez la newsletter à douze mille personnes, la boutique encaisse le pic au lieu de tomber juste au moment où vous dépensiez en publicité.

Enfin, avec le temps, dans le trafic. Une boutique qui répond vite est mieux explorée et moins abandonnée, et cela finit par se voir dans Google — même si, comme nous l'expliquions dans par où commencer quand on n'apparaît pas sur Google, la vitesse est rarement la première chose à corriger.