Prérequis

Niveau : bases admin serveur (Nginx ou Apache) + accès au code/CMS.
Outils : Lighthouse, PageSpeed Insights, WebPageTest, Cloudflare (gratuit), terminal.
Temps estimé : 2-4 h pour un audit complet et premières corrections.

Pourquoi la vitesse pour le SEO ?

Depuis 2021, Google utilise les Core Web Vitals (LCP, INP, CLS) comme facteur de classement. Un site rapide ranke mieux ET convertit mieux : chaque seconde gagnée sur le LCP fait baisser le taux de rebond de 7 % en moyenne. C’est l’un des leviers SEO à plus haut ROI.

Ce que vous saurez faire

Mesurer avant optimiser
WebP/AVIF + lazy
Cache agressif Nginx
CSS/JS optimisés

Vue d’ensemble 1 — Mesurer

npx lighthouse https://example.sn --only-categories=performance --view

# Cibles Core Web Vitals:
# LCP < 2.5s | INP < 200ms | CLS < 0.1

Vue d’ensemble 2 — Images WebP/AVIF

apt install -y webp
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

# AVIF
npm i -g sharp-cli
sharp -i img.jpg -o img.avif -q 55 --format avif

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="600"
       loading="lazy" decoding="async" fetchpriority="high">
</picture>

Vue d’ensemble 3 — Préchargement critique

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<link rel="dns-prefetch" href="https://cdn.example.sn">

Vue d’ensemble 4 — Cache HTTP Nginx

location ~* \.(woff2|avif|webp|jpg|png|svg|css|js)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

location ~* \.html$ {
  add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";
}

gzip on;
gzip_types text/css application/javascript application/json text/xml;

brotli on;
brotli_types text/css application/javascript application/json text/xml;

Vue d’ensemble 5 — CSS critique inline

