De combien le session replay ralentit-il la vitesse d'un site ?

Le session replay ralentit-il les performances d'un site ?

Le session replay, c'est-à-dire la relecture de visites enregistrées, coûte à une page sur trois postes, et c'est pourquoi la réponse à "le session replay ralentit-il les performances d'un site" est oui : des octets de script au premier chargement, du CPU de thread principal passé à sérialiser les mutations du DOM, et de la bande passante montante pendant la visite. L'ampleur de chaque poste dépend de l'enregistreur, de la taille du DOM de la page et de la configuration d'échantillonnage. Sentry publie un benchmark daté avec sa méthodologie jointe, et ces chiffres placent le coût visible sur le thread principal, pas sur le réseau.

Quels sont les trois coûts de l'enregistrement d'une session ?

Un enregistreur facture une page une fois au chargement, puis en continu pendant le reste de la visite. Le frais unique, c'est le bundle, qui se télécharge, se parse et s'exécute avant de pouvoir prendre son premier instantané du DOM. Le frais continu se partage entre le CPU, qui sérialise les enregistrements de mutation en événements JSON, et le réseau, qui envoie ces événements par lots. Comme le session replay reconstitue une visite à partir des mutations du DOM plutôt que d'images vidéo, c'est la ligne CPU qui suit la taille de votre page.

Quelle est la taille d'un script de session replay ?

Le bundle de l'enregistreur est la seule partie qu'un visiteur paie avant que la page devienne interactive. Bundlephobia mesure @rrweb/record 2.1.4, la moitié enregistrement de rrweb, à 23 262 bytes gzipped, et le paquet rrweb complet avec le lecteur à 78 597 bytes gzipped. La documentation de Sentry indique elle-même que "as of version 7.78.0 the Session Replay plugin is an additional ~36KB gzipped" en plus de son SDK d'erreurs. Flowsery livre un seul script sous les 10 KB. Chargez en asynchrone l'enregistreur que vous choisissez pour que ses octets ne se placent jamais devant le premier rendu, puis faites vous-même la comparaison avant et après dans Lighthouse au lieu de vous fier à un badge de taille.

Combien de temps de thread principal coûte la sérialisation du DOM ?

Le coût CPU se concentre sur le premier instantané complet, puis retombe à du travail par lot pour le reste de la session. rrweb enregistre un MutationObserver, et c'est pourquoi son guide précise que rrweb "does not support IE11 and below because it uses the MutationObserver API" ; cette API remet à l'enregistreur un lot d'enregistrements en file plutôt que de se déclencher à chaque changement du DOM, si bien que la sérialisation tourne lot par lot, et non à chaque nœud touché. Des chiffres publiés existent pour l'instantané : l'issue rrweb #1337 a mesuré la sérialisation de l'instantané complet à 34,55 ms en moyenne sur un document de divs très imbriqués, et à 27,35 ms après suppression des appels répétés à closest().

L'article web.dev de Google sur les longues tâches définit le seuil et le calcul :

blocking time = task duration - 50 ms

Un instantané de 34,55 ms contribue donc pour 0 ms de blocking time, parce que "any task that takes longer than 50 milliseconds is a long task" et que rien de plus court ne compte. Les instantanés sur des arbres DOM bien plus grands franchissent cette ligne, et le tracker de rrweb en porte les signalements : l'issue #1547 indique qu'une vérification interne "lags by 1 to 3 seconds on pages with lots of nodes", et l'issue #1820 documente le blocage du thread principal quand un widget Zendesk est présent sur la page. Aucun benchmark public ne relie le nombre de nœuds du DOM aux millisecondes de sérialisation, alors traitez toute annonce d'un chiffre CPU fixe par page comme non mesurée.

Les enregistreurs peuvent repousser le travail non urgent dans requestIdleCallback, mais la spécification du W3C plafonne chaque deadline d'inactivité "to a maximum value of 50ms" pour que le navigateur garde de la marge et réponde aux entrées dans la fenêtre de 100 ms qui paraît instantanée. MDN avertit que sans l'option timeout "it's possible multiple seconds will elapse before the callback is fired", donc la planification en temps mort convient à la compression et à l'envoi, pas à l'instantané.

