Core Web Vitals

O que são os Core Web Vitals?

Os Core Web Vitals são três métricas que a Google utiliza para medir o desempenho do seu website ou loja online. São eles:

• Velocidade da página
• Interatividade
• Estabilidade visual

Velocidade da página - LCP

Largest Contentful Paint (LCP) é a primeira métrica do Core Web Vitals. Esta métrica é utilizada para medir a velocidade da página. Resumindo: quanto tempo demora até que a maior imagem ou bloco de texto, visível acima da dobra, fique totalmente visível.

Interatividade - FID

O First Input Delay (FID), a segunda métrica do Core Web Vitals, é o atraso entre a primeira interação dos visitantes e o momento em que a página web responde efetivamente. Pressionar um botão para abrir o menu de navegação, por exemplo.

Estabilidade visual - CLS

O Cumulative Layout Shift (CLS), a terceira métrica do Core Web Vitals, é uma soma de todas as alterações que acontecem numa página web. Já viu um anúncio aparecer de repente, empurrando tudo para baixo, pouco antes de querer clicar em algo? Não está sozinho.

Não são apenas os anúncios que o causam. Imagens que ocupam espaço após o carregamento, excertos de texto cuja fonte personalizada carrega repentinamente - fazendo com que os caracteres ocupem menos ou mais espaço, ficheiros CSS que são aplicados demasiado tarde e tendo de redesenhar toda a página web. o layout mude, o que não é bom para a pontuação CLS do Core Web Vitals.

Perceções sobre os seus Core Web Vitals

Explicaremos brevemente como pode obter insights sobre o progresso da otimização do seu website ou loja online para o Core Web Vitals. Como o problema não se resolve sozinho com testes repetidos, gostaríamos de nos concentrar em soluções.

Ao utilizar o PageSpeed ​​​​Insights, obterá insights sobre as três métricas do Core Web Vitals. Irá reparar que a segunda métrica, Atraso da Primeira Entrada, está em falta nos dados do laboratório. Isto porque esta métrica tem origem em dados do mundo real (de utilizadores que optaram por partilhar dados com o Google para melhorar a sua experiência).

Pode reconhecer as métricas do Core Web Vitals pela faixa azul atrás do nome da métrica. A sua pontuação para cada métrica está dividida em três intervalos, cada um com a sua própria cor e formato (para pessoas com daltonismo):

• Triângulo vermelho - Mau
  • LCP > 4s
  • FID > 300ms
  • CLS > 0,25
• Quadrado laranja - Moderado
  • LCP <= 4s
  • FID <= 300ms
  • CLS <= 0,25
• Círculo verde - Bom
  • LCP < 2,5s
  • FID < 100ms
  • CLS < 0,1

Fruta fácil de colher para o Core Web Vitals

Devido a potenciais novatos na otimização do Core Web Vitals, decidimos começar com soluções mais fáceis de implementar. Já leu artigos sobre otimização para o Core Web Vitals antes? Se sim, leia este capítulo para ver se ainda existe alguma oportunidade fácil para si e, em seguida, desça/deslize para baixo até às soluções exclusivas que estamos a disponibilizar neste artigo para o ajudar com a otimização do seu Core Web Vitals.

Imagens de carregamento lento e frames em linha

Se estiver a utilizar o WordPress e manteve o sistema atualizado, o WordPress já ativou o carregamento lento para si. Está a usar um sistema diferente? Bem, então pode activar o carregamento lento para imagens adicionando HTML loading="lazy" todas as tags <img> e <iframe>. Este é um atributo introduzido em 2019 para que o carregamento lento aconteça pelos navegadores da web, em vez de utilizar JavaScript. Neste momento (Maio de 2021), o chamado carregamento lento nativo é suportado pelos browsers modernos.

Imagens WebP para um download mais rápido

O WebP é uma codificação para imagens, o que as torna 39% menos pesadas (em média) do que as imagens JPEG e 45% menos pesadas do que as imagens PNG. As páginas Web com muitas imagens pesadas não atenderão aos Core Web Vitals se os visitantes tiverem uma velocidade de download mais baixa.

Está a usar o WordPress? Se sim, pode utilizar o WebP Express. Para utilizar este plugin, instale-o, ative-o, vá ao backend do WordPress, coloque o rato em Settings e clique em WebP Express. Em seguida, desça até à secção chamada Alter HTML.

