Como os limites das Core Web Vitals foram definidos

A pesquisa e a metodologia por trás dos limites das Core Web Vitals

Bryan McQuade

Barry Pollard

Publicado em 21 de maio de 2020

As Core Web Vitals são um conjunto de métricas de campo que medem aspectos importantes da experiência do usuário na Web. As Core Web Vitals incluem métricas e limites de destino para cada métrica, que ajudam os desenvolvedores a entender qualitativamente se a experiência do site é "boa", "precisa de melhorias" ou é "ruim". Esta postagem explica a abordagem usada para escolher os limites das métricas Core Web Vitals em geral, além de como os limites de cada métrica específica das Core Web Vitals foram escolhidos.

Revisão: métricas e limites das Core Web Vitals

As Core Web Vitals são três métricas: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Cada métrica mede um aspecto diferente da experiência do usuário: a LCP mede a velocidade de carregamento percebida e marca o ponto na linha do tempo de carregamento da página em que o conteúdo principal da página provavelmente foi carregado. O INP mede a capacidade de resposta e quantifica a experiência dos usuários ao tentar interagir com a página. Já a CLS mede a estabilidade visual e quantifica a quantidade de mudança de layout inesperada do conteúdo visível da página.

Cada métrica das Core Web Vitals tem limites associados, que categorizam a performance como "boa", "precisa de melhorias" ou "ruim":

Além disso, para classificar a performance geral de uma página ou site, usamos o valor da 75ª percentil de todas as visualizações de página para essa página ou site. Em outras palavras, se pelo menos 75% das visualizações de página de um site atenderem ao limite "bom", o site será classificado como tendo performance "boa" para essa métrica. Por outro lado, se pelo menos 25% das visualizações de página atenderem ao limite "ruim", o site será classificado como tendo performance "ruim". Assim, por exemplo, uma LCP de 75o percentil de 2 segundos é classificada como "boa", enquanto uma LCP de 5 segundos é classificada como "Ruim".

Critérios para os limites das métricas do Core Web Vitals

Nesta seção, analisaremos os critérios para avaliar os limites das Core Web Vitals. As seções a seguir vão explicar em mais detalhes como esses critérios foram aplicados para selecionar os limites de cada métrica. Nos próximos anos, esperamos fazer melhorias e adições aos critérios e limites para aprimorar ainda mais nossa capacidade de avaliar ótimas experiências do usuário na Web.

Experiência do usuário de alta qualidade

Nosso principal objetivo é otimizar o site para o usuário e a qualidade da experiência dele. Por isso, nosso objetivo é garantir que as páginas que atendam aos limites "bons" das Core Web Vitals ofereçam uma experiência do usuário de alta qualidade.

Para identificar um limite associado a uma experiência do usuário de alta qualidade, buscamos pesquisas de percepção humana e HCI. Embora essa pesquisa às vezes seja resumida usando um único limite fixo, descobrimos que a pesquisa subjacente é normalmente expressa como um intervalo de valores. Por exemplo, a pesquisa sobre o tempo que os usuários normalmente esperam antes de perder o foco às vezes é descrita como 1 segundo, enquanto a pesquisa subjacente é expressa como um intervalo, de centenas de milissegundos a vários segundos. O fato de os limites de percepção variarem de acordo com o usuário e o contexto é confirmado pelos dados de métricas agregadas e anônimas do Chrome, que mostram que não há um único tempo de espera para que uma página da Web exiba conteúdo antes de abortar o carregamento da página. Em vez disso, esses dados mostram uma distribuição suave e contínua. Para uma visão mais aprofundada dos limites de percepção humana e pesquisas relevantes de HCI, consulte A ciência por trás das vitais da Web (em inglês).

Nos casos em que uma pesquisa relevante sobre a experiência do usuário está disponível para uma determinada métrica e há um consenso razoável sobre o intervalo de valores na literatura, usamos esse intervalo como uma entrada para orientar nosso processo de seleção de limite. Nos casos em que a pesquisa relevante sobre a experiência do usuário não está disponível, por exemplo, para uma nova métrica como a Cumulative Layout Shift, avaliamos páginas reais que atendem a diferentes limites candidatos a uma métrica para identificar um limite que resulte em uma boa experiência do usuário.

