Optimiser les Core Web Vitals pour les appareils bas de gamme

Optimiser les Core Web Vitals pour les appareils bas de gamme

Les Core Web Vitals devraient faire partie d'un benchmark objectif pour la qualité du site. En pratique, ils ne le sont pas ! Les métriques sont étroitement liées aux appareils que les utilisateurs apportent à la table. Si une entreprise vend des produits ou 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 des entreprises ciblant des acheteurs soucieux des coûts ou des marchés émergents. Leurs publics s'appuient sur des téléphones vieillissants, des processeurs faibles ou de mauvaises conditions réseau. 
Le même site web qui traverse facilement un test sur un iPhone phare a du mal à se charger de manière acceptable sur un Android de milieu de gamme ou dans des pays avec une connectivité à faible bande passante. Cet article examine comment optimiser les Core Web Vitals pour les appareils bas de gamme.

Étape 1 : Générer un Score de Capacité Client

Pour évaluer si un visiteur utilise un appareil haut de gamme ou bas de gamme, un Score de Capacité Client peut être calculé directement dans le navigateur. Ce score va de 0 (extrêmement contraint) à 100 (matériel de premier niveau). En pratique, tout appareil obtenant un score inférieur à 40 devrait être classé comme pauvre.

La fonction ci-dessous calcule le Score de Capacité Client en utilisant des indicateurs matériels et réseau qui sont fortement corrélés avec les données RUM du monde réel et les Core Web Vitals de Google. Un score plus élevé indique que l'appareil est plus capable de fournir des performances de page rapides avec moins de contraintes de ressources et peut gérer une interaction plus fluide.

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 comptent 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'effort. C'est pourquoi nous ne poussons pas l'optimisation des images en haut de la liste pour la plupart des utilisateurs, mais lorsqu'il s'agit de visiteurs à faible bande passante ou à mémoire contrainte, cela devient rapidement une priorité.

Activer http/3 avec QUIC et 0-RTT

• Configuration de connexion plus rapide : QUIC regroupe les handshakes de transport et de chiffrement en un seul. 0-RTT va plus loin : les visiteurs réguliers envoient des données immédiatement, contournant complètement les handshakes.
• Latence plus faible pour les utilisateurs réguliers : 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écieux pour les utilisateurs distants ou mobiles.
• Résilient sur de longues distances : HTTP/3 (sur UDP) contourne le blocage de tête de ligne (head-of-line blocking) de TCP. QUIC gère la perte de paquets et les réseaux instables plus gracieusement — idéal pour les connexions intercontinentales ou mobiles instables.

Compressez les images plus agressivement que votre designer ne l'aime

Les images haute résolution bloquent le LCP (Largest Contentful Paint), en particulier sur les appareils avec une puissance de décompression GPU limitée. Au lieu de céder à l'esthétique, visez des images plus petites et perceptivement acceptables. WebP et AVIF aident, mais le chargement différé (lazy-loading) et la fourniture de tailles réactives comptent plus.

Une règle claire : pour les images de héros sur les appareils bas 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 d'argumenter davantage.

Réduisez le CSS au strict nécessaire

En ce qui concerne les styles, il n'y a qu'une seule règle : faites le 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 de surcharges. 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 du navigateur et la maintenabilité pour les développeurs.

Pour le contenu au-dessus de la ligne de flottaison, n'intégrez (inline) que ce qui est absolument nécessaire. Chargez le reste en différé, mais gardez la séparation minimale et claire. Évitez les outils qui devinent ce qu'est le "CSS critique", définissez-le manuellement et chirurgicalement.

Soyez direct avec les Scripts

• 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 utilisateur, il ne doit pas être synchrone. Sinon, vous gaspillez de précieuses millisecondes.
•  Planifiez les scripts non critiques Les scripts qui ne sont pas requis dès le départ doivent être planifiés. Mais ne les chargez pas au petit bonheur la chance. Utilisez les fonctions requestIdleCallback pour déclencher des scripts lorsque le navigateur est inactif. Cela vous permet de décharger les tâches lourdes sans perturber les chemins de rendu critiques.
• Utilisez le Score de Capacité Client pour charger sélectivement les scripts "sympas à avoir":  Le Score de Capacité Client n'est pas seulement une métrique mais un outil pour optimiser l'expérience utilisateur.  Sur les appareils bas de gamme, réduisez le nombre de scripts chargés et choisissez des alternatives plus légères. Si l'utilisateur a une mémoire limitée ou un vieux processeur, ne gaspillez pas de ressources à charger des scripts lourds en ressources. Priorisez la performance sur les fonctionnalités vaniteuses qui pourraient impressionner sur des appareils haut de gamme mais frustrer sur des appareils bas de gamme.

Utilisez les polices système ou au moins évitez les polices personnalisées lourdes

Le chargement de polices personnalisées ajoute de la latence et saccade la mise en page. Sur les appareils à mémoire limitée, elles peuvent également augmenter inutilement la pression sur la RAM.

Les polices système s'affichent plus rapidement, respectent les paramètres utilisateur et réduisent le décalage de mise en page (layout shift). Si l'image de marque impose une typographie personnalisée, faites des sous-ensembles (subset) agressifs et chargez les polices tardivement.

Surveillez avec du vrai matériel, pas seulement des tests synthétiques

Enfin, les outils de test synthétiques (comme Lighthouse, WebPageTest, etc.) simulent le throttling mais n'imitent pas toutes les bizarreries du matériel bas de gamme : thermiques, throttling sous charge réelle, pauses de ramasse-miettes (garbage collection) et goulots d'étranglement de stockage.

Achetez un téléphone Android bon marché et naviguez sur votre site. Si vous ne supportez pas de faire cela régulièrement, utilisez un outil RUM comme Coredash et segmentez les données par classe d'appareil. Si votre LCP P75 est bon sur iPhone 15 mais terrible sur Xiaomi Redmi 9, il est temps d'être honnête sur pour qui vous optimisez.