Copie as definições apresentadas na Figura 1 referentes à secção Alter HTML.

Se tiver copiado estas definições, o plugin mostrará imagens WebP em vez de imagens JPEG e PNG. Se um navegador Web não suportar imagens WebP, apresenta imagens JPEG ou PNG. Também pode optar por marcar a caixa Replace image URLS, uma vez que todos os navegadores modernos suportam WebP.

O Microsoft Internet Explorer não suporta imagens WebP, mas felizmente já quase ninguém utiliza este browser. Se o seu público-alvo utilizar o Internet Explorer, sugiro copiar as definições da Figura 1 e marcar a caixa Dynamically load picturefill.js on older browsers, uma vez que a etiqueta <picture> não é suportada pelo IE.

Pode converter todas as imagens premindo o botão Bulk Convert.

Otimizar imagens é um ótimo passo na direção certa para otimizar o seu Core Web Vitals.

Minimizando ficheiros JavaScript

Embora isto apenas reduza o tamanho dos ficheiros JavaScript, muitos sites podem beneficiar disto. Os utilizadores com uma ligação de internet mais lenta não terão de esperar tanto. Passo a passo, chegará mais perto de cumprir os padrões do Core Web Vitals. São necessárias muitas otimizações, mas nenhuma delas é decisiva por si só.

Caso ainda não utilize um plugin do WordPress para otimizar a velocidade da página, sugiro que utilize um plugin chamado LiteSpeed ​​Cache. Depois de instalar o LiteSpeed ​​Cache, vá para o backend do WordPress, coloque o rato em LiteSpeed ​​Cache no menu lateral e clique em Page Optimization. Agora clique no separador [2] JS Settings e ative o JS Minify. Clique agora no botão azul Save Changes. Verifique se tudo ainda funciona!

Combinando ficheiros JavaScript

Como discutido acima, pode utilizar o plugin LiteSpeed ​​Cache do WordPress para realizar todos os tipos de otimizações. Vá para o backend do WordPress, coloque o rato em LiteSpeed ​​Cache e clique em Page Optimization. Mais uma vez, clique no separador [2] JS Settings e marque a caixa JS Combine. Clique agora no botão azul Dave Changes. Mais uma vez, verifique se tudo ainda funciona! Não é de todo aceitável que a funcionalidade do seu website ou loja online necessite de ser limitada para cumprir os padrões do Core Web Vitals.

Empurrando ficheiros JavaScript

Ao utilizar o plugin LiteSpeed ​​​​Cache, através da Page Optimization clica no separador [2] JS Settings e de seguida ativa a opção JS HTTP/2 Push. Só pode utilizar esta função se o seu site utilizar HTTPS com um certificado SSL válido.

Embora o HTTPS não esteja relacionado com o Core Web Vitals, é essencial para conseguir classificação nos resultados de pesquisa de uma loja online.

Minimizando os ficheiros CSS

A mesma história é válida para a minimização de ficheiros CSS. No backend do WordPress, clique em Page Optimization e ative a opção Minify CSS. Guarde novamente as alterações e verifique se tudo funciona e parece bom. No final da otimização do Core Web Vitals, a intenção é que tudo continue a funcionar bem. Na verdade, deve funcionar ainda melhor e mais rapidamente!

Combinando ficheiros CSS

Na mesma página, ative a opção CSS Combine, guarde as alterações e verifique se tudo parece bem e ainda funciona.

Empurrando ficheiros CSS

Na mesma página, ative a opção CSS HTTP/2 Push. Isto só funcionará se o seu site ou loja online utilizar HTTPS e tiver um certificado SSL válido. Guarde as alterações. Verifique se, após ativar esta opção, esta beneficia a velocidade da sua página.

Minimizando o HTML

Quando utilizar o plugin LiteSpeed ​​Cache do WordPress, em Page Optimization, clique no separador [3] Optimization e de seguida ative a opção HTML Minify. Guarde as alterações e verifique se o design do seu website está bom e se há algum erro de JavaScript que não estava lá antes de minimizar o HTML.

Soluções únicas