Alcançável com o conteúdo da Web atual

Além disso, para garantir que os proprietários de sites consigam otimizar os sites para atender aos limites "bons", exigimos que esses limites sejam alcançáveis para o conteúdo existente na Web. Por exemplo, embora zero milissegundos seja um limite "bom" de LCP ideal, resultando em experiências de carregamento instantâneo, um limite de zero milissegundos não é viável na maioria dos casos devido a latências de processamento de rede e dispositivo. Portanto, zero milissegundos não é um limite "bom" razoável de LCP para as Core Web Vitals.

Ao avaliar os limites "bons" das Core Web Vitals, verificamos se esses limites são alcançáveis com base nos dados do Chrome User Experience Report (CrUX, na sigla em inglês). Para confirmar que um limite é alcançável, exigimos que pelo menos 10% das origens atendam ao limite "bom". Além disso, para garantir que sites bem otimizados não sejam classificados incorretamente devido à variabilidade nos dados de campo, também verificamos se o conteúdo bem otimizado atende consistentemente ao limite "bom".

Por outro lado, estabelecemos o limite "ruim" identificando um nível de performance que apenas uma minoria de origens não está atingindo. A menos que haja pesquisas relevantes para definir um limite "ruim", por padrão, os 10 a 30% de origens com o pior desempenho são classificados como "ruins".

Se os critérios são iguais ou diferentes por dispositivo

O uso de dispositivos móveis e computadores geralmente tem características muito diferentes em relação aos recursos do dispositivo e à confiabilidade da rede. Isso afeta muito os critérios de "atingibilidade" e sugere que devemos considerar limites separados para cada um.

No entanto, as expectativas dos usuários de uma experiência boa ou ruim não dependem do dispositivo, mesmo que os critérios de viabilidade sejam. Por esse motivo, os limites recomendados das Core Web Vitals não são separados por dispositivo, e o mesmo limite é usado para ambos. Isso também tem a vantagem de simplificar o entendimento dos limites.

Além disso, os dispositivos nem sempre se encaixam bem em uma categoria. Isso deve ser baseado no formato do dispositivo, na capacidade de processamento ou nas condições de rede? Ter os mesmos limites tem o benefício adicional de evitar essa complexidade.

A natureza mais restrita dos dispositivos móveis significa que a maioria dos limites é definida com base na achievability para dispositivos móveis. É mais provável que eles representem limites para dispositivos móveis, em vez de um limite conjunto real em todos os tipos de dispositivos. No entanto, como os dispositivos móveis costumam gerar a maior parte do tráfego da maioria dos sites, isso não é uma preocupação.

Considerações finais sobre os critérios

Ao avaliar os limites de candidatos, descobrimos que os critérios às vezes entravam em conflito. Por exemplo, pode haver uma tensão entre um limite que pode ser alcançado de forma consistente e garantir uma boa experiência do usuário. Além disso, considerando que a pesquisa de percepção humana normalmente oferece uma variedade de valores, e as métricas de comportamento do usuário mostram mudanças graduais no comportamento, descobrimos que geralmente não há um único limite "correto" para uma métrica. Assim, nossa abordagem para as Core Web Vitals tem sido escolher limites que melhor atendem aos critérios, reconhecendo que não há um limite perfeito e que às vezes podemos precisar escolher entre vários limites de candidatos razoáveis. Em vez de perguntar "Qual é o limite perfeito?", nos concentramos em perguntar "Qual limite de candidato melhor atinge nossos critérios?"

Escolha do percentil

Conforme observado anteriormente, para classificar o desempenho geral de uma página ou site, usamos o valor do 75o percentil de todas as visitas a essa página ou site. O 75o percentil foi escolhido com base em dois critérios. Primeiro, a porcentagem precisa garantir que a maioria das visitas a uma página ou site tenha o nível de desempenho alvo. Em segundo lugar, o valor na percentil escolhida não pode ser muito impactado por valores discrepantes.

