Aller au contenu principal
8 min de lecture

Core Web Vitals

Zenovay collecte les Core Web Vitals de Google (LCP, CLS, INP) ainsi que deux métriques complémentaires (FCP, TTFB) à partir de chaque session visiteur réelle. Les données apparaissent dans l'onglet Performance du tableau de bord de chaque domaine.

Rien à installer. La collecte des Web Vitals fait partie du tracker Zenovay standard. Si votre script de suivi est déjà en place, les vitals commencent à remonter dès que les visiteurs chargent vos pages.


Ce que mesurent les Web Vitals

Les Core Web Vitals sont les signaux stables de Google pour l'expérience réelle de la page. Ils apparaissent dans Google Search Console, influencent le classement et corrèlent fortement avec le taux de rebond et la conversion.

MétriqueCe qu'elle mesureBonÀ améliorerMauvais
LCP — Largest Contentful PaintQuand le contenu principal devient visible≤ 2,5 s≤ 4,0 s> 4,0 s
CLS — Cumulative Layout ShiftAmpleur des déplacements inattendus du contenu visible≤ 0,1≤ 0,25> 0,25
INP — Interaction to Next PaintPire délai entre un clic/tap et le prochain rendu≤ 200 ms≤ 500 ms> 500 ms
FCP — First Contentful PaintQuand le premier texte/image est rendu≤ 1,8 s≤ 3,0 s> 3,0 s
TTFB — Time to First ByteQuand le premier octet arrive depuis le serveur≤ 800 ms≤ 1,8 s> 1,8 s

Les seuils suivent les recommandations publiées par Google et se reflètent directement dans le code couleur du tableau de bord Zenovay (vert / orange / rouge).


Comment Zenovay collecte les données

La collecte se fait entièrement dans le navigateur via l'API standard PerformanceObserver et l'entrée Navigation Timing — sans bibliothèque tierce, sans script additionnel.

Déroulement court :

  1. Dès l'initialisation du tracker, des observers sont enregistrés pour largest-contentful-paint, layout-shift, event (pour INP) et paint (pour FCP).
  2. TTFB est lu une fois depuis performance.getEntriesByType('navigation')[0].responseStart.
  3. Les valeurs finales sont regroupées dans une seule charge utile et envoyées à POST /api/track/<votre-code-de-suivi>/performance lorsque le visiteur quitte la page (visibilitychange → hidden, plus pagehide pour le bfcache mobile).
  4. L'API enrichit chaque ligne avec country_code, device_type, browser et — si disponible — connection_type.

La charge utile ne contient aucune valeur de formulaire, aucun contenu DOM, et aucune PII au-delà de ce qu'un pageview analytique contient déjà (l'URL).

Un beacon par cycle de page. Les vitals sont envoyés exactement une fois lorsque le visiteur quitte une page. Les SPA qui routent côté client envoient un nouveau beacon à chaque transition de page — comme pour les événements pageview.


Où voir vos données

Ouvrez un domaine dans app.zenovay.com et cliquez sur l'onglet Performance.

Vous verrez :

  • Une barre latérale de métriques avec la valeur actuelle, l'évaluation par seuil et la distribution par percentile pour LCP / CLS / INP / FCP / TTFB.
  • Un panneau de détail avec l'évolution de la métrique sélectionnée sur la plage horaire choisie, plus une explication contextuelle de ce qui l'influence.
  • Des répartitions par Routes et Pays indiquant les pages et régions les moins performantes.
  • Des contrôles pour :
    • Appareil — Tous / Desktop / Mobile
    • Percentile — P75 / P90 / P95 / P99 (Google utilise P75 par défaut)
    • Plage horaire — limitée par formule (voir ci-dessous)

Conseils sur les percentiles

Google utilise le 75ᵉ percentile des utilisateurs réels pour les signaux de classement de Search Console. Les percentiles supérieurs (P90, P95, P99) font ressortir vos visiteurs les plus lents — utiles lors de l'investigation d'une régression spécifique ou d'une longue traîne d'appareils lents.


Disponibilité par formule et conservation

La collecte des Web Vitals est incluse dans chaque formule, y compris Free. L'accès à la plage horaire est échelonné par formule :

FormulePlage horaire Performance
Free7 derniers jours
Pro30 derniers jours
Scale90 derniers jours
EnterpriseJusqu'à 1 an

