Monitorização de utilizadores reais: compreender a velocidade dos sites em condições reais e em laboratório

Utilizadores reais e testes em laboratório

Monitorização de Utilizadores Reais O (RUM) regista o funcionamento de um site durante visitas reais. Uma visita efetuada num smartphone mais antigo através de rede móvel pode diferir significativamente de uma visita num computador com uma ligação rápida. As páginas visitadas e as interações também são tidas em conta na análise.

A Teste de laboratório Por outro lado, analisa uma chamada definida em condições controladas. O tipo de dispositivo, as condições de rede e o procedimento de teste podem ser definidos para uma análise. Isto facilita a reprodução de uma anomalia e a verificação de possíveis alterações em condições comparáveis.

Estas duas perspetivas respondem a questões diferentes: os dados de campo podem revelar que as páginas de produtos em dispositivos móveis costumam carregar lentamente. No entanto, não comprovam se, por exemplo, a imagem do produto, o percurso de renderização ou uma resposta lenta do documento são os responsáveis por isso. Para identificar a causa, são necessários diagnósticos adicionais e hipóteses verificáveis.

O PageSpeed Insights combina ambas as perspetivas: compara os dados de campo disponíveis com os resultados dos diagnósticos do Chrome User Experience Report Lab, com base no Lighthouse. Os resultados podem não coincidir, uma vez que as visitas reais envolvem condições e fluxos de utilização diferentes, enquanto o laboratório analisa um caso de teste definido.

Por isso, o RUM não substitui o Labor. Por outro lado, um único teste de laboratório não consegue revelar com que frequência um problema ocorre junto dos visitantes reais. Além disso, antes de uma publicação ou no caso de um site com poucas visitas, podem faltar dados de campo suficientes; sem visitas reais, não se obtêm, de todo, valores de medição próprios do RUM.

É assim que se obtêm os valores medidos pelo RUM

Uma medição própria requer três componentes: um registo no navegador, um recetor para os valores transmitidos e uma análise. Em primeiro lugar, deve definir quais as páginas e os grupos de visitantes que pretende analisar e como os dados serão protegidos. Só a partir de valores individuais agrupados de forma sensata é que se cria uma base para a tomada de decisões.

Para tal, os navegadores disponibilizam várias interfaces de desempenho. Tempo de navegação descreve os momentos relacionados com a navegação até ao documento, como, por exemplo, a resposta ao pedido do documento. O Resource Timing fornece informações temporais sobre recursos individuais carregados, como imagens ou scripts. Desta forma, é possível identificar com maior precisão as diferentes fases de um processo de carregamento.

A PerformanceObserver monitoriza os registos de desempenho suportados assim que estes ficam disponíveis. No que diz respeito aos Core Web Vitals, a biblioteca pode web-vitals encarregar do cálculo e da comunicação. As entradas e os indicadores disponíveis dependem, entre outros fatores, do navegador; por isso, um script de medição não regista automaticamente todas as visitas na íntegra.

Nem todos os valores são gerados diretamente durante o carregamento. No caso do INP, por exemplo, é necessário que ocorra uma interação adequada: quem apenas lê uma página e a abandona pode não gerar qualquer valor. Um valor de medição em falta não é, portanto, nem zero nem uma prova de uma resposta rápida.

Um serviço RUM pode disponibilizar a recolha, a receção e a análise num único pacote. No caso de um desenvolvimento próprio, terás de organizar adicionalmente a operação, o armazenamento e a garantia de qualidade. Isso inclui também tratar corretamente as notificações repetidas ao longo do ciclo de vida da página, em vez de contar cada notificação como uma visita independente, sem a verificar.

Como interpretar corretamente os Core Web Vitals

O Principais dados vitais da Web descrevem três aspetos diferentes da experiência do utilizador. O Largest Contentful Paint (LCP) mede o momento em que o maior elemento de conteúdo relevante fica visível. Numa página de produto, isso pode ser, por exemplo, uma imagem grande do produto: se esta aparecer tarde, a página pode dar a impressão de ainda não estar totalmente carregada, apesar de a navegação já estar visível.

O Interaction to Next Paint (INP) analisa o atraso entre as interações e a próxima atualização visível. Se um filtro de produto só reagir de forma percetível após um clique, o INP pode indicar este problema. Por outro lado, o Cumulative Layout Shift (CLS) descreve deslocamentos inesperados de conteúdos visíveis, por exemplo, quando um elemento exibido posteriormente desloca um botão.