Essas metas são um pouco conflitantes. Para atender à primeira meta, uma percentila mais alta geralmente é a melhor escolha. No entanto, com percentis mais altos, a probabilidade de o valor resultante ser afetado por valores atípicos também aumenta. Se algumas visitas a um site estiverem em conexões de rede instáveis, o que resulta em amostras de LCP excessivamente grandes, não queremos que nossa classificação de site seja decidida por essas amostras atípicas. Por exemplo, se estivéssemos avaliando o desempenho de um site com 100 visitas usando um percentil alto, como o 95o, seriam necessárias apenas cinco amostras de valores fora do padrão para que o valor do percentil 95 fosse afetado pelos valores fora do padrão.

Como essas metas são um pouco conflitantes, após a análise, concluímos que a 75ª percentila atinge um equilíbrio razoável. Ao usar o percentil 75, sabemos que a maioria das visitas ao site (3 de 4) teve o nível de desempenho desejado ou melhor. Além disso, o valor do 75o percentil tem menos probabilidade de ser afetado por outliers. Voltando ao nosso exemplo, para um site com 100 visitas, 25 delas precisariam informar grandes amostras de outliers, para que o valor no 75o percentil fosse afetado pelos outliers. Embora 25 de 100 amostras sejam valores discrepantes, isso é muito menos provável do que no caso do percentil 95.

Maior exibição de conteúdo

Os limites de LCP foram definidos com as seguintes considerações de qualidade da experiência e viabilidade.

Qualidade da experiência

Um segundo é frequentemente citado como o tempo que um usuário espera antes de começar a perder o foco em uma tarefa. Em uma inspeção mais detalhada de pesquisas relevantes, descobrimos que 1 segundo é uma aproximação para descrever uma faixa de valores, de aproximadamente várias centenas de milissegundos a vários segundos.

Duas fontes comumente citadas para o limite de 1 segundo são Card e outros e Miller. O card define um limite de "resposta imediata" de 1 segundo, citando as teorias unificadas de cognição de Newell. Newell explica as respostas imediatas como "respostas que precisam ser feitas a algum estímulo em aproximadamente um segundo (ou seja, aproximadamente de 0,3 a 3 segundos)." Isso segue a discussão de Newell sobre "restrições de tempo real na cognição", em que é observado que "as interações com o ambiente que evocam considerações cognitivas ocorrem na ordem de segundos", que variam de aproximadamente 0,5 a 2 a 3 segundos. Miller, outra fonte citada com frequência para o limite de um segundo, observa "as tarefas que os humanos podem e vão realizar com comunicações de máquina mudarão seriamente seu caráter se os atrasos de resposta forem maiores do que dois segundos, com alguma possível extensão de mais ou menos um segundo".

A pesquisa de Miller e Card descreve o tempo que um usuário espera antes de perder o foco como um intervalo, de aproximadamente 0,3 a 3 segundos, o que sugere que nosso limite "bom" de LCP precisa estar nesse intervalo. Além disso, considerando que o limite "bom" da First Contentful Paint é de 1 segundo e que a Maior exibição de conteúdo normalmente ocorre após a First Contentful Paint, restringimos a faixa de limites de LCP de 1 a 3 segundos. Para escolher o limite nesse intervalo que melhor atenda aos nossos critérios, vamos analisar a viabilidade desses limites candidatos a seguir.

Alcançabilidade

Usando dados do CrUX, podemos determinar a porcentagem de origens na Web que atendem aos limites "bons" de LCP.

Embora menos de 10% das origens atendam ao limite de um segundo, todos os outros limites de 1,5 a 3 segundos atendem ao requisito de que pelo menos 10% das origens atendam ao limite "bom" e, portanto, sejam candidatas válidas.

