Optimiser les Core Web Vitals pour les appareils d'entrée de gamme

Optimiser les Core Web Vitals pour les appareils d'entrée de gamme

Les Core Web Vitals devraient faire partie d'un référentiel objectif pour la qualité d'un site. En pratique, ce n'est pas le cas ! Les métriques sont étroitement liées aux appareils que les utilisateurs utilisent. Si une entreprise vend des produits ou des services haut de gamme, ses clients ont tendance à posséder des téléphones rapides, des ordinateurs de bureau et des connexions fiables.
Contrastez cela avec les entreprises ciblant les acheteurs soucieux des coûts ou les marchés émergents. Leur public s'appuie sur des téléphones vieillissants, des processeurs faibles ou de mauvaises conditions réseau.
Le même site web qui passe sans problème un test sur un iPhone phare peine à se charger de manière acceptable sur un Android milieu de gamme ou dans les pays à faible bande passante.

Dernière révision par Arjen Karel en mars 2026

Les chiffres parlent d'eux-mêmes

Selon le Web Almanac 2025, seuls 48 % des origines mobiles réussissent les Core Web Vitals contre 56 % sur ordinateur. L'écart le plus important concerne l'INP : 97 % des origines sur ordinateur réussissent, mais seulement 77 % sur mobile. Cet écart de 20 points de pourcentage est presque entièrement causé par des CPU plus lents sur les appareils Android.

Le Total Blocking Time médian sur mobile est de 1 916 millisecondes. Sur ordinateur ? 92 millisecondes. C'est un ratio de 20:1. Si vos scripts s'exécutent parfaitement sur votre MacBook, ils ne s'exécutent absolument pas bien sur un téléphone économique.

Selon les recherches d'Alex Russell, environ 30 % des appareils dans la nature sont d'entrée de gamme (4 cœurs ou moins, 4 Go de RAM ou moins). Ces appareils ont des performances monocœur jusqu'à 9 fois plus lentes qu'un iPhone actuel. Dans les données RUM de CoreDash, nous voyons que les sites optimisés pour les appareils d'entrée de gamme réussissent les Core Web Vitals sur 62 % des chargements de pages mobiles, contre seulement 41 % pour les sites qui ne testent que sur du matériel haut de gamme.

Étape 1 : Générer un Client Capability Score

Pour évaluer si un visiteur utilise un appareil haut de gamme ou d'entrée de gamme, un Client Capability Score peut être calculé directement dans le navigateur. Ce score varie de 0 (extrêmement contraint) à 100 (matériel de premier plan). En pratique, tout appareil obtenant un score inférieur à 40 doit être classé comme médiocre.

La fonction ci-dessous calcule le Client Capability Score à l'aide d'indicateurs matériels et réseau qui sont fortement corrélés au RUM dans le monde réel et aux données Core Web Vitals de Google. Un score plus élevé indique que l'appareil est plus capable d'offrir des performances de page rapides avec moins de contraintes de ressources.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Conseil Core Web Vitals : Ces optimisations aident tout le monde. Mais si quelqu'un est sur une connexion lente ou utilise un appareil avec une mémoire limitée, elles importent beaucoup plus. Les inconvénients de les ignorer apparaissent plus rapidement.
Prenez les téléchargements d'images. Sur une connexion normale, ils représentent généralement environ 10 % du temps du Largest Contentful Paint. Sur une connexion lente, cela peut doubler sans trop d'efforts. C'est pourquoi nous ne plaçons pas l'optimisation des images en haut de la liste pour la plupart des utilisateurs, mais face à des visiteurs avec une faible bande passante ou des contraintes de mémoire, cela devient rapidement une priorité.

Activer HTTP/3 avec QUIC et 0-RTT

Les visiteurs éloignés de vos serveurs ou bloqués sur des réseaux lents sont confrontés à des temps d'aller-retour (RTT) élevés. HTTP/3, avec QUIC et 0-RTT, améliore directement votre vitesse de connexion initiale. C'est une optimisation importante pour tous les visiteurs, mais particulièrement critique pour les visiteurs à faible bande passante. Selon Cloudflare Radar, HTTP/3 gère désormais 21 % du trafic web mondial. Si vous utilisez Cloudflare, vous pouvez activer HTTP/3 dans le tableau de bord Cloudflare.

• Configuration de connexion plus rapide : QUIC fusionne les handshakes de transport et de chiffrement en un seul. 0-RTT va plus loin : les visiteurs récurrents envoient des données immédiatement, contournant complètement les handshakes.
• Latence plus faible pour les utilisateurs récurrents : 0-RTT permet aux clients de reprendre les sessions et d'envoyer des requêtes sans pause. Des centaines de millisecondes économisées, particulièrement précieuses pour les utilisateurs éloignés ou mobiles.
• Résilient sur de longues distances : HTTP/3 (sur UDP) évite le blocage en tête de file de TCP. QUIC gère la perte de paquets et les réseaux instables avec plus de grâce. Cela fait une réelle différence pour les connexions intercontinentales ou mobiles instables.

Compresser les images de manière plus agressive que ne le souhaite votre designer

