Ce que vous saurez faire
- Comprendre LCP, INP, CLS
- Mesurer avec Lighthouse et web-vitals
- Optimiser chaque métrique
- Monitoring RUM continu
Étape 1 — Les 3 métriques
LCP Largest Contentful Paint < 2.5s
Temps d'affichage de l'élément principal
INP Interaction to Next Paint < 200ms
Réactivité aux interactions
CLS Cumulative Layout Shift < 0.1
Stabilité visuelle (pas de décalages)
Étape 2 — Mesurer avec Lighthouse
npx lighthouse https://example.sn --only-categories=performance --view
# Audit plus proche réalité
npx lighthouse https://example.sn --preset=desktop \
--throttling.cpuSlowdownMultiplier=4
Étape 3 — web-vitals pour RUM
// Dans index.html
import {onCLS, onINP, onLCP} from 'web-vitals';
function send(metric) {
navigator.sendBeacon('/api/vitals', JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
url: location.href,
}));
}
onCLS(send);
onINP(send);
onLCP(send);
Étape 4 — Optimiser LCP
<!-- Précharger l'image LCP -->
<link rel="preload" as="image"
href="/wp-content/uploads/hero.avif"
fetchpriority="high"
imagesrcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
imagesizes="100vw">
<!-- Image LCP: PAS de lazy -->
<img src="hero.webp" fetchpriority="high" alt="..." width="1200" height="600">
Étape 5 — WebP/AVIF
apt install -y webp libheif-examples
for f in *.{jpg,png}; do
cwebp -q 82 "$f" -o "${f%.*}.webp"
heif-enc -q 55 "$f" -o "${f%.*}.avif"
done
Étape 6 — Optimiser INP
// Mauvais: bloque UI
function calculerGros() {
for (let i = 0; i < 1000000; i++) { /* ... */ }
}
// Bon: scheduler.postTask
async function calculerChunk() {
const scheduler = window.scheduler;
for (let i = 0; i < 10; i++) {
await scheduler.postTask(() => {
for (let j = 0; j < 100000; j++) { /* ... */ }
}, { priority: 'background' });
}
}
<!-- Différer JS non critique -->
<script src="/chat.js" defer></script>
<script src="/analytics.js" async></script>
Étape 7 — Optimiser CLS
<!-- TOUJOURS width + height -->
<img src="photo.webp" width="1200" height="800" alt="...">
<!-- Embeds: container fixe -->
<style>
.ad-slot { min-height: 250px; display: grid; place-items: center; }
img { aspect-ratio: attr(width) / attr(height); height: auto; max-width: 100%; }
</style>
<!-- Fonts: swap ou optional -->
<style>
@font-face {
font-family: 'Inter';
src: url('/fonts/Inter.woff2') format('woff2');
font-display: swap;
size-adjust: 100%;
}
</style>
Étape 8 — Lazy native
<img src="galerie.avif" loading="lazy" decoding="async" alt="...">
<iframe src="..." loading="lazy" width="560" height="315"></iframe>
Étape 9 — Picture pour format moderne
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="..." width="1200" height="800" loading="lazy">
</picture>
Étape 10 — Cache serveur + CDN
location ~* \.(avif|webp|jpg|png|svg|css|js|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
access_log off;
}
Cloudflare activation:
- Auto Minify JS/CSS/HTML
- Brotli
- Tiered Cache
- Cloudflare APO for WordPress (5 USD/mo)
Étape 11 — GitHub Actions Lighthouse CI
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
uploadArtifacts: true
Étape 12 — Monitoring Search Console
Search Console > Expérience > Core Web Vitals. Passage rouge/orange au vert après 2-4 semaines. Cliquez Valider la correction après optim.
Checklist
✓ Images AVIF/WebP + width/height + fetchpriority LCP
✓ Fonts woff2 + swap, 2 max
✓ JS différé ou dynamic import
✓ CSS critique inline, reste différé
✓ Cache 1 an assets versionnés
✓ Brotli activé
✓ CDN avec PoPs Afrique (Cloudflare)
✓ RUM monitoring (web-vitals + GA4)
✓ Lighthouse CI sur chaque PR
Pour ne pas tout faire vous-même
Notre équipe conçoit votre site, met en place domaine et hébergement, vous forme à la gestion, et reste joignable 6 mois pour les questions techniques.
À partir de 350 000 FCFA
Étape 1 — Mesurer l’état initial avec PageSpeed Insights
Avant toute optimisation, il faut un point de référence chiffré. Ouvrez pagespeed.web.dev, entrez l’URL du site, attendez 30 secondes. Notez les trois métriques Core Web Vitals : LCP (Largest Contentful Paint, cible < 2,5 s), INP (Interaction to Next Paint, cible < 200 ms), CLS (Cumulative Layout Shift, cible < 0,1).
# Audit en ligne de commande pour automatiser
npm install -g lighthouse
lighthouse https://votresite.com --only-categories=performance --form-factor=mobile --output=json --output-path=./baseline.json
jq '.audits["largest-contentful-paint"].numericValue' baseline.json
Pour un site testé depuis Dakar via une connexion 4G Orange ou Mixx by Yas, la métrique mobile est la seule qui compte : 80 % du trafic ouest-africain est mobile. Si votre LCP mobile dépasse 4 secondes, vous perdez un visiteur sur deux dès la première seconde.
Étape 2 — Choisir un hébergement avec edge en Europe
L’origine du serveur conditionne le LCP. Un mutualisé bon marché aux États-Unis ajoute 200 ms de latence aller-retour vers Dakar par rapport à un VPS Hetzner Helsinki ou OVH Gravelines. C’est le levier qui se voit sans changer une ligne de code.
ping -c 5 votresite.com
# Bonne valeur depuis Dakar : 80-120 ms (Europe)
# Mauvaise valeur : 200+ ms (USA), 300+ ms (Asie)
curl -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://votresite.com
Cible TTFB en deçà de 600 ms pour viser un bon LCP. Au-delà, aucun cache navigateur ni optimisation d’image ne sauvera la note. Un VPS Hetzner CX21 à 5,80 EUR/mois (≈ 3 805 FCFA) avec OpenLiteSpeed ou Plesk donne un TTFB de 200 ms vers Dakar, suffisant pour viser le vert.
Étape 3 — Activer un cache full-page
WordPress génère chaque page côté PHP, ce qui consomme 200 à 800 ms de TTFB. Un cache full-page sert le HTML statique en moins de 50 ms. Trois options gratuites en 2026 : LiteSpeed Cache (si vous êtes sur OpenLiteSpeed), W3 Total Cache (universel), WP Super Cache (Automattic, simple).
# LiteSpeed Cache > Cache > activer toutes les options par défaut
# Réglages > Permaliens > Re-générer les rewrite rules
# Test : deux requêtes successives sur la même URL
curl -I https://votresite.com | grep x-litespeed-cache
# Première requête : x-litespeed-cache: miss
# Deuxième requête : x-litespeed-cache: hit
Mesurez le TTFB après activation, vous devez gagner 300 à 600 ms d’un coup. Pour un site WooCommerce, désactivez le cache sur les pages panier, compte et checkout, sinon le client verra le panier d’un autre visiteur.
Étape 4 — Optimiser les images (format, taille, lazy loading)
Les images représentent 60 % du poids moyen d’une page WordPress. Le triple combo gagnant : format WebP ou AVIF, dimensionnement aux tailles réellement affichées, lazy loading natif. WordPress 6.x ajoute déjà loading="lazy" par défaut depuis 2022, vérifiez juste qu’il n’a pas été désactivé.
# Plugin recommandé : ShortPixel ou Imagify
# Settings > Bulk Optimize tous les médias en WebP
# Vérifier qu'une image responsive sert la bonne taille
<img src="hero-1024.webp" srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1024.webp 1024w" sizes="(max-width: 768px) 100vw, 50vw" alt="..." loading="lazy" decoding="async">
Pour la première image au-dessus de la ligne de flottaison (souvent le hero), retirez loading="lazy" et ajoutez plutôt fetchpriority="high". Cette image c’est précisément le LCP : elle doit charger en priorité absolue.
Étape 5 — Réduire le JavaScript bloquant pour améliorer l’INP
L’INP (Interaction to Next Paint) a remplacé le FID en 2024. Il mesure la réactivité aux clics, taps, frappes. Sur WordPress, le coupable habituel est l’accumulation de plugins qui injectent chacun leur JS dans le head. Un site type chargé de 15 plugins peut atteindre 800 ms d’INP, soit le rouge complet.
# Identifier les scripts les plus lourds
# DevTools Chrome > Performance > Record > clic réel sur un bouton
# Repérer les long tasks > 50 ms
# Plugin Asset CleanUp permet de désactiver script par script et par URL
Le réflexe : désactiver Elementor sur les pages qui ne l’utilisent pas, charger Google Analytics en defer, retirer les sliders JavaScript jamais utilisés. Mesurez après chaque modification : un seul plugin retiré peut faire gagner 200 ms d’INP.
Étape 6 — Stabiliser la mise en page pour le CLS
Le CLS pénalise les bonds de mise en page après le chargement initial. Causes typiques sur WordPress : images sans dimensions explicites, pubs Google AdSense qui apparaissent tardivement, polices web qui changent de glyphe au chargement (FOUT).
<!-- Toujours déclarer width et height sur les images -->
<img src="produit.webp" width="600" height="400" alt="...">
<!-- Réserver l'espace pour les pubs -->
<div style="min-height:250px"><ins class="adsbygoogle" ...></ins></div>
<!-- font-display: swap pour éviter le FOIT mais peut causer FOUT -->
@font-face { font-family: 'Inter'; src: url(...) format('woff2'); font-display: swap; }
Pour un CLS sous 0,05 (excellent), pré-chargez les polices critiques avec <link rel="preload" as="font" type="font/woff2" crossorigin>. La police s’affiche dès le premier paint et le glyphe ne change plus.
Étape 7 — Mettre Cloudflare devant WordPress
Cloudflare gratuit ajoute un cache edge dans 300 datacenters mondiaux dont Lagos, Marseille, Casablanca et Le Cap. Pour un visiteur ouest-africain, la latence vers Marseille via fibre Africa Coast to Europe descend à 50-80 ms, soit la moitié d’un trajet direct vers Helsinki.
# DNS > basculer les enregistrements A et AAAA en mode Proxied (orange)
# Speed > Optimization > activer Auto Minify HTML, CSS, JS
# Speed > Optimization > activer Brotli
# Caching > Configuration > Browser Cache TTL : 1 month
# Page Rules > Cache Everything sur /wp-content/uploads/*
Pensez à exclure du cache /wp-admin/* et /wp-login.php, sinon vous risquez des problèmes de connexion. La règle gratuite Cloudflare suffit. Bénéfice mesuré : LCP de 3,8 s à 2,1 s sur un site testé depuis Cotonou en mai 2025.
Étape 8 — Précharger les ressources critiques
Le navigateur découvre les ressources au fur et à mesure du parsing HTML. On peut anticiper en préchargeant explicitement la police et l’image hero dès le début du <head>, ce qui économise 100 à 300 ms sur le LCP.
<link rel="preload" href="/wp-content/uploads/2026/01/hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="/wp-content/themes/votretheme/fonts/Inter-700.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Insérez ces balises via le plugin WPCode ou directement dans functions.php via le hook wp_head. Mesurez avant/après : le LCP gagne typiquement 15 à 25 % sur un site bien construit.
Étape 9 — Suivre les Core Web Vitals dans la durée
Une mesure unique sur PageSpeed Insights donne une photo. Pour suivre l’évolution réelle vue par les vrais utilisateurs (RUM, Real User Monitoring), Google Search Console publie le rapport Expérience > Core Web Vitals à partir des données Chrome User Experience Report (CrUX).
# Search Console > Expérience > Core Web Vitals
# Filtrer Mobile pour voir les données clés
# Onglet "URL avec problèmes" > exporter en CSV
# Refaire un audit Lighthouse sur les 10 pires URLs
Le CrUX se met à jour mensuellement avec 28 jours de données glissantes. Soyez patient : une optimisation passe au vert dans Search Console 4 à 6 semaines après le déploiement, le temps que Google accumule assez de mesures réelles.
Étape 10 — Coût d’une optimisation Core Web Vitals professionnelle
Un audit complet plus mise en œuvre par un freelance compétent à Dakar coûte entre 200 000 et 500 000 FCFA selon la taille du site (5 à 50 pages auditées). Le ROI est mesurable : un e-commerce qui passe de LCP 4,5 s à 2,2 s voit typiquement +15 à +25 % de taux de conversion mobile, donc un retour sur investissement en 2 à 4 mois.
Pour explorer plus loin, voir notre guide LiteSpeed Cache pas à pas et notre configuration Cloudflare pour WordPress.
Étape 11 — Différer les scripts tiers (analytics, chat, pubs)
Les scripts tiers (Google Tag Manager, Facebook Pixel, Crisp, AdSense) plombent l’INP plus que tout autre facteur. Ils s’exécutent sur le thread principal et bloquent les interactions pendant des centaines de millisecondes. La règle pratique : tout ce qui n’est pas vital pour l’affichage doit être chargé en defer ou via Partytown.
<!-- Defer simple -->
<script defer src="https://www.googletagmanager.com/gtag/js?id=G-XXX"></script>
<!-- Mieux : déplacer dans un Web Worker via Partytown -->
<script src="/~partytown/partytown.js"></script>
<script type="text/partytown">
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('config', 'G-XXX');
</script>
Le plugin WordPress « WP Rocket » 3.16+ propose un toggle Delay JavaScript Execution qui retarde tous les scripts non critiques jusqu’à la première interaction utilisateur. Bénéfice mesuré : INP passant de 450 ms à 180 ms sur un site WooCommerce moyen, sans perte de tracking analytique car les événements sont rejoués au moment du clic.
Étape 12 — Surveiller les régressions à chaque mise à jour
Une mise à jour de plugin ou de thème peut tout casser sans prévenir. Pour éviter de découvrir la régression deux semaines plus tard via Search Console, branchez un audit Lighthouse automatisé qui s’exécute après chaque déploiement et alerte si le score chute.
# GitHub Actions / Gitea Actions
- name: Lighthouse CI
run: |
npm install -g @lhci/cli
lhci autorun --collect.url=https://votresite.com --assert.assertions.performance=0.85 --assert.assertions."largest-contentful-paint"="<2500"
L'action plante si la performance descend sous 0,85 ou si le LCP dépasse 2,5 secondes. Vous bloquez ainsi un déploiement avant qu'il ne dégrade l'expérience client. Couplez avec une notification Slack ou Telegram pour que l'équipe voie immédiatement la régression et son auteur.