Quelle bande passante un session replay envoie-t-il ?

Le benchmark de Sentry a mesuré l'upload réseau de son scénario passant de 3,84 KB avec le SDK d'erreurs seul à 272,51 KB avec le replay activé, pendant que le download restait plat à 8,09 MB et 8,07 MB. L'upload est le coût que portent à la fois votre serveur et la connexion de votre visiteur, et il croît linéairement avec les sessions enregistrées :

monthly replay upload = uploaded bytes per session x sessions per month

Avec les 272,51 KB mesurés par Sentry par scénario enregistré et 50 000 sessions par mois, cela fait 13 625 500 KB, soit environ 13 GB d'upload. Les applications riches en texte au DOM peu changeant tombent sous ce chiffre et celles riches en canvas ou en animations passent au-dessus, et c'est exactement pour cela que la recette de stockage de rrweb existe.

Le session replay change-t-il les Core Web Vitals ?

Dans le run publié par Sentry, le session replay a laissé Largest Contentful Paint et Cumulative Layout Shift tranquilles et a déplacé le Total Blocking Time. Le benchmark était "last updated on Sept 25, 2023" et a tourné "on an Apple M1 MacBook Pro against a remote preview server and a remote API backend with 50 iterations".

Le Total Blocking Time a augmenté de 415,13 ms entre le SDK d'erreurs et le build avec replay, et Sentry note qu'une page de test plus simple "produced an increase of ~100 ms of total JS blocking time". La stabilité visuelle n'a pas bougé du tout, ce qui correspond au fonctionnement de la métrique : l'enregistrement lit le DOM et Cumulative Layout Shift note le mouvement à l'intérieur. Un portable M1 n'est pas un téléphone Android de milieu de gamme, et personne n'a publié le même benchmark sur du matériel mobile bas de gamme, alors mesurez les Core Web Vitals sur vos propres données de terrain avant de décider que les chiffres se transposent.

Comment réduire le surcoût du session replay sans perdre la relecture ?

L'échantillonnage retire les événements qui coûtent le plus et prouvent le moins. La recette de stockage de rrweb recommande mousemove: false pour supprimer le mouvement de souris, scroll: 150 pour n'émettre au plus qu'un événement de scroll par 150 ms, media: 800 pour l'interaction média, et input: 'last' pour n'enregistrer que la valeur finale d'un champ saisi, au motif que l'échantillonnage "can reduce the storage size by dropping some events". Au-delà de l'échantillonnage, blockClass saute des sous-arbres entiers, puisque "an element with the class name .rr-block will not be recorded, instead it will replay as a placeholder", et slimDOMOptions retire les parties du DOM sans valeur pour la relecture. Commencez par mousemove et scroll sur votre page la plus lourde, puis remesurez. Le masquage tourne dans la même passe de sérialisation, donc la façon dont vous configurez le masquage change le coût CPU autant que votre posture de confidentialité.

Questions fréquentes

Le session replay bloque-t-il le premier rendu d'une page ?

Non quand l'enregistreur charge en asynchrone, parce qu'un script async ne se place pas sur le chemin critique du parser. Ce qui peut atterrir près du premier rendu, c'est l'instantané initial du DOM, qui tourne après le démarrage de l'enregistreur et suit le nombre de nœuds. Le benchmark de Sentry a montré Largest Contentful Paint à 1529,11 ms avec le replay activé contre 1599,19 ms sans aucun SDK, donc le premier rendu n'était pas le point de tension dans ce run.

Combien le script d'enregistrement ajoute-t-il au poids de la page ?

Bundlephobia liste @rrweb/record 2.1.4 à 23 262 bytes gzipped et le bundle rrweb complet à 78 597 bytes gzipped, et Sentry documente son plugin Session Replay à environ 36 KB gzipped en plus de son SDK d'erreurs. Le script de Flowsery pèse moins de 10 KB. Vérifiez la taille de transfert compressée dans le panneau réseau de votre navigateur, car les chiffres non compressés exagèrent ce qu'un visiteur télécharge.

Le session replay augmente-t-il la consommation de données d'un visiteur ?

