Mesurer les performances avec web-vitals.js, Google Analytics et BigQuery

1. Avant de commencer

Objectifs de l'atelier

Au cours de cet atelier de programmation, vous allez :

associer votre propriété Google Analytics 4 à BigQuery ;
ajouter la bibliothèque web-vitals à une page Web ;
préparer les données web-vitals et les envoyer à Google Analytics ;
interroger vos données de signaux Web essentiels dans BigQuery ;
créer un tableau de bord dans Google Data Studio pour visualiser vos données de signaux Web essentiels.

Ce dont vous avez besoin

Un compte Google Analytics avec une propriété GA4
Un compte Google Cloud
Un navigateur Web Chromium, tel que Google Chrome ou Microsoft Edge (pour savoir pourquoi un navigateur Web Chromium est nécessaire, consultez Browser Support (Compatibilité des navigateurs))
L'éditeur de texte de votre choix, tel que Sublime Text ou Visual Studio Code
Un emplacement pour héberger vos pages de test afin de découvrir le fonctionnement de la bibliothèque web-vitals (vous pouvez utiliser un serveur local pour afficher les pages Web statiques ou héberger vos pages de test sur GitHub)
Un site public où vous pouvez déployer le code de vos données analytiques (le fait de mettre en production votre code vous permettra de mieux comprendre les exemples BigQuery et Data Studio à la fin de cet atelier de programmation)
Des connaissances sur les langages HTML, CSS, JavaScript et des Outils pour les développeurs Chrome

Avant de commencer

Tout d'abord, associez Google Analytics 4 à BigQuery pour pouvoir lancer l'analyse de vos performances dès la mise en ligne de votre code.

Suivez la procédure indiquée dans le Centre d'aide Google Analytics pour associer votre propriété GA4 à BigQuery.

Maintenant que votre propriété Google Analytics est prête à exporter les données d'événement vers BigQuery, intégrez la bibliothèque web-vitals à votre site.

2. Ajouter la bibliothèque web-vitals et l'outil gtag à une page Web

Tout d'abord, ajoutez la bibliothèque web-vitals à une page Web.

Ouvrez un modèle de page sur lequel vous voulez ajouter la bibliothèque web-vitals. Dans cet exemple, nous allons utiliser une page simple :

basic.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Web Vitals Test</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
  <p><img style="max-width: 360px" src="https://placekitten.com/g/3840/2160" alt="Kitten" /></p>
  <p>Text below image</p>
</body>
</html>

Collez le code source dans un fichier vierge de votre éditeur de texte.
Enregistrez le fichier en local sous le nom basic.html.
Copiez ce script de module et collez-le juste avant la balise de fermeture </body>. Ce script charge la bibliothèque web-vitals à partir d'un réseau de diffusion de contenu (CDN).

basic.html

<script type="module">
  import {getCLS, getFID, getLCP} from 'https://unpkg.com/web-vitals?module';

  getCLS(console.log);
  getFID(console.log);
  getLCP(console.log);
</script>

Le code obtenu doit se présenter comme suit.

basic.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Web Vitals Test</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
  <p><img style="max-width: 360px" src="https://placekitten.com/g/3840/2160" alt="Kitten" /></p>
  <p>Text below image</p>

<script type="module">
  import {getCLS, getFID, getLCP} from 'https://unpkg.com/web-vitals?module';

  getCLS(console.log);
  getFID(console.log);
  getLCP(console.log);
</script>
</body>
</html>

Enregistrez le fichier.

Vous avez ajouté la bibliothèque web-vitals à la page Web.

3. Mesurer les signaux Web essentiels de la page Web

Les signaux Web essentiels mesurent l'expérience utilisateur réelle, telle qu'elle est enregistrée dans Chrome ou dans la bibliothèque web-vitals des navigateurs Chromium. Lorsque vous mettez web-vitals en production, vous obtenez un large éventail de résultats basés sur les vitesses de connexion des utilisateurs, la puissance de l'appareil et la façon dont ils interagissent avec votre site. Pour présenter les fonctionnalités de la bibliothèque web-vitals, nous allons simuler une expérience utilisateur avec une connexion lente.

Ouvrez le fichier enregistré dans votre navigateur Web.
Effectuez un clic droit sur la page Web.
Cliquez sur Inspecter pour ouvrir les outils pour les développeurs Google Chrome.

