Core Web Vitals : pourquoi le code personnalisé obtient 100 – et WordPress dépasse rarement 60

Les Core Web Vitals de Google sont un facteur de classement confirmé. Mais voici ce que la plupart des développeurs ne vous diront pas : la plateforme que vous choisissez détermine 80 % de votre score de base. Le PHP personnalisé peut atteindre 100 avec un effort minimal. WordPress – même avec des plugins de cache – se situe généralement entre 40 et 60. J’ai construit et optimisé les deux. Laissez-moi vous montrer exactement pourquoi, avec des chiffres réels, du code et des résultats clients.

L’argument commercial pour réussir les Core Web Vitals

Avant de plonger dans le code, comprenez l’impact. Les données de Google montrent :

• Les sites qui réussissent les Core Web Vitals constatent 24 % d’abandon utilisateur en moins.
• Une amélioration de 0,5 s du LCP peut augmenter les conversions de 12 à 15 % (étude de cas Google).
• L’expérience de page est désormais un critère de départage lorsque deux pages ont une pertinence similaire.

Votre choix de plateforme ne concerne pas seulement la commodité du développeur – c’est un moteur direct de revenus et de classement.

Les chiffres bruts : PHP personnalisé vs WordPress (même serveur)

J’ai effectué un test contrôlé sur un hébergement identique (Hostinger VPS, 2 vCPU, 2 Go RAM, stockage NVMe). Deux sites Web :