Para a avaliação no PageSpeed Insights, considera-se bom um LCP até 2,5 segundos, inclusive, um INP até 200 milissegundos, inclusive, e um CLS até 0,1, inclusive. O CLS é um valor sem unidades. Os limiares aplicam-se ao respetivo indicador e não devem ser confundidos com a duração de uma única visita à página.

O fator decisivo para a avaliação do campo é o Percentil 75 (p. 75): Pelo menos cerca de 75 por cento das experiências consideradas não excedem o valor em questão. Por outro lado, uma boa média, por si só, pode ocultar o facto de uma parte considerável das visitas ser lenta. Analise os dispositivos móveis e os computadores de secretária separadamente, para que as diferenças entre os grupos de dispositivos continuem visíveis.

O «Time to First Byte» (TTFB) complementa estes indicadores na análise de uma resposta lenta a um documento. No entanto, este valor não corresponde apenas ao tempo de processamento do servidor: a rede e outras etapas até à chegada do primeiro byte de resposta também influenciam o resultado. O «Navigation Timing» e, se disponíveis, os dados de «Server Timing» ajudam a analisar com maior precisão as etapas envolvidas.

CrUX, RUM próprio e laboratório

Para começar, não é necessário que operes logo o teu próprio sistema de medição. O PageSpeed Insights combina dados de campo provenientes do Relatório sobre a Experiência do Utilizador do Chrome (CrUX) com um diagnóstico de laboratório do Lighthouse. As duas perspetivas respondem a questões diferentes: uma descreve as experiências registadas, enquanto a outra analisa uma página em condições controladas.

Os dados de campo do CrUX no PageSpeed Insights referem-se a um período retroativo de 28 dias. Se os dados relativos a um URL específico forem insuficientes, o relatório pode apresentar, em vez disso, dados da origem. Estes incluem a origem do site em questão e não devem ser equiparados à experiência exata na página introduzida. Por isso, preste atenção ao nível que o relatório efetivamente apresenta.

O CrUX tem em conta apenas os utilizadores do Chrome que cumprem os respetivos requisitos; outros navegadores e utilizadores não elegíveis não são incluídos. Num site pequeno ou não público, os dados do CrUX podem não estar disponíveis. No entanto, uma recolha própria, adequada do ponto de vista jurídico e técnico, pode proporcionar informações úteis nesses casos, embora, com poucas visitas, os resultados sejam estatisticamente limitados.

A monitorização sintética repete testes previamente definidos, mesmo quando ninguém está a visitar o site. É adequada para observar regularmente um fluxo de trabalho em condições semelhantes. Para saber se os utilizadores têm a mesma experiência com outros dispositivos ou redes, é necessário realizar uma medição no terreno; um único fluxo sintético não substitui essa perspetiva.

Para a escolha, o que importa, portanto, é a questão a que pretendes responder: um relatório público está rapidamente disponível, enquanto um sistema próprio permite um registo mais específico. Um serviço pode aliviar a carga de trabalho operacional, ao passo que os ensaios laboratoriais e sintéticos permitem análises controladas. No entanto, mesmo um serviço requer uma seleção consciente de dados e grupos de análise.

Preparar com segurança a medição própria

Comece por definir uma questão concreta, por exemplo, se as páginas de produtos para dispositivos móveis apresentam, com maior frequência, um LCP elevado do que outros tipos de páginas. Em seguida, determine quais as páginas e classes de dispositivos que pretende distinguir, quais as métricas necessárias para o efeito e durante quanto tempo pretende recolher dados. Só depois é que deve decidir sobre o script de medição, o destinatário e a análise.

Como primeiro passo técnico, podes utilizar a biblioteca web-vitals Incorporar localmente num projeto de navegador e visualizar o resultado nas ferramentas de desenvolvimento. O código JavaScript seguinte utiliza a versão 6.2.3 do pacote publicada. Pressupõe que esta versão esteja instalada no projeto e que a compilação processe as importações de módulos. O exemplo não envia dados para um servidor nem ativa uma medição separada das navegações virtuais.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

A saída da consola é uma forma de verificar a integração, não uma prova da velocidade dos teus visitantes. Abre a página do projeto e interage, por exemplo, com um filtro. Um valor de INP pressupõe uma interação adequada e pode não aparecer imediatamente; sem uma interação adequada, pode nem sequer aparecer. A compatibilidade do navegador e o ciclo de vida da página também influenciam a saída.