Para ser capaz de cumprir os Core Web Vitals, por vezes precisa de um pouco mais do que todas as frutas mais fáceis que se repetem em cada publicação de blog. É necessária a ajuda de alguém com experiência na criação de sites e lojas online, mas essa pessoa também deve saber como otimizar a velocidade da página e a experiência do utilizador em sites e lojas online.

Reduzindo a quantidade de solicitações

Antes que os ficheiros possam ser descarregados, o seu dispositivo precisa de enviar um pedido ao servidor do site que armazena o ficheiro. O tempo que um dispositivo demora a começar a descarregar um ficheiro armazenado num servidor é chamado de Time To First Byte (TTFB). Imagine que são necessários 50 milissegundos para um único pedido e que um dispositivo precisa de descarregar 45 ficheiros para completar uma página web. Na prática, um dispositivo envia vários pedidos ao mesmo tempo, o que faz com que isto demore menos tempo. De qualquer forma, isto tem uma influência significativa no tempo de carregamento da página e, portanto, uma influência direta sobre se o seu website ou loja online irá ou não cumprir os Core Web Vitals.

Imagine que um dispositivo solicita um ficheiro CSS a um servidor para colorir os caracteres de uma página web, definindo os tamanhos de letra, a altura da linha e assim por diante. Demora 50 milissegundos para que o seu dispositivo receba uma resposta e possa começar a descarregar o ficheiro.

Agora, são necessários mais 50 milissegundos para descarregar o ficheiro. Nada de terrível aconteceu ainda. Até que o seu dispositivo perceba que o ficheiro CSS quer alterar a fonte da página web, para a qual necessita de dois ficheiros de fonte, um para texto em negrito e outro para texto normal.

Isto é ineficiente, porque o dispositivo tem agora de fazer um pedido para cada um destes dois ficheiros de fonte. Teria sido mais eficiente se estes dois ficheiros de fonte já estivessem dentro do ficheiro CSS, porque agora, após 100 milissegundos, o dispositivo percebe que tem de esperar mais 100 milissegundos para estes dois pedidos juntos. Estes pedidos poderiam ter sido feitos com antecedência, de modo que o navegador poderia ter esperado pelos dois ficheiros de fonte juntamente com o ficheiro CSS ao mesmo tempo. Isto levaria metade do tempo gasto com esta forma ineficiente de solicitar recursos.

O download de ficheiros antecipadamente é chamado de preloading. Isto é algo que abordaremos mais à frente neste artigo, pois é uma técnica que por vezes é necessária para evitar alterações de layout em alguns casos. As alterações de layout geram uma pontuação CLS elevada, que é a terceira métrica do Core Web Vitals.

URI de dados para pequenos favicons

Um favicon é uma versão em miniatura do seu logótipo que é utilizada nos separadores do seu navegador. Veja a Figura 2. Estes favicons também são visíveis nos resultados de pesquisa do Google para dispositivos móveis. Como os favicons têm geralmente apenas 1 KB de tamanho, é mais eficiente colocar o conteúdo do ficheiro diretamente no documento HTML. Desta forma, o seu dispositivo não precisa de enviar um pedido separado para um ficheiro de 1 KB. Se um ficheiro for muito maior, digamos 200 KB, é recomendável deixá-lo como um pedido separado. Isto ocorre porque os ficheiros descarregados através de pedidos podem ser armazenados em cache pelo seu navegador da web. Desta forma, não é necessário descarregar o ficheiro para um pedido que o seu dispositivo já tenha feito antes, caso abra uma página diferente no mesmo site.

O favicon é fácil de passar despercebido, pois é apenas um pequeno ícone. Não importa quão pequeno seja um ficheiro, será ainda necessária outra solicitação para que seja possível descarregá-lo. A intenção é diminuir a quantidade de pedidos necessários para o carregamento das suas páginas web. Cada pedido adicional que consiga reduzir, por mais pequeno que seja o ficheiro, é um passo mais perto de cumprir os padrões do Core Web Vitals.

No nosso site utilizamos um URI de dados para o favicon 32x32, uma vez que este tamanho é o mais utilizado juntamente com os favicons. Os favicons de maiores dimensões são tratados através de um pedido separado, uma vez que não são utilizados com tanta frequência e são geralmente mais pesados em tamanho de ficheiro.

