Concevoir un site rapide depuis Mayotte : nos astuces face à la latence sous-marine.

Mayotte est connectée au reste du monde par le câble sous-marin EASSy (Eastern Africa Submarine System). Ce câble relie l'île à l'Afrique du Sud avant de remonter vers l'Europe. Résultat : une requête entre un internaute mahorais et un serveur hébergé à Paris génère 150 à 250 ms de latence réseau — avant même que le serveur commence à répondre.

C'est le double de ce qu'on observe en métropole. Et c'est incompressible : c'est la physique du câble. Mais on peut la compenser. Voici nos quatre leviers techniques.

Levier 1 — Choisir le bon hébergement avec un CDN

L'erreur classique : héberger un site à destination d'une audience mahoraise sur un serveur mutualisé à Paris. Chaque ressource — HTML, CSS, JavaScript, images — doit traverser le câble EASSy pour chaque visiteur, à chaque visite.

La solution : utiliser un CDN (Content Delivery Network) qui met en cache les ressources sur des serveurs géographiquement proches. Vercel, Cloudflare et AWS CloudFront disposent de points de présence en Afrique de l'Est (Nairobi, Johannesburg) qui réduisent considérablement la latence pour les utilisateurs mahorais.

Levier 2 — Optimiser chaque image avant de la mettre en ligne

Les images représentent en moyenne 60 à 70 % du poids d'une page web. À Mayotte, où la connexion peut être instable, chaque kilooctet compte. On applique systématiquement trois règles sur tous nos projets :

• ✓Conversion en WebP ou AVIF : 30 à 50 % plus léger que le JPEG à qualité visuelle équivalente
• ✓Dimensionnement adaptatif : les attributs srcset et sizes servent la bonne taille selon l'écran
• ✓Lazy loading : les images hors de l'écran sont chargées uniquement quand l'utilisateur scrolle jusqu'à elles

Levier 3 — Réduire le JavaScript avec le code splitting

Les frameworks JavaScript modernes peuvent générer des bundles très lourds si on n'y prend pas garde. On pratique systématiquement le code splitting : seul le code nécessaire à la page affichée est chargé immédiatement. Le reste est récupéré à la demande, en arrière-plan.

On supprime aussi les dépendances inutilisées et on diffère le chargement des scripts non critiques — analytics, scripts de chat, widgets tiers — après le premier rendu de la page. L'utilisateur voit le contenu rapidement, même si les fonctionnalités secondaires chargent encore.

Levier 4 — Exploiter le cache navigateur et le cache serveur

Un visiteur qui revient sur votre site ne devrait pas retélécharger ce qu'il a déjà chargé lors de sa première visite. On configure des en-têtes de cache agressifs pour les ressources statiques : CSS, JavaScript, polices, images peuvent être mis en cache pendant 30 jours ou plus.

On active aussi le cache côté serveur (Static Site Generation ou Incremental Static Regeneration sur Next.js) pour que les pages HTML soient précalculées et servies instantanément, sans attendre une génération dynamique à chaque requête.

Ce que ça change concrètement

Sur les projets que nous avons livrés à Mayotte, ces quatre optimisations permettent d'atteindre un score Lighthouse Performance supérieur à 85/100, et un LCP (Largest Contentful Paint) inférieur à 2,5 secondes — même depuis une connexion 4G mahoraise.

La performance web n'est pas un luxe technique. C'est un facteur SEO direct via les Core Web Vitals de Google, et un facteur d'expérience utilisateur qui détermine si vos visiteurs restent ou repartent.

Ces seuils correspondent aux recommandations Google pour les Core Web Vitals — en dessous, le site risque d'être pénalisé dans les résultats de recherche. La performance est donc à la fois un enjeu d'expérience utilisateur et de référencement. Les deux sont indissociables.