Planeia, para uma análise posterior, o Ciclo de vida da página Nota: podem ocorrer múltiplas notificações, por exemplo, quando uma página é ocultada e posteriormente voltada a ser apresentada. Não considere estas notificações, de forma generalizada, como visitas independentes. A biblioteca disponibiliza IDs de métricas que permitem atribuir as notificações à mesma métrica.

A recuperação a partir da cache «Back/Forward» também requer um tratamento específico. Pode desencadear uma nova notificação de métrica, apesar de o documento ser recuperado da cache. Defina como irá distinguir essas recuperações das navegações habituais no seu relatório e consulte as orientações específicas da biblioteca antes de configurar um registo em ambiente de produção.

Analisar os valores medidos por segmento

Um valor global para a loja pode ocultar o facto de que, precisamente, as páginas de produtos para dispositivos móveis são mais lentas. Por isso, divide os dados de medição, pelo menos, por tipo de página e classe de dispositivo e analisa cada métrica num período de tempo definido. Desta forma, podes, por exemplo, comparar páginas de produtos para dispositivos móveis com páginas de categorias para dispositivos móveis, em vez de misturar inadvertidamente diferentes situações de utilização.

Para cada segmento, isso é Percentil 75 mais significativo do que uma simples média: indica o valor que, pelo menos, cerca de 75 por cento das experiências consideradas não ultrapassam. Por outro lado, uma média baixa pode ocultar o facto de um grupo relevante estar a esperar há muito tempo. Compare o p75 apenas para a mesma métrica e com a unidade adequada.

O número de valores válidos faz parte integrante do resultado. Se um segmento for composto apenas por poucas medições, os resultados individuais podem influenciar significativamente o percentil; uma variação não tem, necessariamente, de indicar um problema geral. Se necessário, opta por um período de tempo mais longo ou agrupa páginas com temas semelhantes, sem comprometer a comparabilidade.

A ausência de um INP não equivale a um INP rápido e não deve ser considerada como zero na distribuição. Em vez disso, indique separadamente o número de valores de INP válidos. Se muitas visitas não fornecerem uma interação adequada, a análise do INP descreve apenas as experiências de interação registadas e não, automaticamente, todas as visitas à página.

Agrupa adequadamente as mensagens repetidas com base no ID da métrica, em vez de tratar cada resposta como uma nova observação independente. Além disso, documente como são contabilizadas as recuperações a partir da cache «back/forward». Desta forma, fica claro quais as observações que estão efetivamente incluídas no p75 e no número indicado.

Do problema no terreno ao diagnóstico

Se os dados de campo indicarem que as páginas de produtos apresentam lentidão nos dispositivos móveis, delimita, em primeiro lugar, o segmento afetado: o LCP deficiente afeta muitos produtos ou apenas um tipo de página? Verifica, ao mesmo tempo, o período e o número de valores válidos. Desta forma, obténs um ponto de partida para a análise, mas ainda não tens provas de qual o elemento que está a causar o atraso.

Em seguida, insira no Teste de laboratório Recrie condições o mais semelhantes possível, por exemplo, com uma configuração de dispositivo móvel e velocidade de rede limitada. Analisa qual o elemento que surge como LCP e quando é carregado e apresentado. Uma imagem grande do produto, um pedido de imagem tardio ou um percurso de renderização bloqueado são hipóteses possíveis que deve verificar com base no diagnóstico.

Se houver indícios de que estão a ser enviadas imagens, podes analisar o tamanho dos ficheiros, os formatos e a forma de disponibilização. Um Rede de distribuição de conteúdos é uma medida possível, mas não constitui garantia de um melhor LCP. Se, pelo contrário, a resposta do documento indicar um gargalo, uma medida complementar ajuda a Teste de desempenho de servidores para cargas de trabalho em PHP, analisar a aplicação em condições definidas.

No caso de um filtro de produto com atraso, a interação é determinante, em vez do processo de carregamento. Reproduz o clique no filtro e verifica o trabalho necessário até à atualização visível. Nos navegadores que suportam essa funcionalidade, é possível Fotogramas de animação longos Fornecem indicações sobre atualizações de renderização demoradas e os scripts envolvidos; não explicam automaticamente todas as interações lentas.

Aplique uma alteração específica e, em seguida, observe novamente o mesmo grupo de páginas no ambiente real. Um resultado melhor em laboratório reflete, numa primeira fase, apenas o efeito nas condições de teste selecionadas. Só a avaliação posterior no ambiente real poderá revelar se as experiências registadas dos visitantes reais também se alteraram.