Les images haute résolution bloquent le LCP, particulièrement sur les appareils avec une puissance de décompression GPU limitée. Le Web Almanac 2025 montre que la page d'accueil mobile médiane charge 911 Ko d'images. Cela représente 42 % du poids total de la page. Sur un appareil d'entrée de gamme avec un débit descendant P75 de 9 Mbps, ces images sont directement en concurrence avec vos ressources critiques.

Au lieu de céder à l'esthétique, visez des images plus petites et perceptuellement acceptables. WebP et AVIF aident, mais le chargement différé et le service de tailles réactives importent davantage.

Une règle claire : pour les images hero sur les appareils d'entrée de gamme, restez en dessous de 100 Ko. Si le designer s'y oppose, il devrait tester le même site sur un téléphone Android à 100 € avant de poursuivre le débat.

Réduire le CSS au strict nécessaire

En ce qui concerne les styles, il n'y a qu'une seule règle : faire le grand ménage. Supprimez les sélecteurs inutilisés, réduisez la spécificité et fusionnez les règles redondantes.

Concentrez-vous sur des mises en page prévisibles et cohérentes avec un minimum d'exceptions. Utilisez un petit ensemble de classes utilitaires plutôt que des styles complexes spécifiques aux composants. Cela aide à la fois la construction du CSSOM par le navigateur et la maintenabilité pour les développeurs.

Pour le contenu au-dessus de la ligne de flottaison, intégrez (inline) uniquement ce qui est absolument nécessaire. Chargez le reste en différé, mais gardez la séparation minimale et claire. Vous pouvez utiliser le Critical CSS Generator comme point de départ, mais définissez votre CSS critique manuellement et chirurgicalement pour le meilleur résultat.

Être direct avec les scripts

Avec un TBT mobile médian de 1 916 ms (en hausse de 58 % sur un an selon le Web Almanac 2025), le JavaScript est le problème le plus important sur les appareils d'entrée de gamme. La vitesse réseau P75 pour les appareils économiques est d'environ 9 Mbps en téléchargement avec 100 ms de RTT. Chaque kilooctet de JavaScript que vous envoyez est analysé et exécuté sur un CPU 9 fois plus lent que le téléphone sur lequel vous testez.

• Aucun script ne doit bloquer le rendu : Assurez-vous que tous les scripts non essentiels sont non bloquants. Utilisez les attributs async ou defer sur vos balises <script>. Si un script n'est pas essentiel pour le chargement initial de la page ou l'interaction de l'utilisateur, il ne doit pas être synchrone. Pour un aperçu complet des techniques de report, voir 16 méthodes pour différer JavaScript.
• Planifier les scripts non critiques : Les scripts qui ne sont pas requis d'emblée doivent être planifiés. Utilisez requestIdleCallback pour déclencher les scripts lorsque le navigateur est inactif. Cela vous permet de décharger les tâches lourdes sans perturber les chemins de rendu critiques.
• Utiliser le Client Capability Score pour charger sélectivement les scripts : Utilisez le score pour décider quoi charger. Sur les appareils d'entrée de gamme, réduisez le nombre de scripts et choisissez des alternatives plus légères. Si l'utilisateur a une mémoire limitée ou un CPU plus ancien, ne gaspillez pas les ressources à charger des scripts lourds. Priorisez les performances sur les fonctionnalités de vanité qui pourraient impressionner sur des appareils haut de gamme mais frustrer sur des appareils bas de gamme.

Utiliser des polices système ou au moins éviter les polices personnalisées lourdes

Le chargement de polices personnalisées ajoute de la latence et provoque des saccades dans la mise en page. Sur les appareils avec une mémoire limitée, elles peuvent également augmenter inutilement la pression sur la RAM. Selon le Web Almanac 2025, 88 % des sites chargent au least une police web, mais seuls 12 % les préchargent. La meilleure option pour les performances, font-display: optional, n'est utilisée que par 0,4 % des sites.

Les polices système s'affichent plus rapidement, respectent les paramètres de l'utilisateur et réduisent le Cumulative Layout Shift. Si l'image de marque exige une typographie personnalisée, limitez agressivement les sous-ensembles et chargez les polices tardivement. Envisagez d'héberger vous-même vos polices afin de contrôler leur distribution.

Surveiller avec du matériel réel, pas seulement avec des tests synthétiques

Les outils de tests synthétiques (comme Lighthouse, WebPageTest, etc.) simulent une limitation mais ne reproduisent pas toutes les bizarreries du matériel d'entrée de gamme : la température, la limitation sous charge réelle, les pauses de nettoyage de la mémoire (garbage collection) et les goulots d'étranglement de stockage. Notez que PageSpeed Insights a modifié sa limitation CPU de 4x à 1,2x en décembre 2024, rendant les scores de laboratoire encore moins représentatifs des performances réelles des appareils économiques.

Achetez un téléphone Android bon marché et naviguez sur votre site. Si vous ne pouvez pas vous résoudre à le faire régulièrement, utilisez un outil RUM comme CoreDash et segmentez les données par classe d'appareils. Si votre LCP P75 est correct sur iPhone 15 mais terrible sur Xiaomi Redmi 9, il est temps d'être honnête sur les personnes pour lesquelles vous optimisez.