Ces plafonds correspondent aux paliers de conservation analytique plus larges — voir Tarifs et limites de formule pour les règles sous-jacentes.


Désactiver les Web Vitals pour un site spécifique

Les vitals sont actifs par défaut. Pour les désactiver pour un site suivi spécifique, définissez le feature flag dans les paramètres de ce site :

{
  "feature_flags": {
    "enable_core_web_vitals": false
  }
}

Quand le flag est false :

  • Le tracker n'enregistre pas du tout les observers (coût nul côté navigateur).
  • L'endpoint API accepte le beacon mais ne stocke rien (no-op silencieux pour les requêtes en cours).

Pour réactiver, remettez le flag à true ou supprimez-le entièrement (activé par défaut).


Questions fréquentes

Pourquoi INP est-il absent sur Safari ?

Safari n'a implémenté le type d'entrée event de PerformanceObserver avec interactionId que très récemment. Sur les anciennes versions de Safari, Zenovay rapporte LCP, CLS, FCP et TTFB et laisse INP à null pour cette session. Le tableau de bord affiche simplement moins d'échantillons INP en attendant — aucune action requise de votre part.

Les SPA reçoivent-elles un beacon par changement de route ?

Oui. Le tracker réinitialise les observers à chaque transition de page suivie (y compris les routes SPA qui déclenchent pushState ou replaceState). Vous verrez une ligne de performance par pageview, et non une par session navigateur.

La collecte des vitals affecte-t-elle la performance de mon site ?

PerformanceObserver est une API navigateur passive conçue exactement pour ce cas d'usage. Les observers se déclenchent sur des événements navigateur existants ; il n'y a aucun polling ni travail supplémentaire sur le thread principal. Le beacon unique au déchargement de page est envoyé via fetch avec keepalive: true et ne bloque donc pas la navigation.

Pourquoi mes chiffres ne correspondent-ils pas aux données CrUX de Google ?

Deux raisons normales :

  1. Population échantillonnée. Zenovay mesure chaque visiteur réel qui charge votre site. CrUX ne mesure que les utilisateurs Chrome ayant opté pour l'anonymisation d'URL — un sous-ensemble strict.
  2. Fenêtre temporelle. CrUX est une fenêtre glissante de 28 jours, données Chrome uniquement. Zenovay vous laisse choisir votre fenêtre et filtrer par appareil, percentile, route et pays.

Les deux signaux sont valides ; ils répondent à des questions légèrement différentes. CrUX est ce que Google utilise pour le classement ; Zenovay est ce que vous utilisez pour déboguer.

Où trouver les valeurs de seuil dans le code ?

Elles se trouvent dans app-zenovay/lib/api/performance.ts (constantes frontend) et reflètent les seuils publiés par Google. Les modifier nécessite une mise à jour du code — elles ne sont délibérément pas configurables côté client afin que les libellés « Bon » / « À améliorer » / « Mauvais » restent comparables dans tout le produit.


Dépannage d'un tableau de bord vide

Si l'onglet Performance affiche l'état vide (« No performance data yet ») :

  1. Vérifiez que le tracker se déclenche. Ouvrez le diagnostic Install Health. Si les pageviews ne remontent pas, les vitals non plus.
  2. Vérifiez le feature flag. Assurez-vous que feature_flags.enable_core_web_vitals n'est pas explicitement à false dans les paramètres du site.
  3. Laissez du trafic arriver. Les beacons vitals se déclenchent au déchargement de page. Un site avec très peu de trafic — ou testé uniquement par vous avec un cache vidé — peut avoir besoin de plusieurs sessions avant que des chiffres apparaissent.
  4. Élargissez la plage horaire. Un nouveau site sur Free affiche par défaut les 7 derniers jours — fraîchement installé, élargissez au maximum autorisé par votre formule.
  5. Ouvrez les DevTools → Réseau. Filtrez sur Performance et cherchez un POST vers /api/track/<code>/performance. La réponse est un petit JSON avec success: true.

Si la requête se déclenche mais qu'aucune donnée n'apparaît, contactez [email protected] avec votre code de suivi — il existe un flag de désactivation par site et nous pouvons confirmer qu'il n'est pas défini.


Liens connexes

Cette page vous a-t-elle été utile ?