O Web Vitals é uma iniciativa iniciada pelo Google para definir um conjunto comum de sinais de qualidade que podem ajudar a medir as experiências do usuário na web. Um dos objetivos da iniciativa é tornar mais fácil para os proprietários de sites medirem o desempenho do site sem uma vasta experiência em engenharia de desempenho.
A iniciativa Web Vitals consiste em:
- Um conjunto de diretrizes sobre o que e como o desempenho do site e a experiência do usuário devem ser avaliados
- Uma série de métricas, conhecidas como Web vitais, que medem certos eventos e interações que freqüentemente afetam a experiência do usuário
- Um conjunto de ferramentas e bibliotecas que simplificam o processo de medição de vitais da Web
- Um compromisso de divulgar Web Vitals por meio das ferramentas mais populares do Google
Quais são os sinais vitais da web?
Existem atualmente cinco Web vitais que podem ser medidos:
- Mudança cumulativa de layout (CLS)
- Atraso na primeira entrada (FID)
- Pintura de maior conteúdo (LCP)
- Primeira pintura com conteúdo (FCP)
- Tempo para o primeiro byte (TTFB)
CLS, FID e LCP são considerados Core Web Vitals. Um Core Web Vital destina-se a ser aplicado a todas as páginas da web, independentemente de como essas páginas são construídas. É uma meta ambiciosa, considerando os diferentes tipos de páginas da web que existem. Vamos dar uma olhada em como cada Core Web Vital se aplica a aplicativos de página única (SPAs).
Ferramentas disponíveis para monitorar Core Web Vitals
Apesar de sua vida útil relativamente curta, uma variedade de ferramentas e pacotes do Google já podem ser usados para medir os vitais essenciais da Web-e a lista continua crescendo. Aqui estão algumas das ferramentas mais comuns:
- Experiência do usuário do Chrome Relatório : Este relatório pode ser usado para medir Core Web Vitals com base em dados de campo de usuários reais que optaram por permitir que o Chrome colete e compartilhe esses dados
- PageSpeed Insights : Este ferramenta pode ser usada para medir Core Web Vitals usando dados de campo provenientes do Relatório de experiência do usuário do Chrome, bem como dados de laboratório coletados e analisados pelo Google em um ambiente controlado
- Relatório Core Web Vitals no Google Search Console : o Google Search Console fornece um relatório Core Web Vitals para cada uma de suas propriedades da web registradas
- Chrome DevTools : começando com o Chrome 88, a guia DevTools Desempenho inclui uma faixa Web Vitals que exibe algumas das pontuações principais do Web Vitals
- Farol : Farol 6.0 (também disponível no Chrome DevTools) pode gerar relatórios que incluem métricas Web Vitals
- LogRocket : LogRocket correlaciona métricas Web Vitals com impacto nos negócios. Além de monitorar Web Vitals, LogRocket monitora tempos de carregamento de página, uso de CPU/memória, falhas de navegador e renderização do componente React
- web-vitals : esta é uma biblioteca JavaScript que pode ser integrada ao seu aplicativo da web. Inclui um conjunto simples de funções que capturam eventos e dados vitais do Core Web
Adicionando a biblioteca web-vitals a um aplicativo de página única
O pacote npm web-vitals foi adicionado recentemente a alguns scaffolders de aplicativos da web por padrão. Por exemplo, se você tem um aplicativo React feito com uma versão recente de create-react-app , o pacote web-vitals já está incluído em sua solução.
Caso contrário, vá para a página do pacote web-vitals em npm , onde há instruções detalhadas sobre como para instalar e configurar o pacote em seu aplicativo.
Medindo e melhorando as pontuações do Core Web Vitals para SPAs
À medida que examinamos mais de perto cada um dos principais elementos vitais da Web, também usaremos algumas dessas ferramentas em ação. Usaremos o exemplo de SPA de Northern Getaway Backyard Solutions para simular situações que resultam em Web Vitals fracos. O código-fonte do aplicativo de amostra está disponível no GitHub .
O aplicativo de demonstração Northern Getaway Backyard Solutions foi gerado usando create-react-app, portanto, nenhuma configuração de pacote web-vitals adicional foi necessária. Por conveniência, as pontuações do Core Web Vitals são exibidas na parte superior do aplicativo à medida que ficam disponíveis:
Lembre-se de que as pontuações do Web Vitals variam entre os usuários devido a variáveis como velocidade de conexão de rede, tipo de dispositivo, resolução da tela, tamanho da janela do navegador e muito mais. Se estiver acompanhando o aplicativo de demonstração aberto em seu dispositivo, você deve esperar que as pontuações do Web Vitals sejam diferentes, mas os resultados devem ser semelhantes.
Mudança cumulativa de layout (CLS)
O deslocamento cumulativo do layout quantifica a estabilidade visual de uma página da web. Um dos exemplos mais relacionáveis de mudança de layout impactando a experiência do usuário envolve anúncios. A maioria dos usuários se viu lendo conteúdo em uma página da web apenas para ver o texto deslizar para baixo e, às vezes, até fora da tela, conforme os anúncios são carregados e inseridos na página. Esse tipo de experiência do usuário desconfortável é o que o CLS tenta medir.
A API de estabilidade de layout é uma especificação que define como o CLS é medido e o que é considerado uma mudança de layout. De acordo com esta especificação, nem todas as mudanças de layout contam para a pontuação CLS. Por exemplo, as transformações CSS ou a rolagem de uma página pelo usuário não afetam a pontuação CLS.
As pontuações CLS começam em 0. O algoritmo de pontuação CLS original aumentou o CLS conforme os elementos mudavam na janela de visualização até o próximo evento de carregamento da página. Esse algoritmo pode ter levado a pontuações CLS excessivamente altas para páginas de longa duração, como aplicativos de página única. Imagine um aplicativo de página única com roteamento do lado do cliente. Cada mudança de rota exibe um novo conteúdo, que é o comportamento esperado, mas a pontuação CLS aumenta continuamente.
Em resposta, em 7 de abril de 2021, o Google anunciou uma modificação no algoritmo de pontuação CLS para fornecer melhor pontuação para páginas vividas. Com esta modificação, a mudança de layout será agrupada em janelas de 5s (máximo), com um intervalo de 1s entre cada janela. Cada janela de mudança de layout é medida normalmente pela API de estabilidade de layout. No evento de carregamento de página subsequente, a janela com a pontuação CLS mais alta se torna a pontuação CLS da página anterior.
Vamos dar uma olhada em um exemplo de mudança de layout. Navegue até a página Nosso trabalho do aplicativo de demonstração Northern Getaway Backyard Solutions. Quando a página estiver totalmente carregada, recarregue-a para ver a pontuação CLS. Lembre-se de que o CLS só pode ser medido após a ocorrência do próximo evento de carregamento da página. A pontuação CLS que você vê agora reflete a mudança de layout que ocorreu na página anterior.
A página Nosso Trabalho simula o carregamento de imagens de maneira assíncrona em uma conexão lenta com a Internet. As dimensões da imagem não foram especificadas no código. À medida que cada imagem é carregada, as imagens carregadas anteriormente se movem dentro da janela de visualização, o que pode ser classificado como mudança de layout. Lembre-se de que a pontuação CLS varia dependendo de quanto da página está visível na janela de visualização.
A pontuação CLS resultante é de aproximadamente 1,06, o que não é uma boa pontuação. Na verdade, de acordo com a escala de pontuação CLS do Google, qualquer coisa acima de 0,25 é considerada ruim.
Então, como você melhora a pontuação CLS da página Nosso trabalho? A solução é bastante simples neste caso. Se você definir uma largura e altura em cada imagem, o navegador saberá quanto espaço alocar para a imagem. O navegador é capaz de determinar exatamente onde cada imagem aparecerá na tela antes de carregar.
Fontes comuns de mudança de layout
Vimos um único exemplo de mudança de layout no exemplo anterior, mas existem muitas outras fontes de mudança de layout. Aqui estão algumas fontes e soluções comuns.
| Fonte da mudança de layout | Soluções |
|---|---|
| Uma imagem ou vídeo com dimensões desconhecidas |
|
| Uma fonte que fica maior ou menor que a fonte substituta |
|
| Um anúncio ou widget de terceiros que se redimensiona dinamicamente |
|
Pintura de maior conteúdo (LCP)
A pintura com maior conteúdo mede o tempo de carregamento do conteúdo principal de uma página. A ideia é que um usuário perceba a rapidez com que uma página da web carrega pela rapidez com que o conteúdo principal da página se torna visível. Assim que o conteúdo principal estiver visível, o usuário sentirá que a página foi carregada, embora elementos periféricos menores ainda estejam carregando.
O conteúdo principal da página é determinado pela identificação da maior imagem ou bloco de texto visível na janela de visualização do navegador. O bloco pode ser uma imagem, um vídeo, um elemento de bloco contendo texto ou mesmo uma imagem de fundo carregada via CSS.
A API de maior conteúdo do Paint define uma lista completa de elementos permitidos. Esta lista é intencionalmente curta e concisa para manter a métrica simples. A API também especifica como o tamanho de um elemento é calculado, levando em consideração os elementos que são apenas parcialmente visíveis na janela de visualização e nuances semelhantes.
Vamos dar uma olhada em um exemplo de LCP. Navegue até a página inicial do aplicativo de demonstração Northern Getaway Backyard Solutions. Após cerca de 4s, a página deve estar completamente carregada. Toque em qualquer lugar da tela para forçar o navegador a relatar o LCP. Depois dessa primeira interação com a página, não faz mais sentido continuar a rastrear e relatar no LCP, pois as interações subsequentes podem alterar intencionalmente o que é visível na página.
A pontuação do LCP foi de aproximadamente 0,9s. Lembre-se de que as pontuações do LCP variam com base na velocidade da rede e no tamanho da janela de visualização do navegador. Nesse caso, o navegador foi totalmente expandido em uma tela de laptop com resolução de 1920 × 1080.
Algo não está certo! A página inicial é projetada especificamente para carregar o bloco principal de texto após 4s, mas a pontuação LCP é de 0,9 segundos. Superficialmente, parece que o bloco de texto é o maior bloco na tela e, portanto, a pontuação LCP deve ser 4.000 (4s) ou superior. Com base estritamente nas medidas, o bloco de texto principal é certamente maior do que o cabeçalho:
Podemos usar o Lighthouse no Chrome DevTools para ver o que é exibido na tela quando o LCP é relatado. Abra o aplicativo de demonstração e DevTools no Chrome. Siga estas etapas para gerar um relatório Lighthouse com Web Vitals:
- Mude para a guia Farol
- Desative a opção Limitação simulada para que as métricas relatadas pelo Lighthouse sejam comparáveis às métricas exibidas na página
- Selecione a categoria Desempenho
- Clique no botão Gerar relatório
Farol no Chrome DevTools.
Assim que o relatório for gerado, clique no botão Exibir rastreamento .
Role horizontalmente na raia Tempo até localizar o marcador LCP. Expanda a raia Quadros para ver uma captura de tela da página no ponto em que o LCP foi relatado.
Estas capturas de tela antes e depois do marcador LCP sugerem que o bloco de cabeçalho é o que está conduzindo a pontuação LCP. Podemos provar isso atualizando temporariamente o código-fonte do aplicativo para ocultar o cabeçalho e, em seguida, executar novamente o relatório Lighthouse.
A pontuação do LCP agora é de aproximadamente 4,5s, ou aproximadamente a quantidade de tempo que o bloco de texto principal leva para aparecer na tela. Vejamos o código-fonte do bloco de texto principal:
Bem-vindo, morador de quintal!
Seu quintal está uma bagunça?
Você espia por cima da cerca do seu vizinho e pensa'Eu gostaria de ter isso'?
Você está cansado de olhar pela janela dos fundos para o mesmo paraíso de relva?
Você chegou ao lugar certo. Nós aqui da Northern Getaway Backyward Solutions queremos transformar o seu constrangimento causador de vômito de um quintal no refúgio definitivo da era da pandemia.
Trabalharemos com você para desenvolver um plano arquitetônico de mestre para transformar seus sonhos em realidade. Então, começaremos a limpar a teia de cobras e a re vitalizar o espaço do seu quintal.
A melhor parte é que receberemos apenas uma pequena parte de todo o dinheiro que você conseguiu economizar durante a pandemia.
Confira nosso trabalho para ver e acreditar!
Se você se lembra, o LCP é baseado em quanto tempo leva para o maior elemento de nível de bloco ser renderizado na janela de visualização. No código-fonte de amostra, cada um dos elementos de parágrafo são elementos de nível de bloco. O LCP está realmente sendo relatado devido à renderização de um desses elementos de parágrafo, o que for maior. Também é importante observar que a API LCP não inclui preenchimento ou margens em seus cálculos.
Aplicabilidade de LCP a aplicativos de página única
Assim como outros Web Vitals, o LCP só é medido inicialmente quando a página é carregada. Considere um aplicativo de página única com roteamento do lado do cliente e carregamento de conteúdo assíncrono. A primeira rota no aplicativo pode carregar muito rapidamente.
Assim que o usuário interage com a página da web-para navegar para uma rota diferente, por exemplo-a pontuação LCP é relatada. Nesse ponto, o Web Vitals não rastreará o LCP para alterações subsequentes de rota do lado do cliente. Dependendo de como o aplicativo é projetado, o LCP pode oferecer um valor limitado para medir a experiência do usuário.
Consertando pontuações LCP fracas
O exemplo da página inicial simulou conteúdo de carregamento lento. Em um cenário do mundo real, esse conteúdo pode ser proveniente de uma API de back-end que está frequentemente sob carga pesada e incapaz de responder em um período de tempo razoável. Existem muitas soluções possíveis para este cenário, incluindo:
- Aumente a capacidade de sua API para que ela possa lidar com os volumes esperados
- Certifique-se de que a API está retornando respostas com cabeçalhos de cache HTTP apropriados para que as respostas subsequentes possam ser servidas do cache do navegador
- Se o conteúdo retornado da API for relativamente estático, adicione um serviço CDN na frente da API para servir respostas em cache de servidores localizados mais perto de seus usuários
Atraso na primeira entrada (FID)
Atraso na primeira entrada mede a rapidez com que uma página responde à primeira interação de um usuário. Outros Web Vitals tendem a se concentrar na rapidez com que um usuário vê algo na tela, mas essa métrica se concentra na interação inicial com a página e no que o usuário percebe. É ótimo se sua página carrega e renderiza extremamente rápido, mas a experiência do usuário ainda pode ser um usuário insatisfatório, não sendo capaz de começar a interagir imediatamente com a página.
O FID pode ser difícil de entender no início. Ele mede o tempo entre o momento em que um usuário clica pela primeira vez ou toca em uma página até o momento em que o navegador é realmente capaz de começar a manipular o evento resultante-mas não quanto tempo leva para o aplicativo fazer o que deve quando o evento é gerado.
Por exemplo, suponha que a primeira interação de um usuário com uma página da web seja clicar em um botão. O navegador não consegue responder ao evento de clique por 100 ms porque seu thread principal está ocupado executando o JavaScript iniciado no carregamento da página. Quando o navegador consegue responder, o evento de clique leva 200 ms adicionais para ser concluído. O FID relatado seria de 100 ms.
Vamos dar uma olhada em alguns exemplos de pontuações de FID no aplicativo de demonstração Northern Getaway Backyard Solutions. Navegue até a página Obter estimativa . Clique no menu suspenso Tipo de estimativa para forçar o relatório do FID.
The FID score is approximately 1.6ms, which is far lower than the 300ms or higher score that is considered to be poor. This is about as good as it gets. The Get Estimate page doesn’t really have much happening behind the scenes; the user can interact with the form nearly instantaneously after it becomes visible in the browser.
Let’s add the following CPU-intensive event handler to the click event on the Email Address field. Do you think the FID score will be affected?
function doSomethingSlow() { console.time('onClick event handler'); const baseNumber=12; let result=0; for (var i=Math.pow(baseNumber, 7); i >=0; i--) { result +=Math.atan(i) * Math.tan(i); }; console.log(`result was ${result}`); console.timeEnd('onClick event handler'); };
Reload the Get Estimate page. Before clicking on the page, open Chrome DevTools so that the console is visible. Click on the Email Address text box. The browser will lock up for 4–5s while the CPU-intensive function executes. Once the function completes, the FID score will appear at the top of the screen, and the function result will appear in the DevTools console.
This time, the FID score came in at about 1.49ms, even lower than the 1.6ms from the previous example. This demonstrates that FID does not include the time it takes to execute the event handler itself.
Measuring FID
You measure FID scores differently from how you’d measure other Core Web Vitals. LCP and CLS can be measured in a lab environment using a variety of tools but FID can only be measured in the field with real users.
To measure FID at test time, Google recommends that you look at the Total Blocking Time (TBT) Web Vital instead. Although TBT isn’t the same as FID, it does provide some insight into long tasks that block the main thread for more than 50ms prior to the page being ready for users to interact with it. Any of these long tasks could result in a poor FID score in the field.
To measure FID in the field, you need to use tools that are capable of accessing data collected from real users who have interacted with the page. Page Speed Insights can pull data from the Chrome User Experience Report to provide an overall FID score for the page. This assumes there have been enough users accessing the page who have also opted in to provide their data to the Chrome User Experience report.
FID applicability to single-page apps
Just like the other Web Vitals, FID is only measured on the first interaction with the page. FID will not identify poor user experiences on subsequent interactions on the page or interactions on subsequent routes in a single-page app that uses client-side routing.
Not being able to interact with elements on-screen can be extremely frustrating to users, especially since users may not be able to determine whether the lockup is due to the page itself or their browser or system locking up. Depending on your situation, it might make sense to implement custom FID monitoring on all client-side route changes.
Fixing poor FID scores
First Input Delay and main thread blocking can be caused by a number of things. Here are a few examples and potential solutions:
- Complex and/or large amounts of JavaScript downloaded and run on first page load. Consider breaking up your JavaScript, lazy loading components, and generally simplifying your solution if possible. Remember that all JavaScript is parsed, compiled and executed on the main thread
- If your webpage is loading third-party scripts, analyze FID scores and consider whether these scripts may be contributing to poor scores
- Large amounts of data processing and storage in the browser can lead to heavy main thread usage. Consider reducing the amount of data loaded into memory on initial page load and in general
- Consider using a Web Worker to run long tasks on a separate background thread. This can free up capacity so that the main thread can respond more quickly to user interaction events
Core Web Vitals summary
The table below summarizes each of the core web vitals.
| Core Web Vital | Core Web Vital | What is measured? |
|---|---|---|
| Cumulative Layout Shift (CLS) | The visual stability of your webpage determined by the amount of layout shift when the page initially loads |
|
| Largest Contentful Paint (LCP) | The amount of time it takes to load the largest element on screen |
|
| First Input Delay (FID) | The amount of time between when a user interacts with a page for the first time and when the browser is able to respond to that interaction |
|
What’s next for Web Vitals?
There are active discussions between the Google Chrome team and SPA developers regarding the applicability of Core Web Vitals to single-page apps. Some of those discussions have already led to changes, particularly the evolution of CLS. Google has also indicated that the Core Web Vitals are expected to evolve over time. We may see new Web Vitals rise to prominence and add to or replace existing Core Web Vitals.
Support for Web Vitals outside of Google tools continues to grow. A quick search for Web Vitals-related packages on npm yielded 27 results. These search results include packages that integrate with some of the most popular frontend frameworks, including React, Vue.js, Nuxt.js, and Gatsby.
Perhaps the biggest hint that Web Vitals are here to stay is the fact that Google is set to included Web Vital metrics in page experience signals that contribute to how Google search engine results are ranked. Google appears to be all in on Web Vitals; this all but guarantees some longevity to this method of measuring user experience.
The post Google Web Vitals best practices for single-page apps appeared first on LogRocket Blog.
