Quanto o session replay deixa a velocidade do site mais lenta?

O session replay deixa a performance do site mais lenta?

O session replay, ou seja, a reprodução de visitas gravadas, custa a uma página em três lugares, e é por isso que a resposta para "o session replay deixa a performance do site mais lenta" é sim: bytes de script no primeiro carregamento, CPU da thread principal serializando mutações do DOM e banda de upload durante a visita. O tamanho de cada custo depende do gravador, do tamanho do DOM da página e da configuração de amostragem. A Sentry publica um benchmark datado com a metodologia junto, e esses números colocam o custo visível na thread principal, não na rede.

Quais são os três custos de gravar uma sessão?

Um gravador cobra de uma página uma vez no carregamento e depois continuamente pelo resto da visita. A cobrança única é o bundle, que baixa, é parseado e executa antes de conseguir tirar seu primeiro snapshot do DOM. A cobrança contínua se divide entre CPU, que serializa os registros de mutação em eventos JSON, e rede, que sobe esses eventos em lotes. Como o session replay reconstrói uma visita a partir de mutações do DOM em vez de quadros de vídeo, a linha de CPU é a que escala com a sua página.

Qual é o tamanho de um script de session replay?

O bundle do gravador é a única parte que um visitante paga antes de a página ficar interativa. O Bundlephobia mede o @rrweb/record 2.1.4, a metade de gravação do rrweb, em 23.262 bytes gzipped, e o pacote rrweb completo com o player em 78.597 bytes gzipped. A própria documentação da Sentry afirma que "as of version 7.78.0 the Session Replay plugin is an additional ~36KB gzipped" em cima do SDK de erros. A Flowsery entrega um script abaixo de 10 KB. Carregue o gravador que você escolher de forma assíncrona para que os bytes dele nunca fiquem na frente do primeiro paint, e depois faça você mesmo a comparação antes e depois no Lighthouse em vez de confiar em um selo de tamanho.

Quanto tempo de thread principal custa a serialização do DOM?

O custo de CPU se concentra no primeiro snapshot completo e depois cai para trabalho por lote no resto da sessão. O rrweb registra um MutationObserver, e por isso o guia dele afirma que o rrweb "does not support IE11 and below because it uses the MutationObserver API"; essa API entrega ao gravador um lote enfileirado de registros em vez de disparar uma vez por mudança do DOM, então a serialização roda um lote de cada vez, não a cada nó tocado. Existem números publicados para o snapshot: a issue do rrweb #1337 mediu a serialização do snapshot completo em 34,55 ms de média em um documento de divs profundamente aninhados, e em 27,35 ms depois de remover buscas repetidas de closest().

O artigo do web.dev do Google sobre long tasks define o limite e a aritmética:

blocking time = task duration - 50 ms

Um snapshot de 34,55 ms contribui, portanto, com 0 ms de blocking time, porque "any task that takes longer than 50 milliseconds is a long task" e nada mais curto conta. Snapshots em árvores do DOM bem maiores cruzam essa linha, e o tracker do rrweb tem os relatos: a issue #1547 diz que uma checagem interna "lags by 1 to 3 seconds on pages with lots of nodes", e a issue #1820 documenta a thread principal travando quando há um widget do Zendesk na página. Nenhum benchmark público mapeia número de nós do DOM para milissegundos de serialização, então trate qualquer número fixo de CPU por página alegado por um fornecedor como não medido.

Gravadores podem empurrar o trabalho não urgente para o requestIdleCallback, mas a especificação do W3C limita cada deadline ociosa "to a maximum value of 50ms" para o navegador manter folga e responder a entradas dentro da janela de 100 ms que parece instantânea. A MDN avisa que sem a opção timeout "it's possible multiple seconds will elapse before the callback is fired", então o agendamento ocioso serve para compressão e upload, não para o snapshot.

Quanta banda um session replay envia por upload?

O benchmark da Sentry mediu o upload de rede do cenário dela subindo de 3,84 KB só com o SDK de erros para 272,51 KB com o replay ligado, enquanto o download ficou estável em 8,09 MB e 8,07 MB. O upload é o custo que o seu servidor e a conexão do seu visitante carregam juntos, e ele escala linearmente com as sessões gravadas:

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

Com os 272,51 KB medidos pela Sentry por cenário gravado e 50.000 sessões por mês, isso dá 13.625.500 KB, ou cerca de 13 GB de upload. Apps com muito texto e DOM de mudança lenta ficam abaixo desse número e apps com muito canvas ou animação ficam acima, e é para isso que existe a receita de armazenamento do rrweb.

O session replay muda as Core Web Vitals?

Na execução publicada pela Sentry, o session replay deixou Largest Contentful Paint e Cumulative Layout Shift em paz e moveu o Total Blocking Time. O benchmark estava "last updated on Sept 25, 2023" e rodou "on an Apple M1 MacBook Pro against a remote preview server and a remote API backend with 50 iterations".

O Total Blocking Time subiu 415,13 ms entre o SDK de erros e a build com replay, e a Sentry observa que uma página de teste mais simples "produced an increase of ~100 ms of total JS blocking time". A estabilidade de layout não se moveu nem um pouco, o que combina com o funcionamento da métrica: a gravação lê o DOM e o Cumulative Layout Shift pontua o movimento dentro dele. Um notebook M1 não é um celular Android intermediário, e ninguém publicou o mesmo benchmark em hardware móvel de entrada, então meça as Core Web Vitals com os seus próprios dados de campo antes de decidir que os números se transferem.

Como cortar o overhead do session replay sem perder a gravação?