Qualidade dos dados e proteção de dados na empresa

Antes da implementação em produção, define quais os valores de medição necessários para a tua análise e quem os irá processar. O planeamento deve incluir uma transmissão segura para o destinatário, restrições de acesso, um período de conservação limitado e um procedimento de eliminação. Analisa as questões relativas à proteção de dados e ao consentimento para a implementação concreta e as regras aplicáveis de forma específica, em vez de assumir uma autorização genérica.

Com o Minimização de dados Vale a pena dar uma olhadela aos campos de diagnóstico: as URLs completas podem conter informações sensíveis nos parâmetros de consulta; os seletores DOM também podem revelar detalhes sobre o conteúdo das páginas ou os dados introduzidos. Sempre que possível, registe um tipo geral de página e alguns atributos selecionados de forma específica. Verifique também quais os dados que um serviço integrado recolhe ou armazena adicionalmente.

Os valores medidos nem sempre estão disponíveis de imediato. A biblioteca web-vitals pode emitir respostas várias vezes ao longo do ciclo de vida da página; por isso, uma notificação posterior não deve ser considerada automaticamente como uma nova visita independente. Planeie como as notificações relacionadas serão processadas e como serão tratadas as recuperações a partir da cache «Back/Forward».

No caso de pequenos pacotes de diagnóstico, a transmissão pode ser efetuada através de sendBeacon no evento visibilitychange ser adequado. Isso melhora a possibilidade de enviar dados ao ocultar uma página, mas não garante a entrega. Além disso, o destinatário tem de aceitar os dados de forma segura e processá-los de modo a que as mensagens repetidas não distorçam a análise sem que se perceba.

Por fim, tem em conta a Lacunas no registo: Scripts bloqueados, falta de compatibilidade do navegador ou transmissões perdidas podem fazer com que determinadas visitas não sejam registadas. Avalie uma taxa de perda estimada, juntamente com o tipo de recolha de dados. Os valores medidos restantes descrevem o grupo observado e podem não representar todos os visitantes de forma igual.

Analisar as alterações e escolher o procedimento

Para efetuar uma comparação após uma implementação, define previamente quais os tipos de páginas, classes de dispositivos e períodos a considerar. Compara, para cada métrica, o percentil 75 e o número de valores válidos antes e depois da alteração. Intervalos de tempo de duração semelhante ajudam na contextualização; no entanto, isso não garante automaticamente a obtenção de amostras suficientemente comparáveis.

Esteja atento a uma alteração na composição do tráfego de visitantes. Se, após uma implementação, houver mais utilizadores com ligações móveis lentas, o valor global pode piorar, embora a alteração em si não seja mais lenta. A utilização sazonal ou outras alterações simultâneas também dificultam a atribuição. Uma correlação temporal é, portanto, uma hipótese, não um Prova de causalidade.

O CrUX e o RUM próprio não têm de apresentar os mesmos resultados: podem abranger grupos de utilizadores, intervalos de tempo e condições de recolha diferentes. No caso do CLS, acrescenta-se o facto de o CrUX também ter em conta as contribuições de frames incorporados para a experiência da página principal. Uma medição em JavaScript no documento principal nem sempre regista estas contribuições na íntegra. Por isso, compara primeiro as bases de medição antes de considerares um desvio como um erro.

No caso de uma aplicação de página única, deve definir se pretende analisar a navegação entre documentos ou as mudanças de rota internas. Para o registo separado de Navegação suave A partir da versão 6, o Web Vitals suporta a opção, desde que o navegador a suporte, reportSoftNavs: true. Deve ser definida nos respetivos callbacks de métricas. O exemplo anterior da consola, sem esta opção, não ativa uma medição de percurso separada.

Quando a recolha de dados da navegação soft está ativada, o CLS e o INP são reiniciados para a nova navegação e considerados separadamente; os valores da navegação anterior são concluídos aquando da mudança de percurso. Não se deve comparar esses valores, cujos períodos de tempo são diferentes, com medições relativas a todo o documento sem os verificar previamente. Sem o suporte adequado do navegador, esta opção não resulta numa medição separada da rota.

Ao escolher um serviço RUM, além da cobertura de navegadores, verifica se os grupos de páginas e as classes de dispositivos necessários podem ser analisados. Informa-te sobre os métodos de amostragem, o tratamento de dados, a conservação e as possibilidades de exportação. Igualmente importante é saber que impacto o próprio script de medição pode ter na página e se a sua recolha de dados pode ser limitada ao necessário para a tua análise.