Pode gerar um URI de dados para o seu favicon mais pequeno utilizando o Conversor de URI de imagem para dados. Veja a Figura 3 para um exemplo de como um URI de dados pode ser utilizado para um favicon.

URI de dados para fontes woff2

Voltando ao exemplo do ficheiro CSS que fez com que fossem feitos dois pedidos separados para ficheiros fonte. É possível inserir o ficheiro de fonte completo no ficheiro CSS, para que o dispositivo não tenha de enviar dois pedidos separados para os mesmos.

No entanto, é recomendado que o faça apenas para ficheiros de fontes que tem a certeza que serão utilizados, pois o tamanho do ficheiro CSS aumentará porque os ficheiros de fontes estão literalmente dentro dele. No nosso site, utilizamos ícones que estão dentro de um ficheiro de fonte. O ficheiro de fonte era muito pequeno e era solicitado por um ficheiro CSS, por isso decidimos colocar o ficheiro de fonte dentro do ficheiro CSS para reduzir os pedidos. Ver Figura 4.

Pode gerar um URI de dados para ficheiros woff2 utilizando o data:URI Generator. Certifique-se de que seleciona a opção Explicitly specify mime type e, em seguida, digite font/woff2 no campo Enter Mime Type. Ver Figura 5.

Clique agora no botão Generate Data URI e copie-o (CTRL + C). Agora pode substituir o URL do ficheiro woff2 pelo URI de dados que acabou de copiar, selecionando-o e colando-o (CTRL + V).

Certifique-se de que substitui o URL correto - procure o URL antes de format('woff2') e entre url(' e ').

Descodificação assíncrona de imagens

Quando uma imagem é descarregada, ainda não pode ser apresentada. Primeiro, precisa de ser convertido em pixéis para ser desenhado no ecrã. Converter ficheiros de imagem em pixéis é o que chamamos de descodificação de imagens. Converter pixels num ficheiro de imagem é chamado de codificação.

O tempo que demora a descodificar uma imagem depende do tamanho do ficheiro, da potência da CPU, da quantidade de RAM do dispositivo e da codificação da imagem (JPEG, PNG, WebpP, AVIF). Para dar uma ideia de quanto tempo demora: num PC relativamente rápido, demora 24 milissegundos a descodificar uma imagem JPEG que pesa 119 KB (dimensões: 2480x1651). Isto levaria mais tempo em dispositivos móveis com CPU mais lento e menos RAM. Nestes dispositivos, isto pode demorar 100 milissegundos ou mais. O tamanho de uma imagem não afeta apenas o tempo de download, mas também o tempo que o browser demora a apresentá-la no ecrã.

Por predefinição, a descodificação de imagens bloqueará o processo de desenho de outro conteúdo numa página web, mas é possível descodificar imagens de forma assíncrona utilizando um atributo HTML chamado decoding.

O valor predefinido para este atributo é auto. Neste caso, o browser decidirá por si próprio qual a melhor estratégia para descodificar a imagem. O valor sync indica ao navegador web para desenhar a imagem de forma sincronizada com o outro conteúdo da página web. A utilização do valor async dar-lhe-á a capacidade de descodificar a imagem de forma assíncrona, para não bloquear o processo de desenho do resto.

A Wikipédia não quer que a descodificação das imagens atrase a apresentação do restante conteúdo nas suas páginas web. É por isso que optaram por descodificar as imagens de forma assíncrona, para dar prioridade ao conteúdo textual. Ver Figura 6.

Desativando o polyfills JavaScript

Os polyfills JavaScript oferecem funcionalidades que não são oferecidas por browsers desatualizados, como o Microsoft Internet Explorer. A razão pela qual pode considerar desativar o polyfills é favorecer a velocidade do seu website para que este esteja mais próximo de cumprir os padrões Core Web Vitals. A diferença na velocidade da página pode parecer pequena, mas se somar todas as otimizações, terá um grande impacto.

Globalmente, o Internet Explorer tem uma quota de mercado de apenas 0,81% (em fevereiro de 2021). Depois pode optar por desativar o polyfill, para que o seu público-alvo não utilize o Internet Explorer. O Internet Explorer pode ainda ser utilizado pela geração mais antiga, porque alguns idosos podem não saber o que é um navegador web, ou não saber que o seu navegador está desatualizado, ou não saber como instalar navegadores modernos, como o Google Chrome, Microsoft Edge e Mozilla Firefox.