Cliquez sur l'onglet Console > Paramètres de la console .

Cochez la case Conserver le journal pour conserver les journaux lorsque vous actualisez la page Web.

Cliquez sur l'onglet Réseau > En ligne > 3G lente pour simuler une connexion réseau lente.

Cliquez sur l'onglet Console.
Cliquez n'importe où sur la page Web pour forcer l'impression des métriques associées au LCP (Largest Contentful Paint) et au First Input Delay (FID).
Cliquez sur Actualiser cette page pour forcer l'impression de la métrique associée au CLS (Cumulative Layout Shift).

Cliquez sur l'onglet Réseau > En ligne > 3G rapide pour simuler une connexion réseau rapide.
Cliquez sur l'onglet Console.
Cliquez n'importe où sur la page Web pour forcer à nouveau l'impression des métriques associées au LCP et au FID.

Cliquez sur le bouton Actualiser cette page pour forcer l'impression de la métrique associée au CLS.

Et voilà ! Vous avez mesuré les signaux Web essentiels de la page Web.

4. Explorer les données sur les tests web-vitals plus en détail

Pour chacun des événements "Signaux Web essentiels" que vous mesurez, un certain nombre d'informations sont disponibles dans les données renvoyées. Elles vous permettent de déboguer les goulots d'étranglement qui affectent les performances. Chaque événement web-vitals contient un tableau entries avec des informations sur les événements qui contribuent à la valeur actuelle de la métrique.

CLS `entries`

Lorsque vous développez la propriété entries de l'objet enregistré par getCLS(), une liste d'entrées LayoutShift s'affiche. Chaque LayoutShift contient une propriété value reflétant le score de décalage de la mise en page et un tableau sources qui nous permet de voir quels éléments ont été décalés.

Dans cet exemple, il y a eu deux décalages de mise en page. Chacun a déplacé un élément h1 sur la page. La propriété currentRect nous précise où se trouve désormais l'élément, et l'élément previousRect nous indique son emplacement précédent.

LCP `entries`

Le fait que la propriété des entrées de l'objet enregistré par getLCP() soit développée indique quels éléments pouvaient faire partie du Largest Contentful Paint avant le signalement de la valeur finale.

Dans cet exemple, le tableau entries contient la liste de tous les candidats au LCP, dans l'ordre chronologique. Dans ce cas, un élément h1 a été affiché en premier, suivi d'un élément img. L'élément img était identifié comme "Largest Contentful Paint". L'élément LCP indiqué est toujours le dernier élément du tableau.

`entries` du FID

Lorsque vous développez la propriété entries de l'objet enregistré par getFID(),, un tableau contenant l'entrée PerformanceEventTiming s'affiche pour la première entrée utilisateur (First User Input) sur la page.

La propriété name vous indique le type d'entrée utilisateur qui a déclenché le minuteur de disponibilité du thread principal. Le value indiqué par web-vitals correspond au délai entre les propriétés startTime et processingStart de l'entrée PerformanceEventTiming, converti de microsecondes en millisecondes. Dans ce cas, le FID mesuré est de 2 millisecondes.

5. Préparer les données web-vitals et les envoyer à Google Analytics 4

Pour pouvoir envoyer des données web-vitals à Google Analytics 4, vous devez les convertir dans un format que GA4 peut recevoir. Vous allez également ajouter des fonctions utiles qui permettent d'obtenir de précieuses informations de diagnostic.

Générer un sélecteur pour identifier le nœud cible de l'entrée

Ajoutez d'abord une fonction au bloc de script qui génère une représentation de chaîne du nœud et de son emplacement dans le DOM. Utilisez un format semblable à un sélecteur CSS. Le résultat de cette fonction permet d'identifier quels éléments de la page sont responsables des valeurs de vos signaux Web essentiels.

diagnostics.html

function getSelector(node, maxLen = 100) {
 let sel = '';
 try {
   while (node && node.nodeType !== 9) {
     const part = node.id ? '#' + node.id : node.nodeName.toLowerCase() + (
       (node.className && node.className.length) ?
       '.' + Array.from(node.classList.values()).join('.') : '');
     if (sel.length + part.length > maxLen - 1) return sel || part;
     sel = sel ? part + '>' + sel : part;
     if (node.id) break;
     node = node.parentNode;
   }
 } catch (err) {
   // Do nothing...
 }
 return sel;
}