A amostragem remove os eventos que mais custam e menos provam. A receita de armazenamento do rrweb recomenda mousemove: false para descartar o movimento do mouse, scroll: 150 para emitir no máximo um evento de scroll a cada 150 ms, media: 800 para interação com mídia, e input: 'last' para gravar apenas o valor final de um campo digitado, com o argumento de que a amostragem "can reduce the storage size by dropping some events". Além da amostragem, o blockClass pula subárvores inteiras, já que "an element with the class name .rr-block will not be recorded, instead it will replay as a placeholder", e o slimDOMOptions tira partes do DOM que não agregam valor à reprodução. Comece por mousemove e scroll na sua página mais pesada, e meça de novo. O mascaramento roda dentro da mesma passagem de serialização, então como você configura o mascaramento muda o custo de CPU tanto quanto a sua postura de privacidade.

Perguntas frequentes

O session replay bloqueia a primeira renderização de uma página?

Não quando o gravador carrega de forma assíncrona, porque um script async não fica no caminho crítico do parser. O que pode cair perto da primeira renderização é o snapshot inicial do DOM, que roda depois que o gravador começa e escala com o número de nós. O benchmark da Sentry mostrou Largest Contentful Paint em 1529,11 ms com o replay ligado contra 1599,19 ms sem SDK nenhum, então o primeiro paint não foi o ponto de pressão naquela execução.

Quanto o script do gravador adiciona ao peso da página?

O Bundlephobia lista o @rrweb/record 2.1.4 em 23.262 bytes gzipped e o bundle rrweb completo em 78.597 bytes gzipped, e a Sentry documenta o plugin Session Replay dela em cerca de 36 KB gzipped em cima do SDK de erros. O script da Flowsery fica abaixo de 10 KB. Confira o tamanho de transferência comprimido no painel de rede do seu navegador, já que números sem compressão exageram o que um visitante baixa.

O session replay aumenta o consumo de dados de um visitante?

Sim, no lado do upload. A Sentry mediu 272,51 KB de upload no cenário de benchmark dela com o replay ligado, contra 3,84 KB só com o SDK de erros, enquanto o volume de download não se mexeu. Visitantes em conexões móveis com franquia pagam esse upload, e esse é o argumento mais forte para tirar o mousemove do fluxo por amostragem.

Por que o session replay custa mais CPU em algumas páginas do que em outras?

O trabalho de serialização é função do número de nós do DOM e da taxa de mutação, não de pageviews. Um dashboard que re-renderiza uma tabela grande a cada tecla digitada produz mais registros de mutação do que um artigo estático, e a issue #1547 do rrweb relata travadas de 1 a 3 segundos "on pages with lots of nodes". Widgets de terceiros somam também, que é o que a issue #1820 documenta para o Zendesk Web Widget.

O session replay prejudica o ranqueamento no SEO?

Só pelo mesmo caminho que qualquer script, movendo as Core Web Vitals. A documentação de busca do Google diz que os sistemas centrais de ranqueamento premiam uma boa experiência de página, e ao mesmo tempo alerta que as Core Web Vitals sozinhas não garantem posições (Google Search Central). Como a medição da Sentry moveu o Total Blocking Time e deixou Largest Contentful Paint e Cumulative Layout Shift estáveis, a métrica para acompanhar é a capacidade de resposta da thread principal.

Como eu meço o overhead do session replay no meu próprio site?

Carregue a sua página mais pesada com o gravador desligado, grave um perfil de performance no Chrome DevTools, depois repita com o gravador ligado e compare tempo de scripting, contagem de long tasks e bytes transferidos. Rode cada configuração várias vezes e compare medianas, porque execuções isoladas variam mais do que o efeito que você está medindo. Dados de campo de aparelhos reais resolvem o que um perfil de laboratório apenas sugere.

Desativar o rastreamento de mousemove economiza tempo de CPU ou só banda?

As duas coisas. A tabela de custos do artigo lista a amostragem entre os controles da CPU da thread principal e entre os do upload, porque cada evento de mousemove descartado é um registro de mutação menos para serializar e um evento menos para enviar. Desativar o mousemove com mousemove: false é a mesma alavanca que a receita de armazenamento do rrweb recomenda primeiro.

O que conta como uma 'long task' que o session replay precisa evitar?

O artigo do web.dev do Google define uma long task como qualquer trabalho que passe de 50 milissegundos na thread principal, com o tempo de bloqueio igual à duração da tarefa menos 50 ms. O benchmark de snapshot completo do rrweb mediu 34.55 ms em um documento de divs profundamente aninhadas, o que fica abaixo desse limite e não gera tempo de bloqueio. Snapshots em árvores DOM muito maiores são os que cruzam esse limite, como mostram os relatos do próprio rastreador de issues do rrweb sobre atrasos de vários segundos.

O requestIdleCallback consegue impedir que o session replay bloqueie a thread principal?

Só para o trabalho que pode esperar. Os gravadores podem empurrar compressão e upload para o requestIdleCallback, mas a especificação do W3C limita cada janela de inatividade a 50 ms, e o MDN avisa que, sem a opção timeout, um callback pode levar vários segundos para disparar. Isso torna o agendamento em tempo ocioso adequado para trabalho em segundo plano, não para o snapshot inicial do DOM, que precisa rodar assim que o gravador começa.

O session replay custa mais em uma CPU lenta ou em uma conexão de rede lenta?

Na execução publicada pela Sentry, a CPU carrega a maior parte do custo. O download ficou estável em 8.09 MB contra 8.07 MB com o replay ativado, enquanto o Total Blocking Time subiu de 2621.67 ms para 3036.80 ms, e a conclusão do artigo é que o custo recai sobre a thread principal, não sobre a rede. O upload, por sua vez, cresceu de 3.84 KB para 272.51 KB, então uma conexão com dados limitados também sente isso, só que menos que uma CPU lenta.