<!-- <head> : CSS 1er écran -->
<style>
  :root{--brand:#1E88E5}
  body{font-family:system-ui;margin:0}
  .hero{min-height:70vh;background:#f5f5f7;display:grid;place-items:center}
</style>

<!-- CSS complet différé -->
<link rel="preload" href="/style.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/style.css"></noscript>

Vue d’ensemble 6 — JS différé

<script src="/app.js" defer></script>
<script src="/analytics.js" async></script>

<!-- Dynamic import conditionnel -->
<script type="module">
  if (location.pathname === "/checkout") {
    await import("/checkout-bundle.js");
  }
</script>

Vue d’ensemble 7 — Analyser bundle

npx source-map-explorer dist/app.*.js
npx vite-bundle-visualizer
# Identifier libs lourdes: moment-timezone, lodash

Vue d’ensemble 8 — CDN Cloudflare

Cloudflare:
- Always Online
- Auto Minify JS/CSS/HTML
- Brotli
- HTTP/3 (QUIC)
- Cache level: Standard
- Browser TTL: 1 month

Pour Afrique: PoPs Lagos, Mombasa, Johannesburg

Vue d’ensemble 9 — Base de données

-- Identifier requêtes lentes (PostgreSQL)
ALTER SYSTEM SET log_min_duration_statement = 500;
SELECT pg_reload_conf();

-- Stats
CREATE EXTENSION pg_stat_statements;
SELECT query, calls, mean_exec_time, rows
FROM pg_stat_statements
ORDER BY mean_exec_time DESC LIMIT 10;

-- Index manquant
CREATE INDEX idx_articles_publie_at ON articles(publie_at DESC)
  WHERE statut = 'publie';

Vue d’ensemble 10 — Images responsive

<img src="produit-800.webp"
     srcset="produit-400.webp 400w,
             produit-800.webp 800w,
             produit-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 50vw,
            800px"
     alt="..." width="800" height="600" loading="lazy">

Vue d’ensemble 11 — Monitoring CI Lighthouse

name: Perf
on: pull_request
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: treosh/lighthouse-ci-action@v12
        with:
          urls: https://preview.example.sn
          configPath: .lighthouserc.json

Vue d’ensemble 12 — Résultats attendus

Avant → Après optimisations:
Poids total: -40 à -60%
LCP mobile: -1 à -2 secondes
Score Pagespeed: +15 à +30 points
Passage Core Web Vitals: rouge → vert sous 2-4 semaines

Erreurs fréquentes

Optimiser sans mesurer

Cause : on installe 3 plugins « speed booster » au pif.
Solution : mesurez d’abord avec Lighthouse + PageSpeed, identifiez les 3 plus gros problèmes, attaquez-les un par un.

Cache HTML trop agressif

Cause : on cache l’HTML 1 an → contenu obsolète chez les visiteurs.
Solution : max 5-10 minutes pour l’HTML, 1 an pour les assets statiques (images, CSS, JS avec hash).

Lazy loading sur l’image hero

Cause : on met loading="lazy" partout.
Solution : loading="eager" + fetchpriority="high" sur l’image LCP.

Bundle JS énorme inutilisé

Cause : on importe moment ou lodash en entier pour 1 fonction.
Solution : imports nommés (import { format } from 'date-fns'), tree-shaking, bundle analyzer.

Lectures complémentaires

Optimiser les performances générales
Lazy loading images
Référence : web.dev — Core Web Vitals
Outil : PageSpeed Insights et WebPageTest
Cache CDN : Cloudflare (gratuit)

La vitesse de chargement, signal SEO devenu non negociable

A Lome, une boutique en ligne de fournitures bureautiques perdait 60 % de ses visiteurs avant meme que la page d’accueil n’affiche son catalogue. Le diagnostic PageSpeed Insights revelait un Largest Contentful Paint de 5,8 secondes sur connexion 4G. Apres optimisation, l’indicateur est passe a 1,9 seconde, le taux de rebond a chute de 18 points et le trafic organique a augmente de 34 % en deux mois.

Depuis 2021, Google integre les Core Web Vitals dans son algorithme de classement. Les seuils officiels en 2026 : Largest Contentful Paint sous 2,5 s, Interaction to Next Paint sous 200 ms, Cumulative Layout Shift sous 0,1. Atteindre ces seuils est moins une question de budget qu’une question de methode rigoureuse.

Etape 1 : Mesurer l’etat de depart avec PageSpeed Insights

Avant toute optimisation, etablissez la base de comparaison. Ouvrez pagespeed.web.dev, saisissez l’URL la plus consultee de votre site, et lancez l’analyse. PageSpeed Insights fournit deux jeux de donnees : les donnees de terrain CrUX (vrais utilisateurs Chrome sur 28 jours) et les donnees de laboratoire Lighthouse (simulation contrôlee).

Notez chaque metrique : LCP, INP, CLS, First Contentful Paint, Time to First Byte. Capturez la liste des opportunites en bas du rapport, classees par millisecondes economisables. Cette photo initiale servira de point de comparaison apres chaque vague d’optimisation.

Etape 2 : Optimiser les images avant tout

Les images representent en moyenne 50 a 70 % du poids d’une page. La regle d’or : servir le bon format, dans la bonne taille, avec le bon attribut. Convertissez vos JPG et PNG en WebP, qui reduit le poids de 25 a 35 % a qualite equivalente. AVIF descend encore plus bas mais reste mieux supporte sur Chrome et Firefox que sur Safari ancien.

# Convertir un dossier d'images en WebP avec cwebp
cwebp -q 80 photo.jpg -o photo.webp

# Batch sur tout un repertoire
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

Apres conversion, declarez les dimensions intrinseques sur chaque balise img (width et height) pour eviter le decalage de mise en page. Activez loading= »lazy » sur toutes les images sous la ligne de flottaison. Sur WordPress, des extensions comme ShortPixel, Imagify ou Smush automatisent la conversion et le redimensionnement responsive.

Etape 3 : Activer la compression Brotli ou Gzip

La compression au niveau du serveur reduit de 70 a 80 % le poids du HTML, du CSS et du JavaScript. Brotli, plus efficace que Gzip de 15 a 25 %, est supporte par tous les navigateurs modernes. Sur Nginx, ajoutez dans le bloc http :

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

gzip on;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

Apres rechargement de Nginx, testez avec curl -H « Accept-Encoding: br » -I https://exemple.sn. La reponse doit inclure Content-Encoding: br. Sur Apache, le module mod_brotli s’active via a2enmod brotli.

Etape 4 : Mettre en cache cote navigateur et cote serveur

Les ressources statiques (CSS, JS, images, polices) doivent etre servies avec un Cache-Control long pour eviter de les retelecharger a chaque visite. Une duree d’un an convient des que le nom de fichier integre un hash de versioning (style.a1b2c3.css).

# Configuration Nginx
location ~* \.(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

Cote serveur, activez un cache de page (LiteSpeed Cache, WP Rocket, Varnish, ou le cache Cloudflare). Le Time to First Byte chute alors typiquement de 800 ms a 80 ms. Sur Cloudflare, l’option Cache Everything avec un Edge Cache TTL de 2 heures convient bien aux blogs WordPress.

Etape 5 : Differer le JavaScript non critique

Le JavaScript bloque le rendu et retarde l’INP. Auditez vos scripts via DevTools > Coverage : tout script utilise a moins de 30 % au chargement initial peut etre charge en defer ou en async. Les scripts d’analytics, de chat, de partage social sont des candidats evidents.

<script src="/analytics.js" defer></script>
<script src="/chat-widget.js" async></script>

defer execute le script apres le parsing HTML, dans l’ordre de declaration. async execute des que le telechargement est termine, sans garantie d’ordre. Pour les scripts tiers vraiment lourds (chat, replays, heatmaps), envisagez Partytown qui les execute dans un Web Worker isole du thread principal.

Etape 6 : Reduire le CSS bloquant et inline le critical CSS

Une feuille de style externe bloque le rendu jusqu’a son telechargement complet. La technique du critical CSS consiste a inline directement dans le head le CSS necessaire au rendu de la zone visible (above the fold), puis charger le reste de maniere asynchrone.

<style>/* CSS critique inline, environ 10 a 15 Ko */</style>
<link rel="preload" href="/styles.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

Des outils comme Critical (npm), PurgeCSS ou l’extension WordPress Autoptimize automatisent cette extraction. Le gain typique sur le LCP est de 400 a 800 ms sur une connexion mobile en zone Sandaga ou Marcory.

Etape 7 : Charger les polices web sans bloquer le rendu

Les Google Fonts ou polices auto-hebergees ralentissent souvent le LCP. La parade : preload de la police principale, font-display: swap dans le @font-face, et auto-hebergement pour eviter une connexion DNS supplementaire vers fonts.gstatic.com.

<link rel="preload" href="/fonts/Inter-Regular.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: 'Inter';
  src: url('/fonts/Inter-Regular.woff2') format('woff2');
  font-display: swap;
  font-weight: 400;
}

font-display: swap affiche immediatement la police systeme puis bascule vers la police custom une fois chargee. Le decalage visuel (FOUT) est preferable au texte invisible (FOIT) qui penalise le LCP.

Etape 8 : Activer un CDN proche des utilisateurs

Pour un site heberge en Europe consulte depuis Dakar, Abidjan ou Cotonou, la latence reseau ajoute facilement 200 a 400 ms. Un CDN comme Cloudflare, Bunny.net ou Fastly possede des points de presence en Afrique de l’Ouest (Lagos, Johannesburg, Le Cap) et reduit drastiquement le TTFB pour les visiteurs locaux.

L’activation Cloudflare se fait en pointant vos enregistrements DNS vers leurs serveurs et en activant le mode proxy (nuage orange). En complement, activez HTTP/3 et 0-RTT pour les connexions TLS reprises. Les images peuvent etre servies via Cloudflare Images ou Bunny Optimizer pour un redimensionnement et une conversion WebP/AVIF a la volee.

Etape 9 : Auditer les ressources tierces et les supprimer si possible

Chaque pixel Facebook, chaque widget de chat, chaque embed YouTube ajoute 50 a 300 ms de blocage. Listez les scripts tiers via DevTools > Network, filtre Third-party, et challengez chacun : est-il vraiment indispensable ? Si oui, peut-on le charger uniquement apres interaction utilisateur ?

Pour les videos YouTube, remplacez l’iframe natif par lite-youtube-embed qui charge l’iframe seulement au clic sur la miniature. Pour Google Analytics 4, activez le mesure server-side via Tag Manager et Cloud Run pour eviter le poids du gtag.js cote client. Notre audit SEO technique detaille les outils pour cette phase.

Etape 10 : Mesurer apres optimisation et iterer

Une semaine apres mise en production, relancez PageSpeed Insights sur les memes URLs et comparez. Les donnees CrUX prennent 28 jours pour refleter pleinement les ameliorations. En attendant, fiez-vous aux donnees laboratoire et au monitoring synthetique (SpeedCurve, Calibre, ou Lighthouse CI integre dans GitHub Actions).

Configurez un budget de performance dans votre pipeline CI : un build qui depasse 200 Ko de JavaScript ou 1500 ms de LCP echoue automatiquement. Cette discipline evite les regressions silencieuses lors d’ajouts de plugins ou de scripts marketing. Pour soumettre les URLs optimisees a Google, consultez aussi notre guide sitemap XML.

Cloudflare CDN edge pour reduire la latence depuis Dakar et Abidjan

La distance physique entre les visiteurs ouest-africains et les serveurs d’origine reste la principale cause de lenteur des sites WordPress heberges en Europe. Un site sur un serveur OVH a Strasbourg repond en moyenne en 180 a 240 millisecondes pour un utilisateur a Dakar contre 25 a 40 millisecondes pour un utilisateur parisien. Cloudflare attaque ce probleme en placant des points de presence a Lagos, Casablanca, Le Cap, Nairobi et plus recemment a Abidjan, ce qui ramene la latence ressentie sous les 50 millisecondes pour la plupart des contenus statiques.

Le plan gratuit suffit pour 80 pourcent des blogs WordPress. Il inclut le SSL universel, le cache automatique des ressources statiques (CSS, JS, images, fonts), la protection anti-DDoS de niveau 3 et 4, le firewall WAF avec 5 regles personnalisees, et l’analytics basique. Les plans Pro a 25 USD par mois (15 000 FCFA) et Business a 250 USD par mois (150 000 FCFA) ajoutent l’image polish (compression et conversion automatique en WebP/AVIF), le mobile redirection, et le support prioritaire. Pour un site qui depasse 100 000 visites par mois, le plan Pro devient pertinent surtout pour la gestion des images.

L’activation se fait en pointant les nameservers du domaine vers Cloudflare. Vous gardez votre hebergement (Hostinger, OVH, ou autre) intact, Cloudflare s’intercale en proxy. Apres propagation DNS qui prend de 5 minutes a 24 heures selon les registrars, le panel Cloudflare affiche le trafic en temps reel et vous pouvez activer Auto Minify pour HTML, CSS, JS, le mode Brotli pour la compression, et Rocket Loader si vous acceptez ses limitations sur les scripts qui dependent de jQuery.

Le piege classique sur WordPress est l’incompatibilite entre Cloudflare APO (Automatic Platform Optimization, 5 USD par mois sur le plan gratuit) et certains plugins de cache cote serveur comme W3 Total Cache ou WP Rocket. Choisissez un cache cote origine OU APO mais pas les deux : double caching cause des invalidations qui ne se propagent pas et vous voyez des contenus obsoletes pendant des heures. Pour la majorite des blogs francophones, APO seul suffit et offre un Time To First Byte sous 200 millisecondes depuis Abidjan, ce qui place le site dans le top 10 pourcent en performance par rapport a la concurrence locale.

Lazy loading natif loading= »lazy » et Server Timing API pour le diagnostic

Le lazy loading natif est supporte par tous les navigateurs modernes depuis 2020 (Chrome 76, Firefox 75, Safari 15.4). Il suffit d’ajouter loading= »lazy » sur les balises img et iframe pour que le navigateur retarde le chargement jusqu’a ce que l’element entre dans le viewport. WordPress 5.5 et superieur applique automatiquement cet attribut sur toutes les images du contenu, donc pour la plupart des sites WordPress africains vous beneficiez deja du lazy loading sans plugin tiers.

Le piege est de mal calibrer le seuil. Le lazy loading natif demarre le chargement d’une image quand elle est encore a 1 250 pixels du viewport (sur Chrome desktop), ce qui couvre la majorite des cas. Les plugins tiers comme a3 Lazy Load ou Lazy Load by WP Rocket peuvent reduire ce seuil a 200 pixels pour economiser plus de bande passante, mais cela cause des images encore en chargement quand l’utilisateur scrolle rapidement. Pour les visiteurs sur connexion 3G a Cotonou ou Bamako, le compromis ideal est entre 400 et 600 pixels.

<img
  src="https://itskillscenter.io/wp-content/uploads/photo.jpg"
  alt="Description precise"
  loading="lazy"
  decoding="async"
  width="1200"
  height="800"
>

L’attribut decoding= »async » est complementaire et indique au navigateur de decoder l’image hors du thread principal, ce qui evite les blocages de rendu. Les attributs width et height explicites sont indispensables pour eviter le Cumulative Layout Shift, un des Core Web Vitals que Google penalise depuis 2021. Un CLS superieur a 0,1 fait perdre des positions en SERP, et la cause la plus frequente est justement les images sans dimensions declarees qui font sauter le contenu pendant le chargement progressif.

La Server Timing API permet d’inspecter ou se passe le temps cote serveur depuis les DevTools du navigateur. PHP envoie un en-tete Server-Timing avec les durees de chaque etape : connexion DB, rendu du theme, requetes externes, generation du HTML. Sur WordPress, le plugin Query Monitor expose ces metriques en developpement, mais en production vous voulez une instrumentation legere via un mu-plugin de 30 lignes qui ajoute les en-tetes Server-Timing pour les 5 etapes critiques. La regle empirique est que tout serveur qui depasse 600 millisecondes de TTFB merite une investigation : opcode cache OPcache PHP active, MySQL avec un index correct sur wp_postmeta, requetes externes mises en cache dans transient.

Dans la continuité, l’API web-vitals de Google publie sur npm une bibliotheque JavaScript de 2 Ko qui mesure LCP, INP, CLS et envoie ces valeurs en temps reel a un endpoint analytics. Branchez la sortie sur Plausible Analytics (9 EUR par mois pour 10 000 visites soit 5 900 FCFA) ou sur Google Analytics 4 et vous pilotez les Core Web Vitals reels de vos visiteurs, pas seulement les notes Lighthouse synthetiques. La difference entre les deux est souvent de 20 a 40 pourcent en defaveur du terrain reel, surtout sur connexions mobiles 3G a Yopougon ou Sandaga. Voir notre guide vitesse SEO pour les autres optimisations.