Récupérer les informations de `LayoutShift`

Enregistrez chaque décalage de mise en page susceptible de générer une quantité excessive de données. Les fonctions ci-dessous se concentrent uniquement sur l'entrée LayoutShift la plus grande et la fonction LayoutShiftSource la plus grande dans cette entrée. Lors de vos optimisations, vous pouvez ainsi vous focaliser sur les causes les plus importantes de décalages de mise en page sur votre site. Quand vous identifiez les causes des décalages de mise en page et trouvez des solutions pour les limiter au maximum, la source de décalage de mise en page affichée dans les rapports est modifiée afin de vous indiquer la nouvelle cause critique.

diagnostics.html

function getLargestLayoutShiftEntry(entries) {
 return entries.reduce((a, b) => a && a.value > b.value ? a : b);
}

function getLargestLayoutShiftSource(sources) {
 return sources.reduce((a, b) => {
   return a.node && a.previousRect.width * a.previousRect.height >
       b.previousRect.width * b.previousRect.height ? a : b;
 });
}

getLargestLayoutShiftEntry() affiche la plus grande entrée de décalage de mise en page durant le cycle de vie de la page vue.
getLargestLayoutShiftSource() affiche uniquement la plus grande source de décalage de mise en page dans cette entrée.

Déterminer si le FID s'est produit avant ou après `DOMContentLoaded`

L'événement DOMContentLoaded se produit après le chargement et l'analyse du code HTML de la page. Ce délai inclut le chargement des scripts synchrones, différés ou de module, ainsi que de l'ensemble des modules importés de manière statique. Cette fonction affiche true si la première entrée utilisateur s'est produite avant DOMContentLoaded, ou false si elle s'est produite après.

diagnostics.html

function wasFIDBeforeDCL(fidEntry) {
 const navEntry = performance.getEntriesByType('navigation')[0];
 return navEntry && fidEntry.startTime < navEntry.domContentLoadedEventStart;
}

Identifier l'élément cible du FID

L'élément avec lequel vous avez interagi peut aussi être un signal de débogage potentiellement utile. Bien que l'interaction avec l'élément ne contribue pas au FID (le FID ne représentant qu'une partie de la latence totale de l'événement), il peut être utile de savoir avoir quels éléments interagissent les utilisateurs afin de déterminer la meilleure façon de l'améliorer.

Pour récupérer l'élément associé au premier événement d'entrée, référencez la propriété target de l'entrée first-input :

diagnostics.html

function getFIDDebugTarget(entries) {
  return entries[0].target;
}

Identifier le type d'événement d'entrée du FID

En outre, il peut être utile de capturer le type d'événement ayant déclenché la mesure du FID pour identifier comment vos utilisateurs interagissent avec vos pages.

diagnostics.html

function getFIDEventType(entries) {
  return entries[0].name;
}

Structurer les informations de débogage pour chaque signal Web essentiel

La dernière étape avant l'envoi de ce code à Google Analytics consiste à structurer les informations à partir des entrées, y compris celles renvoyées par les fonctions ci-dessus.

diagnostics.html

function getDebugInfo(name, entries = []) {
  // In some cases there won't be any entries (e.g. if CLS is 0,
  // or for LCP after a bfcache restore), so we have to check first.
  if (entries.length) {
    if (name === 'LCP') {
      const lastEntry = entries[entries.length - 1];
      return {
        debug_target: getSelector(lastEntry.element),
        event_time: lastEntry.startTime,
      };
    } else if (name === 'FID') {
      const firstEntry = entries[0];
      return {
        debug_target: getSelector(firstEntry.target),
        debug_event: firstEntry.name,
        debug_timing: wasFIDBeforeDCL(firstEntry) ? 'pre_dcl' : 'post_dcl',
        event_time: firstEntry.startTime,
      };
    } else if (name === 'CLS') {
      const largestEntry = getLargestLayoutShiftEntry(entries);
      if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
        const largestSource = getLargestLayoutShiftSource(largestEntry.sources);
        if (largestSource) {
          return {
            debug_target: getSelector(largestSource.node),
            event_time: largestEntry.startTime,
          };
        }
      }
    }
  }
  // Return default/empty params in case there are no entries.
  return {
    debug_target: '(not set)',
  };
}

