Core Web Vitals : Comment Promto fait passer tous ses clients au vert sur Google
Ouvrez Google Search Console. Regardez l'onglet "Core Web Vitals". Voyez-vous des URL en rouge ou en jaune ?
Si oui, Google pénalise votre site. Pas théoriquement. Concrètement. Vos pages rankent moins bien à cause de ces scores.
Chez Promto.be, on ne livre que des sites au vert. Voici comment.
Les 3 Core Web Vitals expliqués simplement
LCP (Largest Contentful Paint)
"Combien de temps avant que le contenu principal soit visible ?"
C'est le temps qu'il faut pour que l'élément le plus grand de la page (souvent une image ou un titre) apparaisse.
| Score | Signification |
|---|---|
| < 2.5s | Bon (vert) |
| 2.5s - 4s | À améliorer (jaune) |
| > 4s | Mauvais (rouge) |
Ce qui ralentit le LCP :
- Serveur lent
- Images non optimisées
- CSS bloquant
- JavaScript qui bloque le rendu
Notre solution Promto.be :
- SSG (Static Site Generation) = pas de calcul serveur
- Images Next.js = WebP, redimensionnement, lazy loading
- CSS minimal = pas de feuilles de style inutiles
- Pas de JS bloquant dans le
<head>
Résultat typique : 0.5s - 1.2s
INP (Interaction to Next Paint)
"Le site réagit-il rapidement quand je clique ?"
INP remplace FID (First Input Delay) depuis 2024. Il mesure la réactivité globale du site aux interactions (clics, taps, touches clavier).
| Score | Signification |
|---|---|
| < 200ms | Bon (vert) |
| 200ms - 500ms | À améliorer (jaune) |
| > 500ms | Mauvais (rouge) |
Ce qui ralentit l'INP :
- JavaScript lourd qui bloque le thread principal
- Calculs complexes côté client
- Animations non optimisées
- Third-party scripts (chat, analytics, ads)
Notre solution Promto.be :
- Code splitting automatique = chaque page charge le JS minimum
- Server Components = moins de JS envoyé au navigateur
- Third-party scripts chargés de manière différée
- Pas de plugin lourd qui tourne en arrière-plan
Résultat typique : 50ms - 150ms
CLS (Cumulative Layout Shift)
"Est-ce que la page bouge pendant qu'elle charge ?"
C'est le score de stabilité visuelle. Quand une image se charge et pousse le texte vers le bas, c'est un layout shift.
| Score | Signification |
|---|---|
| < 0.1 | Bon (vert) |
| 0.1 - 0.25 | À améliorer (jaune) |
| > 0.25 | Mauvais (rouge) |
Ce qui cause le CLS :
- Images sans dimensions définies
- Polices qui changent de taille au chargement
- Publicités qui s'insèrent dynamiquement
- Contenu injecté après le chargement initial
Notre solution Promto.be :
- Dimensions d'image définies dans le HTML = espace réservé
- Font optimization = pas de flash de texte
- Pas de publicités tierces
- Pas de pop-ups qui bougent le contenu
Résultat typique : 0 - 0.05
Notre méthode en 5 étapes
Étape 1 : Audit initial
Avant de coder quoi que ce soit, on teste l'existant (si migration) ou on définit les objectifs (si nouveau site).
Outils utilisés :
- PageSpeed Insights (le référence)
- Google Search Console (données réelles)
- WebPageTest (analyse détaillée)
- Lighthouse CI (tests automatisés)
Étape 2 : Architecture optimisée
On choisit la stratégie de rendu appropriée :
- SSG pour les pages statiques (accueil, services, blog)
- SSR pour les pages dynamiques (si nécessaire)
- ISR pour les mises à jour fréquentes sans rebuild total
Étape 3 : Optimisation des ressources
Images :
- Format WebP/AVIF
- Dimensions adaptées
- Lazy loading
- Placeholder blur
Polices :
- Sous-ensemble de caractères (subsetting)
- Préchargement
- Font-display: swap
JavaScript :
- Code splitting
- Tree shaking
- Chargement différé des scripts tiers
CSS :
- CSS minimal
- Pas de frameworks CSS lourds inutiles
- Critical CSS inline
Étape 4 : Tests continus
À chaque étape du développement, on mesure :
- Build time
- Bundle size
- PageSpeed score
- Core Web Vitals
Pas de surprise en production.
Étape 5 : Vérification post-livraison
Après le déploiement, on vérifie :
- PageSpeed Insights mobile ET desktop
- Google Search Console (section Core Web Vitals)
- Chrome User Experience Report (données réelles)
Si un score n'est pas au vert, on corrige. Immédiatement.
Les résultats réels
| Métrique | Avant (WordPress) | Après (Promto.be) |
|---|---|---|
| LCP | 3.8s | 0.7s |
| INP | 450ms | 80ms |
| CLS | 0.35 | 0.02 |
| PageSpeed mobile | 38 | 97 |
| PageSpeed desktop | 65 | 99 |
Ces chiffres ne sont pas des exceptions. C'est la norme pour chaque site qu'on livre.
Les erreurs qu'on voit chez les concurrents
"On optimisera après"
Faux. La performance est une fondation, pas une couche de finition. Un site mal architecturé ne sera jamais rapide, même avec 10 plugins de cache.
"Le score desktop suffit"
Faux. Google indexe mobile-first. Le score mobile est celui qui compte pour le ranking.
"C'est le hosting"
Partiellement vrai. Mais un bon hosting ne compensera jamais un site mal codé. Un site Next.js statique est rapide même sur un hosting basique.
"On a un plugin de cache"
Un plugin de cache sur WordPress compense une architecture lente. C'est un pansement sur une jambe cassée. Next.js n'a pas besoin de cache parce qu'il est natiflement rapide.
La garantie Promto.be
On s'engage formellement :
Score PageSpeed Insights mobile ≥ 90
LCP < 1.5s
INP < 200ms
CLS < 0.1
Si ces objectifs ne sont pas atteints à la livraison, on corrige gratuitement jusqu'à ce qu'ils le soient.
C'est possible parce qu'on maîtrise la stack. Pas parce qu'on a de la chance.
Conclusion
Les Core Web Vitals ne sont pas des indicateurs techniques abstraits. Ce sont les critères que Google utilise pour décider si votre site mérite d'être en première page.
Un site au vert = plus de visibilité. Un site au rouge = invisibilité progressive.
Next.js nous permet d'atteindre le vert systématiquement. Pas avec des hacks, pas avec des plugins miracles. Avec une architecture conçue pour la performance.
Chez Promto.be, le vert n'est pas un objectif. C'est la norme.