Oui, côté upload. Sentry a mesuré 272,51 KB envoyés pour son scénario de benchmark avec le replay activé, contre 3,84 KB avec le SDK d'erreurs seul, alors que le volume de download n'a pas bougé. Les visiteurs sur forfait mobile limité paient cet upload, et c'est l'argument le plus fort pour sortir mousemove du flux par échantillonnage.

Pourquoi le session replay coûte-t-il plus de CPU sur certaines pages ?

Le travail de sérialisation est fonction du nombre de nœuds du DOM et du taux de mutation, pas des pages vues. Un dashboard qui re-rend un grand tableau à chaque frappe produit plus d'enregistrements de mutation qu'un article statique, et l'issue rrweb #1547 signale des latences de 1 à 3 secondes "on pages with lots of nodes". Les widgets tiers s'y ajoutent, ce que documente l'issue #1820 pour le Zendesk Web Widget.

Le session replay nuit-il au référencement ?

Seulement par le même chemin que n'importe quel script, en déplaçant les Core Web Vitals. La documentation de recherche de Google indique que ses systèmes de classement principaux récompensent une bonne page experience, tout en avertissant que les Core Web Vitals seules ne garantissent pas un classement (Google Search Central). Puisque la mesure de Sentry a déplacé le Total Blocking Time et laissé Largest Contentful Paint et Cumulative Layout Shift à plat, la métrique à surveiller est la réactivité du thread principal.

Comment mesurer le surcoût du session replay sur mon propre site ?

Chargez votre page la plus lourde avec l'enregistreur désactivé, enregistrez un profil de performance dans Chrome DevTools, puis recommencez avec l'enregistreur activé et comparez le temps de scripting, le nombre de longues tâches et les octets transférés. Lancez chaque configuration plusieurs fois et comparez les médianes, car des runs isolés varient plus que l'effet que vous mesurez. Les données de terrain issues d'appareils réels tranchent ce qu'un profil de laboratoire ne fait que suggérer.

Désactiver le suivi de mousemove économise-t-il du temps CPU ou seulement de la bande passante ?

Les deux. Le tableau des coûts de l'article place l'échantillonnage parmi les leviers du thread principal comme parmi ceux de la bande passante montante, parce que chaque événement mousemove ignoré est un enregistrement de mutation de moins à sérialiser et un événement de moins à envoyer. Désactiver mousemove avec mousemove: false est le même levier que recommande en premier la recette de stockage de rrweb.

Qu'est-ce qu'une 'tâche longue' que le session replay doit éviter ?

L'article web.dev de Google définit une tâche longue comme tout travail qui dépasse 50 millisecondes sur le thread principal, le temps de blocage correspondant à la durée de la tâche moins 50 ms. Le benchmark de snapshot complet de rrweb a mesuré 34.55 ms sur un document de divs profondément imbriquées, ce qui reste sous ce seuil et ne produit aucun temps de blocage. Les snapshots sur des arbres DOM bien plus grands sont ceux qui franchissent ce seuil, comme le montrent les rapports du suivi d'incidents de rrweb évoquant des ralentissements de plusieurs secondes.

requestIdleCallback peut-il empêcher le session replay de bloquer le thread principal ?

Seulement pour le travail qui peut attendre. Les enregistreurs peuvent déplacer la compression et l'envoi vers requestIdleCallback, mais la spécification du W3C plafonne chaque fenêtre d'inactivité à 50 ms, et MDN prévient que sans option timeout un callback peut mettre plusieurs secondes à se déclencher. La planification en temps d'inactivité convient donc au travail en arrière-plan, pas au premier snapshot du DOM qui doit s'exécuter dès le démarrage de l'enregistreur.

Le session replay coûte-t-il plus cher avec un CPU lent ou une connexion réseau lente ?

Dans le test publié par Sentry, c'est le CPU qui porte la plus grande partie du coût. Le téléchargement est resté stable à 8.09 MB contre 8.07 MB avec le replay activé, tandis que le Total Blocking Time est passé de 2621.67 ms à 3036.80 ms, et la conclusion de l'article est que le coût se situe sur le thread principal, pas sur le réseau. L'envoi montant, lui, est passé de 3.84 KB à 272.51 KB, donc une connexion à données limitées le sent aussi, juste moins qu'un CPU lent.