Envoyer les données à Google Analytics

Enfin, créez une fonction qui récupère les paramètres de l'événement web-vitals et les transmet à Google Analytics.

diagnostics.html

function sendToGoogleAnalytics({ name, delta, value, id, entries }) {
  gtag('event', name, {
    // Built-in params:
    value: delta, // Use `delta` so the value can be summed.
    // Custom params:
    metric_id: id, // Needed to aggregate events.
    metric_value: value, // Value for querying in BQ
    metric_delta: delta, // Delta for querying in BQ
    // Send the returned values from getDebugInfo() as custom parameters
      ...getDebugInfo(name, entries)
  });
}

Enregistrez la fonction avec chacune des fonctions web-vitals. Elle se déclenche lorsque le navigateur est prêt à mesurer chaque événement :

diagnostics.html

getLCP(sendToGoogleAnalytics);
getFID(sendToGoogleAnalytics);
getCLS(sendToGoogleAnalytics);

Bravo ! Vous envoyez désormais des événements web-vitals à Google Analytics.

6. Vérifier que les données web-vitals sont renseignées dans Google Analytics

Pour vous assurer que vos événements sont enregistrés par la propriété Google Analytics 4, procédez comme suit :

Ouvrez votre propriété Google Analytics 4 et accédez à Rapports.

Sélectionnez Temps réel.

Actualisez plusieurs fois la page de test et veillez à cliquer dessus pour déclencher des événements FID.
Accédez à la section Nombre d'événements par nom d'événement dans l'interface utilisateur Aperçu en temps réel. Les événements LCP, FID et CLS doivent s'afficher.

Cliquez sur l'un des noms d'événement pour afficher les paramètres transmis avec ces événements.

Cliquez sur ces clés de paramètre pour afficher un récapitulatif des valeurs reçues par Google Analytics.

Vous pouvez ajouter d'autres données à vos informations de débogage, comme les noms de modèles de pages ou les autres événements de page liés au FID et évoqués précédemment dans cet atelier de programmation. Il vous suffit de modifier les instructions return dans la fonction getDebugInfo().

Une fois que vous êtes satisfait des données provenant de vos pages de test, déployez votre nouveau code GA en production sur votre site, puis passez à l'étape suivante.

7. Interroger les données dans BigQuery

Lorsque votre code Google Analytics est en ligne depuis quelques jours, vous pouvez commencer à interroger les données dans BigQuery. Commencez par vérifier qu'elles sont transmises à BigQuery.

Ouvrez Google Cloud Console, puis sélectionnez votre projet dans le menu déroulant en haut de l'écran.
Dans le menu de navigation en haut à gauche de l'écran, cliquez sur BigQuery sous l'en-tête Analytics.
Dans le volet Explorateur, développez votre projet pour afficher votre ensemble de données Google Analytics. Le nom de l'ensemble de données est analytics_, suivi de votre ID de propriété Google Analytics 4 (par exemple, analytics_229787100).
Développez l'ensemble de données. Une table events_ doit s'afficher. Le nombre entre parenthèses correspond à la durée de disponibilité pour des requêtes (en jours).

Envoyer une sous-requête pour ne sélectionner que les événements "Signaux Web essentiels"

Pour interroger un ensemble de données qui n'inclut que nos événements "Signaux Web essentiels", commencez par une sous-requête qui sélectionne les 28 derniers jours des événements LCP, CLS et FID. Cette sous-requête recherche notamment la dernière valeur indiquée de chaque ID d'événement web-vitals à l'aide de la clé metric_id. Ainsi, vous vous assurez de ne pas comptabiliser plusieurs fois les mêmes événements "Signaux Web essentiels".

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
 SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM
 (
   SELECT *
   , IF (ROW_NUMBER() OVER (
     PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
     ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
   ) = 1, true, false) AS is_last_received_value
   # Make sure to update your project ID and GA4 property ID here!
   FROM `YOUR_PROJECT_ID.analytics_YOUR_GA_PROPERTY_ID.events_*`
   WHERE event_name in ('CLS', 'FID', 'LCP') AND
     _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  )
  WHERE is_last_received_value
)

