C'est la phrase que tout hébergeur entend : « mon site est lent, il faut le mettre sur un serveur au Cameroun ». Parfois c'est juste. Le plus souvent, c'est un diagnostic erroné qui conduit à dépenser de l'argent sans résoudre le problème.
Cet article démonte le chargement d'une page, étape par étape, et classe les causes de lenteur par impact réel. Vous verrez que la distance au serveur arrive rarement en première position.
D'abord, le contexte réseau camerounais
Trois chiffres à garder en tête, parce qu'ils déterminent tout :
- Vitesse médiane fixe : 9,48 Mbps (janvier 2025)
- Vitesse médiane mobile : 13,88 Mbps (janvier 2024)
- Entre 86 et 95 % du trafic internet est mobile
Fait remarquable : au Cameroun, le mobile est plus rapide que le fixe. Cela invalide une bonne partie des réflexes hérités des marchés européens.
Ce que cela signifie concrètement : votre visiteur type est sur un téléphone, avec une connexion autour de 10 Mbps, souvent partagée et instable. Une page de 3 Mo lui prendra plusieurs secondes à charger, quel que soit l'endroit où se trouve votre serveur.
Décomposons ce qui se passe quand on ouvre votre site
Charger une page web n'est pas une opération unique. C'est une séquence :
- Résolution DNS — traduire votre nom de domaine en adresse IP
- Établissement de la connexion TCP — un aller-retour avec le serveur
- Négociation TLS — la mise en place du chiffrement HTTPS, plusieurs allers-retours
- Génération de la page côté serveur — PHP, base de données
- Transfert du HTML
- Téléchargement des ressources — CSS, JavaScript, images, polices
- Affichage par le navigateur
La latence — la distance au serveur — n'affecte que les étapes 1, 2, 3 et 5. Et elle les affecte de façon multiplicative : chaque aller-retour coûte le temps de latence. C'est là son effet réel.
Les étapes 4, 6 et 7, qui dominent le temps de chargement de la grande majorité des sites, ne dépendent quasiment pas de la distance.
Le calcul qui change la perspective
Prenons deux sites vus depuis Douala.
Site A — Serveur à Douala, page mal optimisée
- Latence très faible
- Page de 3 Mo, 80 requêtes, images non compressées, aucun cache
Site B — Serveur en Europe, page optimisée
- Latence nettement plus élevée
- Page de 250 Ko, 15 requêtes, images en WebP, cache actif, compression activée
Le site B sera perçu comme plus rapide, souvent nettement. Parce que la latence ajoute une pénalité fixe de quelques centaines de millisecondes, tandis qu'un surplus de 2,75 Mo à télécharger sur une connexion à 10 Mbps coûte plusieurs secondes.
Autrement dit : l'optimisation de la page rapporte généralement plus que le rapprochement du serveur. Et elle est très souvent moins chère.
Les vraies causes de lenteur, par ordre d'impact
1. Le poids de la page — l'ennemi numéro un
C'est de loin la première cause, et la plus fréquente. Les responsables habituels :
- Images non redimensionnées. Une photo de 4 Mo sortie d'un appareil, affichée dans un cadre de 400 pixels. Le navigateur télécharge les 4 Mo puis les réduit. Une image correctement préparée pèse 50 à 150 Ko.
- Thèmes surchargés. Beaucoup de thèmes WordPress commerciaux chargent l'intégralité de leurs fonctions sur chaque page, y compris ce que vous n'utilisez pas.
- Extensions accumulées. Chaque plugin ajoute ses fichiers CSS et JavaScript. Vingt plugins, c'est souvent quarante fichiers supplémentaires à charger.
- Polices web multiples. Une famille de polices complète peut peser plusieurs centaines de kilo-octets. Deux ou trois graisses suffisent.
- Carrousels et vidéos en page d'accueil. Un diaporama de cinq images haute résolution, c'est cinq images téléchargées pour une seule vue.
Objectif raisonnable pour un marché à 10 Mbps : moins de 500 Ko par page, moins de 1 Mo pour une page riche.
2. L'absence de cache
Sans cache, chaque visiteur déclenche l'exécution complète de PHP et des requêtes en base de données. Avec un cache, la page est servie en fichier statique — souvent dix fois plus vite.
Deux niveaux à activer :
- Cache serveur — LiteSpeed Cache, Redis, ou l'équivalent fourni par votre hébergeur
- Cache navigateur — les visiteurs qui reviennent ne retéléchargent pas les images et les styles
C'est le réglage au meilleur rapport gain/effort de toute cette liste, et il est gratuit.
3. Une base de données négligée
Un WordPress de trois ans accumule des révisions d'articles, des commentaires indésirables, des tables laissées par des plugins désinstallés, des données d'extensions oubliées. La base gonfle, les requêtes ralentissent.
Un nettoyage périodique fait parfois gagner plus qu'un changement de serveur.
4. Trop de requêtes externes
Chaque script tiers — analytics, pixel publicitaire, widget de chat, police externe, bouton de partage — est une connexion vers un autre serveur, avec sa propre résolution DNS et sa propre négociation TLS.
Et le pire cas : un script pointant vers un service disparu. Le navigateur attend l'expiration du délai avant de continuer. Nous voyons régulièrement des sites qui appellent encore des bibliothèques hébergées sur des réseaux de diffusion fermés depuis des années. Chaque visiteur attend inutilement.
Ouvrez la console de votre navigateur et regardez les erreurs réseau. C'est souvent instructif.
5. Un hébergement saturé
Là, la responsabilité est celle de l'hébergeur. Sur un mutualisé surpeuplé, vos ressources sont disputées par des centaines de comptes. Le symptôme caractéristique : un site rapide la nuit et lent en journée.
Si votre site répond en moins d'une seconde à 3 h du matin et en cinq secondes à 14 h, ce n'est pas votre page qui est en cause.
6. La latence — enfin
Elle existe, elle est réelle, et elle est incompressible sur un serveur distant. Le trafic entre le Cameroun et l'Europe transite par des câbles sous-marins, et la vitesse de la lumière dans une fibre fixe une limite physique que personne ne franchira.
Son effet se concentre sur les allers-retours : négociation TLS, requêtes à la base de données déportées, appels d'API. C'est pour cela qu'un site avec beaucoup de requêtes séquentielles souffre plus de la latence qu'un site simple.
Quand un serveur local change réellement les choses
Soyons honnêtes plutôt que commerciaux. Il y a des cas où la proximité géographique est décisive :
- Applications interactives en temps réel — visioconférence, jeux en ligne, trading, outils collaboratifs. Chaque milliseconde compte.
- Applications à très nombreuses requêtes séquentielles — un tableau de bord qui enchaîne trente appels d'API voit la latence multipliée par trente.
- Contrainte réglementaire de localisation — si un cadre juridique ou un cahier des charges impose que les données restent au Cameroun.
- Transferts de fichiers volumineux et fréquents — sauvegardes lourdes, échanges vidéo internes.
Et il y a les cas — la majorité — où cela ne change presque rien : site vitrine, blog, site institutionnel, boutique en ligne de taille modeste, application de gestion peu sollicitée.
Notre position, sans détour : Teles Hosting exploite des serveurs en Europe. C'est aussi le cas de LWS, OVH, Ikoula, PlanetHoster et de la plupart des acteurs internationaux. Quelques hébergeurs camerounais opèrent des serveurs à Douala ou Yaoundé, et pour les cas listés ci-dessus, c'est un avantage réel qu'il serait malhonnête de nier.
Ce que nous contestons, c'est l'idée que la localisation soit le facteur déterminant pour tous les sites. Nous voyons régulièrement des sites hébergés localement plus lents que des sites hébergés en Europe, simplement parce que personne n'a compressé les images.
Comment mesurer au lieu de deviner
Avant de changer d'hébergeur, prenez trente minutes pour mesurer.
1. Séparez le temps serveur du temps de chargement
Le TTFB (time to first byte) est le temps que met le serveur à commencer sa réponse. C'est la partie où latence et performance serveur se jouent.
- TTFB inférieur à 300 ms depuis le Cameroun : très correct pour un serveur distant
- TTFB entre 300 et 800 ms : acceptable, à surveiller
- TTFB supérieur à 1,5 s : le problème est côté serveur ou côté application, pas côté distance
Si votre TTFB est de 400 ms mais que votre page met huit secondes à s'afficher, changer de serveur ne réglera rien. Les 7,6 secondes restantes sont dans vos images et vos scripts.
2. Testez depuis une vraie connexion camerounaise
Les outils de test en ligne mesurent souvent depuis l'Europe ou les États-Unis. Le résultat ne reflète pas l'expérience de vos clients. Testez depuis votre téléphone, en données mobiles, en ville et en périphérie.
3. Testez à des heures différentes
Matin tôt, midi, 20 h. Un écart important entre ces mesures désigne une saturation — la vôtre ou celle de votre hébergeur.
4. Regardez la liste des requêtes
Dans l'onglet Réseau de votre navigateur, triez par taille. Vous identifierez en trente secondes les trois fichiers qui pèsent le plus lourd. C'est là qu'il faut agir en premier.
Le plan d'action, dans l'ordre
Par rapport gain / effort :
- Compressez vos images et passez-les en WebP. Gain typique : 50 à 80 % du poids total de la page. Effort : quelques heures.
- Activez le cache serveur et navigateur. Gain : souvent un facteur trois à dix sur le TTFB. Effort : une heure.
- Activez la compression Gzip ou Brotli. Gain : 60 à 80 % sur le HTML, le CSS et le JavaScript. Effort : un réglage.
- Supprimez les scripts inutiles et les appels vers des services morts. Gain : variable, parfois spectaculaire.
- Désinstallez les plugins non utilisés. Pas seulement désactivés — supprimés.
- Mettez en place un CDN pour servir les fichiers statiques depuis un point proche du visiteur. C'est la vraie réponse technique à la latence, et elle coûte souvent moins qu'un serveur local.
- Nettoyez la base de données.
- Alors seulement, envisagez de changer d'hébergement ou de passer sur un VPS dédié si les mesures le justifient.
Dans notre expérience, les cinq premiers points résolvent l'essentiel des plaintes de lenteur, sans changer une ligne d'infrastructure.
Questions fréquentes
Un CDN remplace-t-il un serveur local ?
Pour les fichiers statiques — images, CSS, JavaScript — oui, largement : ils sont servis depuis un point de présence proche du visiteur. Pour le HTML généré dynamiquement, non : la requête remonte toujours au serveur d'origine. Un CDN bien configuré avec du cache de page peut cependant couvrir aussi ce cas.
Pourquoi mon site est-il rapide chez moi et lent chez mes clients ?
Parce que votre navigateur a mis en cache toutes les ressources. Vous ne voyez que les visites répétées. Testez en navigation privée, ou videz le cache, pour voir ce que voit un nouveau visiteur.
Le VPS est-il plus rapide que le mutualisé ?
Pas intrinsèquement. Un VPS vous donne des ressources garanties et évite les voisins encombrants. Mais un VPS mal configuré est souvent plus lent qu'un mutualisé de qualité, parce que personne n'a réglé le cache, PHP ni la base de données. Le VPS se justifie quand vous atteignez les limites de ressources, pas comme solution magique.
Combien de secondes est-ce acceptable ?
Sur mobile, viser moins de 3 secondes pour l'affichage du contenu principal. Au-delà de 5 secondes, une part importante des visiteurs abandonne. Sur un marché où la connexion est déjà limitée, cette exigence est plus forte, pas moins.
Notre proposition est simple : mesurons avant de dépenser.
Envoyez-nous l'adresse de votre site. Nous mesurons le TTFB, le poids réel de vos pages et le nombre de requêtes, et nous vous disons franchement si votre problème est votre hébergement ou votre site. Si c'est votre site, changer d'hébergeur ne vous servira à rien — et nous vous le dirons.
Si vos mesures justifient un changement, voyez notre hébergement mutualisé avec cache LiteSpeed, ou nos VPS Linux pour les projets qui ont besoin de ressources garanties.
Vous envisagez de migrer ? Lisez d'abord comment changer d'hébergeur sans perdre votre référencement ni vos emails.
Sources : DataReportal — Digital 2025 Cameroon et Digital 2024 Cameroon pour les vitesses de connexion médianes et la répartition mobile/fixe.