• Site A : PHP/HTML personnalisé, sans framework, CSS/JS minimal, optimisé manuellement.
• Site B : WordPress 6.7 frais + thème Astra + 5 plugins essentiels (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

Les 847 Ko de JavaScript sont le problème. WordPress charge jQuery, l’éditeur de blocs, les scripts de plugins et les actifs du thème – même si vous ne les utilisez pas. Lighthouse de Google mesure tout cela, et chaque kilo-octet s’ajoute au LCP et à l’INP.

Core Web Vitals expliquées (seuils 2026)

Google a confirmé que l’expérience de page est un signal de classement sur mobile et sur ordinateur. En 2026, les seuils sont :

• LCP (Largest Contentful Paint) – mesure la vitesse de chargement. Bon : moins de 2,5 s.
• INP (Interaction to Next Paint) – mesure la réactivité. Bon : moins de 200 ms (a remplacé le FID en 2024).
• CLS (Cumulative Layout Shift) – mesure la stabilité visuelle. Bon : moins de 0,1.
• TTFB (Time To First Byte) – réponse du serveur. Bon : moins de 600 ms (non officiel, mais Google l’utilise).

Un site qui échoue à ces métriques est relégué en dessous des concurrents plus rapides – même s’il a plus de backlinks.

Comment le PHP personnalisé atteint un 100 parfait (code réel + techniques de pointe)

Voici exactement ce que je fais sur chaque construction personnalisée pour garantir un score Lighthouse de 100.

1. Précharger les actifs critiques

Dites au navigateur ce qui est le plus important avant même qu’il n’analyse le HTML.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Intégrer le CSS de la partie visible (réduire le FCP de moitié)

Extrayez uniquement les styles nécessaires pour la zone visible. Utilisez l’onglet Coverage de Chrome pour trouver le CSS inutilisé.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Servir des images responsives avec srcset et WebP

La plupart des sites servent des images de taille ordinateur aux mobiles – une énorme pénalité LCP. Utilisez `srcset` pour servir des images de taille appropriée.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Optimiser la réponse du serveur (TTFB)

J’utilise PHP‑FPM avec OPcache activé, la compression GZIP et l’indexation de base de données. L’absence de surcharge `wp_query` de WordPress signifie que les requêtes renvoient des résultats en 5–15 ms, pas 150 ms. Ajustements supplémentaires :

• Activer Keep‑Alive et HTTP/2.
• Utiliser un CDN (Cloudflare ou Bunny.net) pour mettre en cache les actifs statiques.
• Déplacer la base de données vers un serveur séparé ou utiliser Redis pour la mise en cache d’objets si nécessaire.

5. Éliminer les décalages de mise en page (CLS = 0,01)

Chaque image, vidéo et emplacement publicitaire reçoit des attributs explicites `width` et `height`. Réservez de l’espace pour les polices avec `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Différer le JavaScript non critique

Utilisez `defer` ou `async` sur tous les scripts externes et déplacez les analyses pour qu’elles se chargent après l’interaction de l’utilisateur.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. Utiliser `loading="lazy"` pour les images sous la ligne de flottaison

Les images non visibles initialement doivent être chargées en lazy. Cela économise la bande passante et accélère le LCP.

Pourquoi WordPress ne peut pas facilement égaler ces chiffres

• Chaque plugin ajoute son propre CSS/JS, souvent sans `async` ni `defer`. Même les plugins « optimisés » ajoutent de la surcharge.
• L’éditeur de blocs charge plus de 500 Ko de JavaScript même si vous n’utilisez qu’une page simple. C’est un demi-mégaoctet de code inutilisé.
• Les plugins de cache aident, mais ils ne peuvent pas supprimer le gonflement sous-jacent – ils ne font que mettre en cache la sortie déjà gonflée.
• Les thèmes tiers intègrent des frameworks entiers (Bootstrap, Tailwind) – 90 % de CSS inutilisé qui bloque toujours le rendu.

Même si vous obtenez temporairement 90 à Lighthouse, une mise à jour de plugin ou un nouveau thème peut le faire chuter à 45 du jour au lendemain. Avec le PHP personnalisé, vos performances sont déterministes – elles ne changent que si vous les changez.

Deux transformations réelles de clients

Étude de cas 1 : Boutique de bijoux WooCommerce → PHP personnalisé

Une bijouterie avait un site WooCommerce obtenant 43 à Lighthouse (mobile). Ils avaient 12 plugins actifs, un thème gonflé et des temps de chargement de 4,2 s. Après avoir migré vers une boutique PHP personnalisée avec Stripe Checkout :

• Score Lighthouse : 43 → 98.
• Temps de chargement mobile : 4,2 s → 0,9 s.
• Taux de conversion : 1,8 % → 3,4 % (+89 %).
• La valeur moyenne des commandes a augmenté de 22 % (un paiement plus rapide a encouragé les ventes incitatives).

Étude de cas 2 : Site immobilier avec plus de 500 pages

Une agence immobilière avait un site WordPress avec des temps de chargement de 3,5 secondes et un CLS de 0,28 (mauvais). Nous avons reconstruit le front‑end en un site PHP personnalisé utilisant un modèle léger, du CSS critique intégré et des images hero préchargées.

• LCP : 3,1 s → 0,9 s.
• CLS : 0,28 → 0,02.
• Le taux de rebond est passé de 58 % à 37 %.
• Les envois de formulaires de contact ont augmenté de 41 % en 60 jours.

Le coût caché des constructeurs de pages : Wix, Squarespace, Shopify

Ce n’est pas seulement WordPress. Toutes les plates-formes glisser-déposer souffrent de mauvais paramètres par défaut :

• Wix/Squarespace : Styles en ligne partout, taille DOM énorme et aucun contrôle sur le CSS critique. Score moyen Lighthouse mobile : 30–50.
• Shopify : Mieux que Wix, mais les thèmes chargent du JavaScript lourd et des polices externes. Score moyen : 60–75.
• Webflow : Peut être optimisé, mais nécessite des connaissances expertes et produit encore du code gonflé par rapport au PHP écrit à la main.

Seul le PHP personnalisé vous donne un contrôle total sur chaque octet qui atteint le navigateur.

Comment commencer (même si vous n’êtes pas développeur)

Vous n’avez pas besoin de tout écrire à partir de zéro. Je construis chaque site Web manuellement, vous obtenez donc une base de code 100 % adaptée. Le résultat : un score Lighthouse que vous pouvez capturer et utiliser comme signal de confiance. Vous pouvez également commencer par un générateur de site statique (Hugo, Eleventy) et ajouter plus tard du PHP pour des fonctionnalités dynamiques.

Plan d'action : obtenez un score de 100 dès aujourd'hui

1. Testez votre site actuel sur PageSpeed Insights (mobile). Notez votre LCP, INP, CLS.
2. Corrigez les problèmes évidents : compressez les images, activez la mise en cache, supprimez les plugins inutilisés.
3. Si vous êtes en dessous de 70, envisagez une migration de plateforme. Le retour sur investissement d’un site PHP personnalisé est souvent rentabilisé en 6 à 12 mois grâce à des conversions plus élevées et des coûts d’hébergement inférieurs.
4. Ou engagez-moi. Je vais vous construire un site PHP personnalisé qui obtient 100 – garanti.

Résumé final : le choix de la plateforme représente 80 % de la bataille

Vous pouvez optimiser n’importe quel site, mais commencer avec du PHP personnalisé vous donne une longueur d’avance considérable. WordPress nécessite une lutte constante contre sa propre architecture. Wix et Squarespace vous enferment dans des modèles lents. Le PHP personnalisé vous donne un contrôle total. Les chiffres parlent d’eux-mêmes.

Si vous voulez un site Web qui obtient naturellement 96–100 à Lighthouse et surclasse les constructeurs de pages, parlons-en.

Toutes les données de test ont été collectées sur Hostinger VPS (2 vCPU, 2 Go RAM) à l’aide de Lighthouse 12.0 (simulation mobile). Vos résultats peuvent varier en fonction du contenu et de l’hébergement.