Toutes vos requêtes sur cet ensemble de données sont basées sur ce principe. Votre requête principale sera exécutée sur la table temporaire web_vitals_events.

Structure des événements GA4

Chaque donnée d'événement Google Analytics 4 est stockée dans le STRUCT d'une colonne event_params. Chacun des paramètres d'événement que vous transmettez à GA4 sur votre site est représenté par sa clé. De plus, la valeur est un STRUCT avec une clé pour chaque type de données potentiel. Dans l'exemple ci-dessus, la clé metric_value peut avoir une int_value ou une double_value. La fonction COALESCE() est donc utilisée. Pour obtenir la debug_target que vous avez transmise précédemment, sélectionnez la clé string_value dans la debug_target.

...
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = "debug_target") as debug_target
...

Identifier les pages et les éléments les moins performants

debug_target est une chaîne de sélecteur CSS qui correspond à l'élément de la page le plus pertinent pour la valeur de la métrique.

Avec le CLS, debug_target représente l'élément le plus grand du décalage de mise en page le plus important ayant contribué à la valeur CLS. Si aucun élément n'a été décalé, la valeur de debug_target est null.

Les requêtes suivantes permettent de lister les pages de la pire à la meilleure en fonction de leur CLS au 75e centile, regroupées par debug_target :

# Main query logic
SELECT
  page_path,
  debug_target,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS metric_p75,
  COUNT(1) as page_views
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = "debug_target") as debug_target,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
    *
  FROM web_vitals_events
  WHERE metric_name = 'CLS'
)
GROUP BY 1, 2
# OPTIONAL: You may want to limit your calculations to pages with a
# minimum number of pageviews to reduce noise in your reports.
# HAVING page_views > 50
ORDER BY metric_p75 DESC

Si vous savez quels éléments sont décalés sur la page, vous devriez pouvoir identifier l'origine du problème et le résoudre beaucoup plus facilement.

Gardez à l'esprit que les éléments signalés ici peuvent ne pas correspondre aux éléments décalés lorsque vous déboguez vos pages en local. C'est pourquoi il est très important de collecter ces données au départ. Si vous ignorez que des problèmes existent, vous aurez du mal à les résoudre.

Déboguer d'autres métriques

La requête ci-dessus affiche les résultats de la métrique CLS. Toutefois, vous pouvez utiliser la même technique afin de créer des rapports sur les cibles de débogage pour le LCP et le FID. Il vous suffit de remplacer la clause WHERE par la métrique appropriée pour effectuer le débogage :

# Replace:
# WHERE metric_name = 'CLS'
# With:
WHERE metric_name = 'LCP'

8. Visualiser les résultats de la requête dans Data Studio

BigQuery permet de visualiser rapidement des résultats de requête via Data Studio. Data Studio est un outil de visualisation de données et de tableaux de bord gratuit. Pour visualiser vos résultats de requête après avoir exécuté votre requête dans l'UI BigQuery, cliquez sur Explorer les données, puis sélectionnez Explorer avec Data Studio.

Explorer avec l'option Data Studio dans BigQuery

Un lien direct de BigQuery vers Data Studio est alors créé dans la vue "Explorer". Dans cette vue, vous pouvez sélectionner les champs que vous souhaitez visualiser, choisir des types de graphiques, configurer des filtres et créer des graphiques ad hoc pour une analyse visuelle rapide. À partir des résultats de la requête ci-dessus, vous pouvez créer ce graphique en courbes pour observer l'évolution des valeurs LCP au fil du temps :

Graphique en courbes des valeurs LCP quotidiennes dans Data Studio

Grâce à ce lien direct entre BigQuery et Data Studio, vous pouvez créer des graphiques rapides à partir de n'importe quelle requête et effectuer une analyse visuelle. Toutefois, si vous souhaitez effectuer d'autres analyses, vous pouvez consulter plusieurs graphiques dans un tableau de bord interactif afin d'obtenir une vue plus globale ou pour pouvoir afficher le détail des données. Grâce à ce tableau de bord pratique, vous n'avez pas besoin d'écrire des requêtes ni de générer des graphiques manuellement chaque fois que vous souhaitez analyser vos métriques.

Vous pouvez créer un tableau de bord dans Data Studio à l'aide du connecteur BigQuery natif. Pour ce faire, accédez à datastudio.google.com, créez une source de données, sélectionnez le connecteur BigQuery, puis choisissez l'ensemble de données que vous voulez interroger :

