Les visiteurs mobiles et de bureau bénéficient rarement de la même expérience. Une page qui se charge rapidement sur un ordinateur portable rapide peut sembler lente sur un téléphone avec un processeur plus lent et une connexion cellulaire. L'onglet Performance (Speed Insights) de Zenovay vous permet de diviser vos Core Web Vitals par appareil afin que vous puissiez voir — et corriger — ces écarts.
Où le trouver
Ouvrez le tableau de bord de votre site web à partir de Domains, puis sélectionnez l'onglet Performance. La performance est regroupée sous Behavior dans la barre latérale du tableau de bord.
L'onglet Performance mesure les cinq Core Web Vitals à partir de vrais visiteurs :
- LCP — Largest Contentful Paint
- CLS — Cumulative Layout Shift
- INP — Interaction to Next Paint
- FCP — First Contentful Paint
- TTFB — Time to First Byte
Info
Les données de performance sont disponibles sur tous les plans. La quantité d'historique que vous pouvez consulter dépend de votre plan : Free voit les 24 dernières heures, Pro jusqu'à 30 jours et Scale jusqu'à 90 jours. Les plages plus longues et les ventilations plus approfondies ci-dessous sont plus utiles pour Pro et au-dessus.
Diviser la performance par appareil
La barre d'outils Performance dispose d'un filtre d'appareil avec trois options :
- All — tous les visiteurs
- Desktop
- Mobile
Changez le filtre pour comparer la même métrique entre les classes d'appareils. Mobile affiche généralement des Core Web Vitals plus lents que desktop en raison de :
- Processeurs plus lents et moins de mémoire
- Réseaux cellulaires avec une latence plus élevée
- Fenêtres d'affichage plus petites, qui peuvent modifier la façon dont le contenu se charge et se déplace
Associez le filtre d'appareil au sélecteur percentile (p75, p90, p95, p99) pour voir si un problème affecte la plupart des visiteurs mobiles ou seulement les plus lents.
Astuce
p75 est le percentile que Google utilise pour noter les Core Web Vitals, c'est donc le meilleur point de départ. Augmentez à p95 ou p99 lorsque vous chassez les pires expériences sur les appareils mobiles bas de gamme.
Approfondir la cause
Une fois qu'une classe d'appareil semble lente, utilisez les ventilations de l'onglet Performance pour déterminer où se trouve le problème :
- Par page — quelles routes ont les pires valeurs pour la métrique sélectionnée. Un seul modèle lourd entraîne souvent un segment d'appareil entier.
- Par pays — une choroplèthe mondiale plus une liste classée, afin que vous puissiez distinguer un problème d'appareil d'un problème réseau/géographique.
- Phases TTFB — un graphique en cascade divisant Time to First Byte en DNS, connexion, serveur et temps de transfert, ce qui aide à séparer la lenteur du backend de la distance réseau.
- Éléments les plus responsables — les sélecteurs spécifiques les plus responsables de la métrique sélectionnée sur chaque route.
La combinaison du filtre d'appareil avec ces ventilations est généralement suffisante pour localiser un problème, par exemple « INP est faible sur mobile, spécifiquement sur la route de paiement ».
Recevoir des notifications
Les alertes automatisées de Zenovay couvrent la détection d'anomalies et les notifications de pic de trafic plutôt que les seuils par métrique, par appareil. Pour être averti lorsque la performance globale change et pour planifier des résumés récurrents, consultez le guide Performance Alerts.
Stratégies d'optimisation
Mobile-first
Comme mobile est généralement le plus grand segment et le plus lent, priorisez-le :
- Réduire JavaScript — généralement le plus grand avantage pour INP et le temps de charge
- Optimiser et dimensionner correctement les images pour les fenêtres d'affichage mobiles
- Minimiser les décalages de mise en page (CLS)
- Améliorer les tailles des cibles de robinet
- Tester sur de véritables appareils bas de gamme, pas seulement un émulateur
Servir les bonnes ressources par appareil
Utilisez des images réactives afin que les téléphones ne téléchargent pas des fichiers de la taille du bureau :
<!-- Responsive images -->
<picture>
<source
srcset="image-mobile.webp"
media="(max-width: 768px)"
>
<source
srcset="image-desktop.webp"
media="(min-width: 769px)"
>
<img src="image-fallback.jpg" alt="Description">
</picture>
Amélioration progressive
Détection de fonctionnalité plutôt que d'assumer que chaque appareil prend en charge chaque API :
// Feature detection
if ('IntersectionObserver' in window) {
// Use modern lazy loading
} else {
// Fall back to a simpler approach
}
Budgets de performance par appareil
Un moyen simple de éviter les régressions est de définir un budget par classe d'appareil et de traiter tout ce qui dépasse comme un bogue :
Performance Budgets
Metric Desktop Mobile
LCP < 2.0s < 2.5s
INP < 150ms < 200ms
CLS < 0.05 < 0.1
Dépannage
Aucune donnée d'appareil
Vérifiez :
- Le script de suivi est installé sur les pages que vous attendez (voir Install the tracking script)
- Les visiteurs ne sont pas tous bloqués par les outils de confidentialité ou les bloqueurs de publicités
- Il y a suffisamment de trafic récent pour remplir la plage de temps sélectionnée
Une classe d'appareil n'affiche aucune métrique
Les Core Web Vitals sont collectés à partir de vraies visites. Un tout nouveau site, une page avec peu de trafic ou une plage de temps très courte peuvent ne pas avoir encore assez d'échantillons pour une division d'appareil — élargissez la plage ou attendez plus de trafic.