Basicamente, o que pode fazer é sacrificar alguma compatibilidade entre browsers para oferecer uma melhor experiência nos browsers modernos. Manter-se atualizado com todas as novas funcionalidades que a web moderna tem para oferecer é uma parte importante da otimização do Core Web Vitals e da velocidade da página em geral, porque existem codificações mais eficientes para imagens, vídeos e tipos de letra.

Por acaso usa o WordPress? Se sim, pode considerar desativar o polyfill do Babel. Antes de o fazer, no entanto, deve verificar se o seu site ou loja online tem este polyfill ativado. Se estiver a utilizar um plugin do WordPress para otimizar a velocidade da página, considere desativá-lo temporariamente para evitar que os ficheiros sejam combinados e renomeados.

Abra uma página no seu site ou loja online, prima F12 (Mac: Command + Option + I), depois prima CTRL + F, escreva wp-polyfill-js e prima Enter. Se nada for encontrado, provavelmente o seu site não tem este polyfill activado.

Se o seu site utilizar este polyfill, pode desativá-lo adicionando o seguinte código ao seu child theme no ficheiro chamado functions.php:

function tw_remove_wp_polyfill() {
  wp_deregister_script('wp-polyfill');
}
add_action('wp_enqueue_scripts', 'tw_remove_wp_polyfill');

Se não tiver um child theme, pode gerar um utilizando este plugin: Child Theme Generator. Recomendamos que crie um backup do seu site WordPress (base de dados e ficheiros) antes de ativar o child theme, uma vez que já tivemos a experiência de um tema guardar as opções do tema incorretamente ao utilizar um child theme.

Não tem acesso ao FTP para o seu site WordPress, mas Appearance dentro do menu lateral no backend do WordPress contém um link chamado Theme Editor? Depois pode clicar nesse link. Em seguida, mude para o tema filho utilizando a caixa de selecção na parte superior da barra lateral direita). De seguida, clique em Theme Functions (functions.php) na barra lateral direita. Agora copie e cole o código acima no final do ficheiro. Agora pressione o botão azul Update File.

Se tiver acesso ao FTP, pode encontrar o ficheiro abrindo a pasta chamada wp-content (depois de abrir a pasta raiz do WordPress, que se chama public_html ou www ou simplesmente o nome do seu site), abra a pasta themes e depois abra a pasta que tem -child anexado ao nome do tema que o seu site utiliza actualmente. Copie e cole o código acima no final do ficheiro chamado functions.php e guarde-o.

Não deixe de verificar se tudo funciona! Abra algumas páginas, prima F12 (Mac: Command + Option + I) em cada uma delas, clique no separador Console e verifique se existem erros de JavaScript. Há algum erro? Se sim, certifique-se de verificar se estes erros são causados ​​pela desativação do polyfill (remova o código que adicionou no ficheiro functions.php). Se os erros foram causados ​​pela remoção do polyfill, mantenha o polyfill.

Caso tenha desativado um plugin que servia para a otimização da velocidade da página, certifique-se de que o ativa novamente. Isto não seria bom para o progresso da otimização do seu Core Web Vitals, obviamente.

Dividir ficheiros CSS em ficheiros CSS específicos do dispositivo

Caso tenha escrito demasiado CSS para o design do seu website, considere agrupar estes ficheiros CSS (na mesma ordem em que são carregados no DOM) e depois dividi-los em três ficheiros CSS diferentes:

• um ficheiro que não possui consultas de media;
• um ficheiro com apenas media queries para dispositivos móveis (smartphones e tablets);
• um ficheiro que contém consultas de media apenas para portáteis e desktops.

Esteja ciente: se o seu website utilizar cache de saída HTML, certifique-se de verificar se esta ferramenta tem uma opção para manter um cache separado para dispositivos móveis. Caso contrário, o que pode acontecer é que o CSS para portáteis e desktops seja colocado em fila para dispositivos móveis, se a página for armazenada em cache num pedido de desktop. O mesmo pode acontecer ao contrário. Se tal não for possível, sugiro não dividir os seus ficheiros CSS em ficheiros específicos do dispositivo.