Utiliser le connecteur BigQuery natif dans Data Studio

9. Matérialiser les données des signaux Web

Lorsque vous créez des tableaux de bord pour les données d'événement "Signaux Web", comme décrit ci-dessus, il n'est pas efficace d'utiliser directement l'ensemble de données d'exportation Google Analytics 4. En raison de la structure des données GA4 et du prétraitement requis pour les métriques des signaux Web, certaines parties de votre requête finissent par s'exécuter plusieurs fois. Cela entraîne deux problèmes concernant les performances du tableau de bord et les coûts associés à BigQuery.

Vous pouvez utiliser gratuitement le mode bac à sable de BigQuery. Avec la version gratuite de BigQuery, le premier téraoctet de données de requêtes traitées chaque mois est gratuit. Pour les méthodes d'analyse décrites dans cet article, sauf si vous utilisez un ensemble de données très volumineux ou que vous interrogez régulièrement l'ensemble de données, vous devriez être en mesure de respecter cette limite mensuelle. Toutefois, si votre site Web génère un volume de trafic important et que vous souhaitez surveiller régulièrement différentes métriques à l'aide d'un tableau de bord interactif rapide, nous vous conseillons de prétraiter et de matérialiser vos données de signaux Web tout en utilisant les fonctionnalités de BigQuery, telles que le partitionnement, le clustering et la mise en cache.

Le script suivant prétraite vos données BigQuery (table source) et crée une table matérialisée (table cible).

# Materialize Web Vitals metrics from GA4 event export data

# Replace target table name
CREATE OR REPLACE TABLE YOUR_PROJECT_ID.analytics_YOUR_GA_PROPERTY_ID.web_vitals_summary
  PARTITION BY DATE(event_timestamp)
AS
SELECT
  ga_session_id,
  IF(
    EXISTS(SELECT 1 FROM UNNEST(events) AS e WHERE e.event_name = 'first_visit'),
    'New user',
    'Returning user') AS user_type,
  IF(
    (SELECT MAX(session_engaged) FROM UNNEST(events)) > 0, 'Engaged', 'Not engaged')
    AS session_engagement,
  evt.* EXCEPT (session_engaged, event_name),
  event_name AS metric_name,
  FORMAT_TIMESTAMP('%Y%m%d', event_timestamp) AS event_date
