A pesquisa e a metodologia por trás dos limites das Core Web Vitals
As Core Web Vitals são um conjunto de métricas de campo que avaliam aspectos importantes da experiência real do usuário na Web. As Core Web Vitals incluem métricas e limites de segmentação para cada uma delas, 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 Core Web Vitals em geral, além de como os limites de cada métrica específica foram escolhidos.
Revisão: Métricas e limites das Core Web Vitals
Em 2020, as Core Web Vitals são três métricas: Largest Contentful Paint (LCP), First Input Delay (FID) e Cumulative Layout Shift (CLS). Cada métrica avalia 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 quando o conteúdo principal da página provavelmente foi carregado; a FID mede a capacidade de resposta e quantifica a experiência do usuário ao tentar interagir pela primeira vez com a página; e a CLS mede a estabilidade visual e quantifica a quantidade de mudanças inesperadas de layout do conteúdo da página visível.
Cada métrica das Core Web Vitals tem limites associados, que categorizam o desempenho como "Bom", "Precisa de melhorias" ou "Ruim":
| Bom | Ruim | Percentil | |
|---|---|---|---|
| Maior exibição de conteúdo | ≤ 2.500 ms | >4.000 ms | 75 |
| Latência na primeira entrada | ≤100ms | >300 ms | 75 |
| Cumulative Layout Shift | ≤ 0,1 | >0,25 | 75 |
Além disso, para classificar o desempenho geral de uma página ou um site, usamos o valor do 75o percentil de todas as visualizações de página desse site. Ou seja, se pelo menos 75% das visualizações de página de um site atingirem o limite "bom", o site será classificado como tendo um desempenho "bom" nessa métrica. Por outro lado, se pelo menos 25% das visualizações de página atingirem o limite "insatisfatório", o site será classificado como tendo desempenho "ruim". Por exemplo, uma LCP no 75o percentil de 2 segundos é classificada como "boa", enquanto uma LCP no 75o percentil de 5 segundos é classificada como "ruim".
Critérios para os limites das Core Web Vitals
Ao estabelecer limites para as Core Web Vitals, primeiro identificamos critérios que cada limite precisa ser cumprido. Abaixo, explico os critérios que usamos no Google para avaliar os limites das Core Web Vitals de 2020. As seções subsequentes entrarão em mais detalhes sobre como esses critérios foram aplicados para selecionar os limites de cada métrica em 2020. Nos próximos anos, prevemos fazer melhorias e adições aos critérios e limites para melhorar ainda mais nossa capacidade de medir ótimas experiências do usuário na Web.
Experiência do usuário de alta qualidade
Nosso principal objetivo é otimizar para o usuário e a qualidade de experiência dele. Nosso objetivo é garantir que as páginas que atendam aos limites de "boa" 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, consideramos a percepção humana e a pesquisa de 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 a quantidade de tempo que os usuários normalmente esperam antes de perder o foco é descrita como um segundo, enquanto a pesquisa subjacente é, na verdade, expressa como um intervalo, de centenas de milissegundos a vários segundos. O fato de que os limites de percepção variam dependendo do usuário e do contexto é apoiado ainda mais por dados de métricas agregados e anônimos do Chrome, o que mostra que não há um tempo único que os usuários aguardam o conteúdo de uma página da Web antes de cancelar o carregamento. Em vez disso, esses dados mostram uma distribuição suave e contínua. Para uma visão mais aprofundada sobre os limites de percepção humana e pesquisas relevantes sobre HCI, consulte A ciência por trás das Web vitals (em inglês).
Nos casos em que pesquisas relevantes de experiência do usuário estão disponíveis 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 limites. Nos casos em que pesquisas relevantes de experiência do usuário não estão disponíveis (por exemplo, para uma nova métrica, como Mudança de layout cumulativa), avaliamos páginas reais que atendem a diferentes limites candidatos a uma métrica para identificar um limite que resulta em uma boa experiência do usuário.
Alcançável por conteúdo da Web existente
Além disso, para garantir que os proprietários consigam otimizar os sites e atender aos limites "bom", exigimos que esses limites sejam alcançáveis para o conteúdo na Web. Por exemplo, mesmo que zero milissegundos seja um limite "bom" de LCP, resultando em experiências de carregamento instantâneo, um limite de zero milissegundo não é praticamente alcançável na maioria dos casos devido a latências de processamento de rede e dispositivo. Portanto, zero milissegundos não é um limite razoável de LCP para Core Web Vitals.
Ao avaliar os limites "bom" das Core Web Vitals, verificamos se esses limites são alcançáveis com base nos dados do Chrome User Experience Relatório (CrUX, na sigla em inglês). Para confirmar se um limite é alcançável, exigimos que pelo menos 10% das origens atendam ao limite "bom". Além disso, para garantir que sites otimizados não sejam classificados incorretamente devido à variabilidade nos dados de campo, também verificamos se o conteúdo otimizado consistentemente atende ao limite "bom".
Por outro lado, estabelecemos o limite "insatisfatório" identificando um nível de desempenho que somente uma minoria de origens não está atingindo atualmente. A menos que haja pesquisas relevantes para definir um limite "ruim", por padrão, 10 a 30% das origens com pior desempenho são classificadas como "ruim".
Considerações finais sobre critérios
Ao avaliar os limites do candidato, descobrimos que, às vezes, os critérios entravam em conflito. Por exemplo, pode haver uma tensão entre um limite ser alcançável consistentemente e garantir uma experiência do usuário consistentemente boa. Além disso, como a pesquisa de percepção humana normalmente fornece uma variedade de valores e as métricas de comportamento do usuário mostram mudanças graduais no comportamento, descobrimos que muitas vezes não há um limite "correto" único para uma métrica. Portanto, nossa abordagem para as Core Web Vitals de 2020 tem sido escolher limites que melhor atendam aos critérios acima, reconhecendo que não há um limite perfeito e que, às vezes, precisamos escolher entre vários requisitos razoáveis. Em vez de perguntar "qual é o limite perfeito?", nós nos concentramos em perguntar "qual limite de candidato atende melhor nossos critérios?".
Escolha do percentil
Conforme observado anteriormente, para classificar o desempenho geral de uma página ou um 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, o percentil precisa garantir que a maioria das visitas a uma página ou um site tenha o nível desejado de desempenho. Segundo, o valor no percentil escolhido não deve ser excessivamente impactado por outliers.
Esses objetivos estão, de alguma forma, conflitantes. Para satisfazer a primeira meta, um percentil mais alto é normalmente uma escolha melhor. No entanto, com percentis mais altos, a probabilidade do valor resultante ser afetado por outliers também aumenta. Se algumas visitas a um site estiverem em conexões de rede instáveis que resultam em amostras de LCP excessivamente grandes, não queremos que nossa classificação de sites seja decidida por essas amostras discrepantes. Por exemplo, se estivéssemos avaliando o desempenho de um site com 100 visitas usando um percentil alto, como o 95o, precisaria de apenas 5 amostras de outliers para o valor de percentil do 95o ser afetado pelos outliers.
Como essas metas estão um pouco em risco, após a análise, concluímos que o 75o percentil atinge um equilíbrio razoável. Ao usar o 75o percentil, sabemos que a maioria dos acessos ao site (3 de 4) teve o nível desejado de desempenho 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 dessas visitas precisariam informar amostras de outliers maiores para que o valor no 75o percentil seja afetado por outliers. Embora 25 de 100 amostras sejam discrepantes, é muito menos provável do que no caso do 95o percentil.
Maior exibição de conteúdo
Qualidade de experiência
Um segundo costuma ser citado como a quantidade de tempo que um usuário espera antes de começar a perder o foco em uma tarefa. Em uma inspeção mais detalhada da pesquisa relevante, descobrimos que um segundo é uma aproximação para descrever um intervalo de valores, de aproximadamente várias centenas de milissegundos a vários segundos.
Duas fontes citadas com frequência para o limite de um segundo são Card et al e Miller. O card define um limite de "resposta imediata" de um segundo, citando as Teorias unificadas da cognição de Newell. Newell explica as respostas imediatas como "respostas que precisam ser feitas a algum estímulo em muito aproximadamente um segundo (ou seja, aproximadamente de 0,3 a 3 segundos)." Isso segue a discussão de Newell sobre "restrições em tempo real da cognição". Observa-se 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 comumente citada para o limite de um segundo, observa que as "tarefas que os humanos podem e vão executar 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 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 Primeira exibição de conteúdo é de 1 segundo e que a Maior exibição de conteúdo normalmente ocorre após a primeira exibição de conteúdo, restringimos ainda mais nosso intervalo de limites de LCP candidatos, de 1 a 3 segundos. Para escolher o limite nesse intervalo que melhor atende aos nossos critérios, analisamos a capacidade de alcance desses limites candidatos abaixo.
Viabilidade
Usando dados do CrUX, podemos determinar a porcentagem de origens na Web que atendem aos nossos limites "bons" de LCP candidatos.
Percentual de origens do CrUX classificadas como "boas" (para possíveis limites de LCP)
| 1 segundo | 1,5 segundos | 2 segundos | 2,5 segundos | 3 segundos | |
|---|---|---|---|---|---|
| phone | 3,5% | 13% | 27% | 42% | 55% |
| computador | 6,9% | 19% | 36% | 51% | 64% |
Embora menos de 10% das origens atendam ao limite de 1 segundo, todos os outros limites de 1,5 a 3 segundos atendem ao nosso requisito de que pelo menos 10% das origens atendam ao limite "bom" e, portanto, ainda sejam candidatos válidos.
Além disso, para garantir que o limite escolhido seja alcançável consistentemente para sites bem otimizados, analisamos o desempenho da LCP em sites com melhor desempenho em toda a Web para determinar quais limites são consistentemente alcançáveis para esses sites. Especificamente, nosso objetivo é identificar um limite que possa ser atingido consistentemente no 75o percentil para sites com melhor desempenho. Concluímos que os limites de 1,5 e 2 segundos não são alcançáveis de forma consistente, enquanto os 2,5 segundos podem ser atingidos de maneira consistente.
Para identificar um limite "insatisfatório" para a LCP, usamos dados do CrUX para identificar um limite atendido pela maioria das origens:
Percentual de origens do CrUX classificadas como "ruim" (para candidatos a limites de LCP)
| 3 segundos | 3,5 segundos | 4 segundos | 4,5 segundos | 5 segundos | |
|---|---|---|---|---|---|
| phone | 45% | 35% | 26% | 20% | 15% |
| computador | 36% | 26% | 19% | 14% | 10% |
Para um limite de quatro segundos, aproximadamente 26% das origens de smartphones e 21% das origens de computadores seriam classificados como ruins. Isso está dentro da nossa meta de 10% a 30%, então, concluímos que quatro 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.
Latência na primeira entrada
Qualidade de experiência
A pesquisa é razoavelmente consistente em concluir que atrasos no feedback visual de 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" de 100 ms de latência na primeira entrada provavelmente é apropriado como uma barra mínima: se o atraso para processamento de entrada for maior que 100 ms, não haverá chance de outras etapas de processamento e renderização serem concluídas a tempo.
O Tempo de resposta: os três limites importantes (link em inglês) de Jakob Nielsen define 0,1 segundo como o limite para fazer com que o usuário sinta que o sistema está reagindo instantaneamente. A Nielsen cita Miller e Card, que cita The Perception of Causality (link em inglês) de Michotte, de 1962. Na pesquisa de Michotte, os participantes do experimento veem "dois objetos em uma tela. O objeto A é solto 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 para e o momento em que o Objeto B começa a se mover. Michotte descobre que, para atrasos de até 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, e para atrasos acima de 200 ms, o movimento do Objeto B não é mais visto como causado pelo Objeto A.
Da mesma forma, Miller define um limite de resposta para "Resposta à ativação de controle" como "a indicação de ação dada, normalmente, pelo movimento de uma chave, um interruptor ou outro membro de controle que sinaliza que foi fisicamente ativado. Essa resposta precisa ser percebida como parte da ação mecânica induzida pelo operador. Atraso: não mais que 0,1 segundo. Depois, o tempo entre o pressionamento de 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 investigaram a percepção de simultaneidade entre o toque de um botão virtual em uma tela touchscreen e o feedback visual subsequente indicando que ele foi tocado, durante 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 apareceu simultaneamente com o pressionamento do botão 75% do tempo. Além disso, para atrasos de 100 ms ou menos, os participantes relataram uma qualidade percebida alta consistentemente ao pressionar o botão, com a qualidade percebida caindo para atrasos de 100 ms a 150 ms e atingindo níveis muito baixos para atrasos de 300 ms.
Com isso em mente, concluímos que a pesquisa aponta para um intervalo de valores de cerca de 100 ms como um limite adequado de latência na primeira entrada para Web Vitals. Além disso, considerando que os usuários relataram níveis baixos de qualidade para atrasos de 300 ms ou mais, 300 ms apresentam um limite "ruim" razoável.
Viabilidade
Usando dados do CrUX, determinamos que a maioria das origens na Web atende ao limite "bom" de 100 ms da FID no 75o percentil:
Percentual de origens do CrUX classificadas como "boas" para o limite de 100 ms de FID
| 100 ms | |
|---|---|
| phone | 78% |
| computador | >99% |
Além disso, observamos que os principais sites da Web conseguem atingir consistentemente esse limite no 75o percentil e, geralmente, no 95o percentil.
Considerando o que foi dito acima, concluímos que 100 ms é um limite "bom" razoável para FID.
Cumulative Layout Shift
Qualidade de experiência
A Mudança de layout cumulativa (CLS) é uma nova métrica que mede quanto o conteúdo visível de uma página muda. Como o CLS é novo, não temos conhecimento de pesquisas que possam informar diretamente os limites para essa métrica. Assim, para identificar um limite alinhado às expectativas do usuário, avaliamos páginas reais com diferentes quantidades de mudança de layout para determinar a quantidade máxima de mudanças percebidas como aceitável antes de causar interrupções significativas no consumidor do conteúdo. No teste interno, descobrimos que os níveis de mudança de 0,15 e acima foram percebidos consistentemente como disruptivos, enquanto as mudanças de 0,1 e abaixo foram perceptíveis, mas não excessivamente perturbadoras. Embora nenhuma mudança de layout seja o ideal, concluímos que valores de até 0, 1 são possíveis limites de CLS "bom".
Viabilidade
Com base nos dados do CrUX, quase 50% das origens têm CLS de 0,05 ou menor.
Percentual de origens do CrUX classificadas como "boas" (para possíveis limites de CLS)
| 0,05 | 0,1 | 0,15 | |
|---|---|---|---|
| phone | 49% | 60% | 69% |
| computador | 42% | 59% | 69% |
Embora os dados do CrUX sugiram que 0,05 possa ser um limite "bom" de CLS, reconhecemos que há alguns casos de uso em que é atualmente difícil evitar mudanças de layout disruptivas. Por exemplo, para conteúdo incorporado de terceiros, como incorporações de mídias sociais, a altura do conteúdo às vezes não é conhecida até ele terminar de carregar, o que pode levar a uma mudança de layout maior que 0,05. Assim, embora muitas origens atinjam o limite de 0,05, o limite um pouco menos rigoroso de CLS de 0,1 estabelece um melhor equilíbrio entre qualidade de experiência e viabilidade. Esperamos que, daqui em diante, o ecossistema da Web identifique soluções para lidar com mudanças de layout causadas por incorporações de terceiros, o que permitiria o uso de um limite "bom" de CLS mais rigoroso de 0,05 ou 0 em uma iteração futura das Core Web Vitals.
Além disso, para determinar um limite "ruim" para CLS, usamos os dados do CrUX para identificar um limite atingido pela maioria das origens:
Percentual de origens do CrUX classificadas como "ruim" (para possíveis limites de CLS)
| 0,15 | 0,2 | 0,25 | 0,3 | |
|---|---|---|---|---|
| phone | 31% | 25% | 20% | 18% |
| computador | 31% | 23% | 18% | 16% |
Para um limite de 0,25, aproximadamente 20% das origens de smartphones e 18% das origens de computadores seriam classificadas como "ruim". Isso está dentro da nossa meta de 10% a 30%. Portanto, concluímos que 0,25 é um limite "ruim" aceitável.