Além disso, para garantir que o limite escolhido seja alcançável de maneira consistente em sites bem otimizados, analisamos o desempenho da LCP em sites com melhor desempenho em toda a Web para determinar quais limites são alcançáveis de maneira consistente nesses sites. Especificamente, nosso objetivo é identificar um limite que possa ser alcançado de forma consistente no percentil 75 para os sites com melhor desempenho. Descobrimos que os limites de 1,5 e 2 segundos não são alcançados de forma consistente, enquanto 2,5 segundos é consistente.

Para identificar um limite "ruim" para o LCP, usamos dados do CrUX para identificar um limite atingido pela maioria das origens:

Para um limite de 4 segundos, cerca de 26% das origens de smartphones e 21% das origens de computadores seriam classificadas como ruins. Esse valor está dentro do intervalo desejado de 10 a 30%, portanto, concluímos que 4 segundos é um limite "ruim" aceitável.

Portanto, concluímos que 2,5 segundos é um limite "bom" razoável, e 4 segundos é um limite "ruim" razoável para a maior exibição de conteúdo.

Interaction to Next Paint

Os limites de INP foram definidos com as seguintes considerações de qualidade da experiência e viabilidade.

Qualidade de experiência

A pesquisa é razoavelmente consistente em concluir que atrasos no feedback visual de até cerca de 100 ms são percebidos como causados por uma fonte associada, como uma entrada do usuário. Isso sugere que um limite "bom" ideal de interação com a próxima pintura estaria próximo a isso.

O artigo de Jakob Nielsen, Response Times: The 3 Important Limits, define 0,1 segundo como o limite para que o usuário sinta que o sistema reage instantaneamente. Nielsen cita Miller e Card, que citam A percepção da causalidade de Michotte. Na pesquisa de Michotte, os participantes do experimento são mostrados "dois objetos em uma tela. O objeto A é disparado e se move em direção a B. Ele para no momento em que entra em contato com B, enquanto o último começa e se afasta de A." Michotte varia o intervalo de tempo entre o momento em que o objeto A é interrompido e o objeto B começa a se mover. Michotte descobre que, para atrasos de até cerca de 100 ms, os participantes têm a impressão de que o Objeto A causa o movimento do Objeto B. Para atrasos de aproximadamente 100 ms a 200 ms, a percepção de causalidade é mista. Em atrasos acima de 200 ms, o movimento do Objeto B não é mais visto como sendo causado pelo Objeto A.

Da mesma forma, Miller define um limite de resposta para "Resposta para controlar a ativação" como "a indicação de ação dada, normalmente, pelo movimento de uma chave, interruptor ou outro membro de controle que sinaliza que foi ativada fisicamente. Essa resposta precisa ser percebida como parte da ação mecânica induzida pelo operador. Tempo de espera: não mais que 0,1 segundo" e mais tarde "o tempo de espera entre pressionar uma tecla e o feedback visual não pode ser maior que 0,1 a 0,2 segundos".

Mais recentemente, em Towards the Temporally Perfect Virtual Button, Kaaresoja e outros pesquisadores investigaram a percepção de simultaneidade entre tocar em um botão virtual em uma tela touchscreen e o feedback visual subsequente indicando que o botão foi tocado, para vários atrasos. Quando o atraso entre o pressionamento do botão e o feedback visual era de 85 ms ou menos, os participantes relataram que o feedback visual aparecia simultaneamente ao pressionamento do botão 75% das vezes. Além disso, para atrasos de 100 ms ou menos, os participantes relataram uma qualidade percebida consistentemente alta do botão pressionado, com a qualidade percebida diminuindo para atrasos de 100 ms a 150 ms e atingindo níveis muito baixos para atrasos de 300 ms.

Portanto, concluímos que a pesquisa aponta 100 ms como um "bom" limite de interação com a próxima pintura para as Core Web Vitals. Além disso, considerando que os usuários relataram níveis de qualidade baixos para atrasos de 300 ms ou mais, o ideal seria que esse fosse o limite "ruim".

Alcançabilidade

Usando dados do CrUX, determinamos que a maioria das origens na Web atende ao limite "bom" de 200 ms de INP na 75ª percentil:

Também dedicamos ainda mais atenção à possibilidade de transmitir INP para dispositivos móveis de última geração, onde eles formaram uma alta proporção de visitas a sites. Isso confirmou a adequação de um limite de 200 ms.

Considerando o limite de 100 ms, que é apoiado por pesquisas sobre a qualidade da experiência e os critérios de achievability, concluímos que 200 ms é um limite razoável para boas experiências.

Para identificar um limite "ruim" para a LCP, usamos dados do CrUX a fim de identificar um limite atingido pela maioria das origens:

Isso sugere que podemos ter um limite "insatisfatório" de 300 ms.

No entanto, ao contrário do LCP e do CLS, o INP tem uma correlação inversa com a popularidade. Os sites mais populares costumam ser mais complexos, o que aumenta a probabilidade de um INP maior. Quando analisamos os 10.000 principais sites, que formam a grande maioria da navegação na Internet, vemos uma imagem mais complexa:

Em dispositivos móveis, um limite "ruim" de 300 ms classificaria a maioria dos sites populares como "ruim", aumentando nossos critérios de viabilidade, enquanto 500 ms seria melhor na faixa de 10 a 30% dos sites. O limite "bom" de 200 ms também é mais difícil para esses sites, mas 23% deles ainda o atendem em dispositivos móveis, o que ainda atende aos nossos critérios mínimos de 10%.

Por esse motivo, concluímos que 200 ms é um limite "bom" razoável para a maioria dos sites, e mais de 500 ms é um limite "ruim" razoável.

Cumulative Layout Shift

Os limites de CLS foram definidos de acordo com as considerações de viabilidade e qualidade de experiência a seguir.

Qualidade da experiência

O Cumulative Layout Shift (CLS) é uma nova métrica que mede o quanto o conteúdo visível de uma página muda de posição. Como o CLS é novo, não temos conhecimento de pesquisas que possam informar diretamente os limites dessa métrica. Portanto, para identificar um limite alinhado às expectativas dos usuários, avaliamos páginas reais com diferentes quantidades de mudança de layout para determinar a quantidade máxima de mudança que é percebida como aceitável antes de causar interrupções significativas ao consumir o conteúdo da página. Em nossos testes internos, descobrimos que os níveis de mudança de 0,15 e mais altos eram consistentemente percebidos como perturbadores, enquanto as mudanças de 0,1 e menores eram perceptíveis, mas não excessivamente perturbadoras. Assim, embora a mudança de layout zero seja ideal, concluímos que valores de até 0,1 são candidatos "bons" limites de CLS.

Viabilidade

Com base nos dados do CrUX, podemos ver que quase 50% das origens têm CLS de 0,05 ou menor.

Embora os dados do CrUX sugiram que 0,05 pode ser um limite "bom" de CLS, reconhecemos que há alguns casos de uso em que é difícil evitar mudanças de layout disruptivas. Por exemplo, no caso de conteúdo incorporado de terceiros, como incorporações de mídias sociais, a altura do conteúdo incorporado às vezes não é conhecida até que o carregamento seja concluído, o que pode levar a uma mudança de layout maior que 0,05. Portanto, concluímos que, embora muitas origens atendam ao limite de 0,05, o limite de CLS um pouco menos rigoroso de 0,1 atinge um melhor equilíbrio entre a qualidade da experiência e a capacidade de realização. Esperamos que, no futuro, o ecossistema da Web identifique soluções para resolver mudanças de layout causadas por incorporações de terceiros, o que permitiria usar um limite de CLS "bom" mais rígido de 0,05 ou 0 em uma iteração futura dos Core Web Vitals.

Além disso, para determinar um limite "ruim" para o CLS, usamos dados do CrUX para identificar um limite atendido pela maioria das origens:

Para um limite de 0,25, cerca de 20% das origens de smartphone e 18% de origens de computador seriam classificadas como "ruim". Esse valor está dentro do intervalo desejado de 10 a 30%. Portanto, concluímos que 0,25 é um limite "ruim" aceitável.