FROM
  (
    SELECT
      ga_session_id,
      ARRAY_AGG(custom_event) AS events
    FROM
      (
        SELECT
          ga_session_id,
          STRUCT(
            country,
            device_category,
            device_os,
            traffic_medium,
            traffic_name,
            traffic_source,
            page_path,
            debug_target,
            event_timestamp,
            event_name,
            metric_id,
            IF(event_name = 'LCP', metric_value / 1000, metric_value) AS metric_value,
            user_pseudo_id,
            session_engaged,
            session_revenue) AS custom_event
        FROM
          (
            SELECT
              (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
                AS ga_session_id,
              (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
                AS metric_id,
              ANY_VALUE(device.category) AS device_category,
              ANY_VALUE(device.operating_system) AS device_os,
              ANY_VALUE(traffic_source.medium) AS traffic_medium,
              ANY_VALUE(traffic_source.name) AS traffic_name,
              ANY_VALUE(traffic_source.source) AS traffic_source,
              ANY_VALUE(
                REGEXP_SUBSTR(
                  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
                  r'^[^?]+')) AS page_path,
              ANY_VALUE(
                (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'debug_target'))
                AS debug_target,
              ANY_VALUE(user_pseudo_id) AS user_pseudo_id,
              ANY_VALUE(geo.country) AS country,
              ANY_VALUE(event_name) AS event_name,
              SUM(ecommerce.purchase_revenue) AS session_revenue,
              MAX(
                (
                  SELECT
                    COALESCE(
                      value.double_value, value.int_value, CAST(value.string_value AS NUMERIC))
                  FROM UNNEST(event_params)
                  WHERE key = 'session_engaged'
                )) AS session_engaged,
              TIMESTAMP_MICROS(MAX(event_timestamp)) AS event_timestamp,
              MAX(
                (
                  SELECT COALESCE(value.double_value, value.int_value)
                  FROM UNNEST(event_params)
                  WHERE key = 'metric_value'
                )) AS metric_value,
            FROM
              # Replace source table name
              `YOUR_PROJECT_ID.analytics_YOUR_GA_PROPERTY_ID.events_*`
            WHERE
              event_name IN ('LCP', 'FID', 'CLS', 'first_visit', 'purchase')
            GROUP BY
              1, 2
          )
      )
    WHERE
      ga_session_id IS NOT NULL
    GROUP BY ga_session_id
  )
CROSS JOIN UNNEST(events) AS evt
WHERE evt.event_name NOT IN ('first_visit', 'purchase');

Cet ensemble de données matérialisé présente plusieurs avantages :

La structure des données est aplatie et devient plus facile à interroger.
Elle ne conserve que les événements "Signaux Web" de l'ensemble de données GA4 d'origine.
Les informations sur l'ID de session, le type d'utilisateur (nouveau ou connu) et l'engagement sont disponibles directement dans des colonnes.
La table est partitionnée par date et regroupée par nom de métrique. Cela permet généralement de réduire la quantité de données traitées pour chaque requête.
Comme vous n'avez pas besoin d'utiliser de caractères génériques pour interroger cette table, les résultats de requête peuvent être mis en cache pendant 24 heures maximum. Cela permet de réduire les coûts liés à la répétition de la même requête.
Si vous utilisez BigQuery BI Engine, vous pouvez exécuter des fonctions et opérateurs SQL optimisés sur cette table.

Vous pouvez interroger directement cette table matérialisée à partir de l'UI BigQuery ou vous en servir dans Data Studio à l'aide du connecteur BigQuery.

Exécuter des tâches régulières de matérialisation

Si vous exécutez la requête ci-dessus sans avoir indiqué une période, elle s'exécute sur l'intégralité de votre ensemble de données Google Analytics. Vous devez éviter de le faire tous les jours, car vous relancez le traitement d'une grande quantité de données historiques. Vous pouvez modifier votre requête pour n'ajouter que les données du jour précédent en supprimant l'instruction CREATE or REPLACE TABLE au début de la requête et en ajoutant un critère à la clause WHERE dans la sous-requête sur la table events_intraday_ :

FROM
  # Replace source table name
  `YOUR_PROJECT_ID.analytics_YOUR_GA_PROPERTY_ID.events_intraday_*`
WHERE
  event_name IN ('LCP', 'FID', 'CLS', 'first_visit', 'purchase')
  # The _TABLE_SUFFIX replaces the asterisk (*) in the table name
  #
  AND _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY)

Cette requête ne renvoie que les données de la veille. Vous pouvez ensuite planifier l'exécution quotidienne de votre requête à l'aide de la console BigQuery.

10. Visualiser les données dans Google Data Studio

Google Data Studio permet de lire les données de Google BigQuery de manière native. Maintenant que vous disposez des données web-vitals de Google Analytics 4 dans BigQuery, vous pouvez utiliser le connecteur BigQuery de Data Studio pour lire directement votre table matérialisée.

Utiliser le connecteur de signaux Web

Créer un tableau de bord à partir de zéro prend du temps. C'est pourquoi nous avons développé un package qui crée un modèle de tableau de bord pour vous. Tout d'abord, assurez-vous d'avoir matérialisé vos signaux Web à l'aide de la requête ci-dessus. Accédez ensuite au connecteur de signaux Web pour Data Studio via le lien suivant : goo.gle/web-vitals-connector.

Une fois que vous avez accordé une autorisation unique, l'écran de configuration suivant doit s'afficher :

Écran d'autorisation du connecteur de signaux Web

Indiquez l'ID de la table BigQuery matérialisée (la table cible) et l'ID de votre projet de facturation BigQuery. Lorsque vous cliquez sur ASSOCIER, Data Studio crée un tableau de bord à partir d'un modèle et y associe vos données. Vous pouvez modifier et partager le tableau de bord à votre guise. Si vous créez un tableau de bord une seule fois, vous n'avez pas besoin d'accéder à nouveau au lien du connecteur, sauf si vous voulez créer plusieurs tableaux à partir de différents ensembles de données.

Parcourir le tableau de bord

Lorsque vous parcourez le tableau de bord, vous pouvez consulter les tendances quotidiennes des métriques de signaux Web ainsi que des informations sur l'utilisation de votre site Web (utilisateurs et sessions, par exemple) dans l'onglet "Résumé".

Dans l'onglet "Analyse des utilisateurs", vous pouvez sélectionner une métrique et obtenir le détail du centile des métriques, ainsi que le nombre d'utilisateurs, en fonction de différentes métriques d'utilisation et de métriques commerciales.

L'onglet "Analyse du chemin de la page" vous permet d'identifier les points problématiques sur votre site. Vous pouvez choisir une métrique pour voir l'aperçu, mais aussi afficher le graphique à nuage de points de tous les chemins de la page avec la valeur de centile sur l'axe y et le nombre d'enregistrements sur l'axe x. Ce graphique peut vous permettre d'identifier les pages présentant des valeurs de métriques inférieures aux attentes. Une fois les pages sélectionnées, vous pouvez afficher une vue détaillée de la zone problématique à l'aide du graphique à nuage de points du tableau "Chemin de la page" ou en consultant le tableau "Cible de débogage".

L'onglet "Analyse des revenus" illustre comment vous pouvez surveiller vos métriques commerciales et de performances au même endroit. Cette section représente toutes les sessions au cours desquelles l'utilisateur a effectué un achat. Vous pouvez comparer les revenus générés et l'expérience utilisateur au cours d'une session spécifique.

11. Autres ressources

Vous avez terminé cet atelier de programmation. Vous devriez désormais être capable de suivre les performances de vos signaux Web essentiels sur votre site avec un niveau de précision élevé. Vous devriez également savoir identifier les types de pages et les éléments de votre site qui déclenchent des signaux Web essentiels élevés, pour pouvoir vous concentrer sur les optimisations.

Complément d'information

Le site web.dev contient de nombreux articles et études de cas avec des stratégies pour améliorer les signaux Web essentiels. Commencez par lire les articles sur l'optimisation de chaque métrique :

Optimize Largest Contentful Paint (Optimiser le Largest Contentful Paint)
Optimize Cumulative Layout Shift (Optimiser le Cumulative Layout Shift)
Optimize First Input Delay (Optimiser le First Input Delay)

Documents de référence

Pour cet atelier de programmation, nous nous sommes beaucoup inspirés du contenu de deux articles de web.dev :
L'article sur la mesure des signaux Web dans le champ
L'article sur l'utilisation des données de signaux Web de GA4 dans BigQuery, qui contient de nombreux autres exemples de requêtes utiles
Pour en savoir plus sur l'intégration de GA4 > BigQuery Export, consultez le Centre d'aide Google Analytics.

Mesurer les performances avec web-vitals.js, Google Analytics et BigQuery

1. Avant de commencer

Objectifs de l'atelier

Ce dont vous avez besoin

Avant de commencer

2. Ajouter la bibliothèque web-vitals et l'outil gtag à une page Web

3. Mesurer les signaux Web essentiels de la page Web

4. Explorer les données sur les tests web-vitals plus en détail

CLS entries

LCP entries

entries du FID

5. Préparer les données web-vitals et les envoyer à Google Analytics 4

Générer un sélecteur pour identifier le nœud cible de l'entrée

Récupérer les informations de LayoutShift

Déterminer si le FID s'est produit avant ou après DOMContentLoaded

Identifier l'élément cible du FID

Identifier le type d'événement d'entrée du FID

Structurer les informations de débogage pour chaque signal Web essentiel

Envoyer les données à Google Analytics

6. Vérifier que les données web-vitals sont renseignées dans Google Analytics

7. Interroger les données dans BigQuery

Envoyer une sous-requête pour ne sélectionner que les événements "Signaux Web essentiels"

Structure des événements GA4

Identifier les pages et les éléments les moins performants

Déboguer d'autres métriques

8. Visualiser les résultats de la requête dans Data Studio

9. Matérialiser les données des signaux Web

Exécuter des tâches régulières de matérialisation

10. Visualiser les données dans Google Data Studio

Utiliser le connecteur de signaux Web

Parcourir le tableau de bord

11. Autres ressources

Complément d'information

Documents de référence

CLS `entries`

LCP `entries`

`entries` du FID

Récupérer les informations de `LayoutShift`

Déterminer si le FID s'est produit avant ou après `DOMContentLoaded`