Por favor, mantenha um backup dos seus ficheiros CSS originais. Pode executar user-agent sniffing em PHP, ou em qualquer outra linguagem de backend, para descobrir se deve enfileirar o ficheiro CSS para dispositivos móveis ou para portáteis e desktops. Desta forma, pode enfileirar ficheiros que contenham apenas as media queries que podem corresponder às larguras da janela de visualização de dispositivos móveis, portáteis ou desktops. Deve então utilizar JavaScript como uma forma fiável de fazer backup, verificando a largura da janela de visualização do dispositivo (o que não é possível utilizando linguagens de backend, uma vez que estes dados não são transferidos através de pedidos ao seu servidor, infelizmente).

Quanto mais CSS tiver de ser processado e aplicado, mais tempo levará para o browser desenhar/renderizar a página web. Menos CSS é melhor para a terceira métrica do Core Web Vitals: Largest Contentful Paint (LCP).

Remover JavaScript e CSS não utilizados

O JavaScript pode realmente tornar uma página lenta, especialmente quando há muito JavaScript. Por conseguinte, é melhor remover o JavaScript que não é utilizado. A mesma história é válida para os ficheiros CSS.

Discuti como remover CSS não utilizado automaticamente.

Pré-carregamento de CSS importante no <head>

Se o ficheiro CSS mais importante for descarregado depois de outros ficheiros, isto pode causar um período em que o navegador da Web pode já ter desenhado a página da Web antes de o ficheiro CSS mais importante ter sido descarregado, não sendo ainda aplicado. Isto parece feio e é mau para a sua pontuação CLS, pois também causa grandes alterações de layout.

Pontuações elevadas no CLS significam fraca estabilidade visual (#3 do Core Web Vitals). O simples facto de mover o ficheiro CSS mais importante para o topo do <head> permitirá que as regras no seu ficheiro CSS sejam substituídas pelos ficheiros CSS que serão aplicados depois do seu ficheiro CSS mais importante. A propósito, isto não é bom.

No entanto, pode dizer ao navegador da Web para descarregar o ficheiro CSS mais importante com antecedência, mas que a prioridade do ficheiro CSS depende da posição da etiqueta <link> que faz referência a esse ficheiro CSS. Isto minimizará a hipótese de os navegadores da Web exibirem a sua página antes de aplicar o ficheiro CSS mais importante, por causa do download tardio. Ver Figura 7.

Lazy rendering

Quando abre uma página web, o seu navegador utilizará os ficheiros CSS para estilizar o documento HTML. Quanto maior for o ficheiro CSS, mais elementos serão afetados pelo ficheiro, fazendo com que o browser necessite de mais tempo para desenhar a página web.

O seu navegador desenha a página inteira, independentemente de todas as secções aparecerem ou não na sua janela de pré-visualização em algum momento ao fazer scroll para baixo. É possível dizer ao seu navegador para desenhar apenas a parte da página que é visível dentro da sua janela de visualização (com mais 50% da altura da sua janela de visualização para além do que pode ver). Isto poupará tempo do seu navegador ao renderizar a página web.

É a mesma ideia das imagens de lazy loading, o que significa que o browser apenas carrega imagens que são visíveis na janela de pré-visualização. Veja a Figura 8 para uma pré-visualização.

Aplicar lazy rendering é fácil, mas também traz alguns problemas: quando uma secção não é renderizada pelo navegador da Web, não tem altura.

Isto fará com que a página web pareça mais pequena, porque o polegar da barra de deslocamento é maior (indicando que a página é mais pequena), por causa de todas as secções que têm 0 pixels de altura.

Quando um visitante faz scroll para baixo, as outras secções entrarão no limite de lazy rendering e serão renderizadas, ocupando espaço em conformidade. Isto fará com que o polegar da barra de deslocamento fique louco. Para evitar isto, as secções precisam de uma altura estimada que deve fornecer você mesmo. Ver Figura 9.

No entanto, estas estimativas precisam de ser bastante precisas para oferecer uma experiência perfeita. Também necessita de outras correções.

Deseja fornecer uma estimativa automática para a altura das secções? Se sim, não deixe de consultar o nosso post no blogue sobre como calcular o contain-intrinsic-size para content-visibility, que aborda isto com o máximo de detalhe possível.