O Google está em uma missão para melhorar o desempenho da web com o Core Web Vitals. Por quê? Porque os negócios do Google são predominantemente baseados na web – sites lentos e aplicativos web empurram os usuários de volta aos aplicativos nativos.
A sua colocação nos resultados de pesquisa do Google é em grande parte determinada pelas palavras-chave do termo de pesquisa, pela utilização dessas palavras-chave dentro da sua página e pela popularidade da sua página de acordo com o número (e qualidade) de links de outros lugares. A partir de agosto de 2021, o Google também está fazendo esforços para avaliar as páginas com base no desempenho.
Este artigo irá mostrar-lhe como pode optimizar o seu site para as métricas do Core Web Vitals do Google.
Porquê o Core Web Vitals?
O conteúdo continua sendo crucial. Mas se você comparar dois sites com texto e popularidade semelhantes, aquele que oferece a melhor experiência na web terá maior prioridade nos resultados de pesquisa do Google.
Além de uma melhor classificação da página, os sites de alto desempenho são elegíveis para inclusão no carrossel de busca móvel. Isto era anteriormente reservado para as Accelerated Mobile Pages (AMP), que exigiam que você portasse o conteúdo para um site separado hospedado no Google. O AMP tem atraído críticas, especialmente porque as páginas nem sempre são mais rápidas que um site WordPress ou um site estático bem otimizado. No entanto, isso não é mais um requisito.
Não importa o que você escolher, quanto mais rápido e mais ágil for o seu site, melhores serão as chances de ele se classificar mais alto nos resultados de pesquisa do Google.
Quando você considera que a página média é de cerca de 2 MB, faz mais de 60 pedidos HTTP e leva 16 segundos para renderizar totalmente em um dispositivo móvel, você verá que há alguma margem para melhorar o seu site. Nós lhe mostraremos as melhores maneiras de conseguir essas melhorias.
Fatores chave do ranking do Google
Existem quatro fatores chave de classificação para examinar antes de começar a avaliar o desempenho:
- HTTPS: HTTPS é essencial. O seu site estabelece uma conexão segura entre o navegador do usuário e o servidor web?
- Mobile-Friendly: O seu site deve funcionar bem em um dispositivo móvel. O seu site é utilizável em dispositivos de tela pequena? Ele renderiza sem transbordamento de conteúdo? O texto é suficientemente grande? As áreas clicáveis são suficientemente grandes para o controle de toque?
- Sem intersticiais: Evite intersticial intrusivo que exijam um espaço de tela pouco razoável. O seu conteúdo é sempre legível? É parcialmente obscurecido por intersticiais pop-up ou banners? A sua publicidade ou promoções de marketing estão a dificultar a utilização do site?
- Navegação segura: O seu site deve estar livre de malware, vírus, phishing, fraude e outros golpes.
Uma vez satisfeitos estes requisitos, o seu site será avaliado quanto ao seu desempenho.
Como o Google avalia o desempenho da web?
Fazer seu site carregar rapidamente, renderizar rapidamente e ser responsivo mais cedo é vital. Mas será que os usuários se sentem rápidos?
Aplicativos de medição de desempenho como o browser DevTools reportam medições técnicas como, por exemplo:
- Tempo de bloqueio: O tempo gasto à espera que um download comece, normalmente porque outros recursos, como folhas de estilo e scripts, têm maior prioridade.
- Resolução DNS: O tempo para resolver um hostname para um endereço IP para recuperar um activo.
- Tempo conectado: O tempo para inicializar uma ligação TCP.
- Tempo para o primeiro byte (TTFB): O tempo total entre o pedido e o primeiro byte de resposta.
- Tempo recebido: O tempo para recuperar todo o ativo.
- Tempo de carregamento DOM: O tempo para baixar e renderizar o Modelo de Objeto do Documento HTML. Este é normalmente o primeiro ponto em que os scripts que analisam ou modificam o DOM podem ser executados de forma confiável.
- Tempo de carregamento da página: O tempo para baixar a página e todos os ativos como imagens, folhas de estilo, scripts, e assim por diante
- Peso total da página: O tamanho total de todos os bens. É frequentemente reportado tanto num tamanho comprimido (download) como num tamanho não comprimido.
- O número de elementos DOM: O número total de elementos HTML na página. Quanto mais elementos, mais tempo a página leva para processar.
- First Contentful Paint (FCP): O tempo que leva antes do navegador renderizar o primeiro pixel de conteúdo.
- First Meaningful Paint (FMP): O tempo que leva antes que o conteúdo da página principal se torne visível para o usuário.
- Time to Interactive (TTI): O tempo que leva antes de uma página é totalmente interativo e pode responder de forma confiável à entrada do usuário.
- Primeira CPU ociosa: O tempo para a CPU renderizar a página e executar todos os scripts de inicialização, esperando por mais informações.
- Utilização de CPU: A atividade de processamento necessária durante a renderização da página e a resposta à entrada do usuário.
- Layouts por segundo: O ritmo ao qual o navegador tem que recalcular estilos e layouts de página.
Estes podem ser usados para determinar gargalos específicos, tais como carga do servidor, cache CMS, cache do navegador, velocidades de download e eficiência do JavaScript. Mas eles não podem determinar se uma página fornece uma boa ou má experiência para o usuário. Por exemplo:
- Um aplicativo poderia baixar e aparecer rapidamente, mas ficar sem resposta após a primeira interação, pois está executando uma grande quantidade de código JavaScript não otimizado.
- Um aplicativo de chat pode descarregar dados continuamente à medida que os utilizadores colocam mensagens. Uma ferramenta de avaliação pode presumir que nunca completou o carregamento, apesar de a página se sentir responsiva.
O Core Web Vitals é a tentativa do Google para resolver estes dilemas.
O que são Core Web Vitals?
O Core Web Vitals do Google (CWV) são três métricas de desempenho que avaliam a experiência do usuário no mundo real:
- Largest Contentful Paint (LCP): Desempenho de carregamento
- First Input Delay (FID): Desempenho de interatividade
- Cumulative Layout Shift (CLS): Desempenho de estabilidade visual
Esta nova atualização do algoritmo do Google começou a ser implementada globalmente no final de agosto de 2021. As métricas do Core Web Vitals afetam principalmente os resultados da pesquisa móvel, mas os equivalentes de desktop seguirão se o experimento for bem sucedido.
As pontuações LCP, FID e CLS de uma página são baseadas nos últimos 28 dias de métricas de usuários reais coletadas anonimamente através do navegador Chrome. Essas medidas podem variar devido ao dispositivo do usuário, conexão e outras atividades simultâneas, portanto o percentil 75 é calculado em vez de uma média.
Em outras palavras, as métricas de todos os usuários são ordenadas do melhor para o pior, e o número no ponto três quartos é tomado. Três em cada quatro visitantes do site irão, portanto, experimentar esse nível de desempenho ou melhor.
Qualquer página que atinja uma boa pontuação (verde) para os três indicadores do Core Web Vitals receberá uma classificação superior nos resultados de pesquisa e será incluída no carrossel “Top Stories” no aplicativo Google News.
Nas seções seguintes, descreveremos o algoritmo usado para calcular uma métrica, as ferramentas que você pode usar para identificar a pontuação de uma página, as causas típicas de pontuação baixa e os passos que você pode tomar para resolver problemas de desempenho.
Largest Contentful Paint (LCP)
Largest Contentful Paint mede o desempenho do carregamento. Em essência, com que rapidez o conteúdo utilizável é apresentado na página?
LCP analisa quanto tempo leva para que a maior imagem ou bloco de texto fique visível dentro do viewport do navegador (acima da dobra). Na maioria dos casos, o item mais proeminente será um hero image, banner, cabeçalho ou um grande bloco de texto.
Qualquer um dos seguintes elementos é elegível para a análise da Largest Contentful Paint:
- imagens (
< img>elemento) - imagens dentro de gráficos vetoriais (uma
<imagem>embutida em uma< svg>) - miniaturas de vídeo (um atributo de um poster definido para uma URL de imagem dentro de um elemento
<video>) - elementos com imagens de fundo (normalmente carregados com a propriedade CSS
background-image url()) - elementos de nível de bloco contendo texto
São consideradas boas (verdes) as páginas onde o Largest Contentful Paint é completada nos primeiros 2,5 segundos do carremento de página. Páginas que excedam 4,0 segundos são consideradas pobres (vermelho):
As maiores ferramentas do Largest Contentful Paint
LCP é a métrica Core Web Vital mais fácil de compreender, mas pode não ser óbvio qual elemento será escolhido para análise.
O painel do Farol DevTools é fornecido em navegadores baseados em cromo, cromo, Edge, Brave, Opera, e Vivaldi. Abra o DevTools no menu do navegador – geralmente em Mais ferramentas > Ferramentas do desenvolvedor ou os atalhos do teclado Ctrl | Cmd + Shift + i ou F12 – depois navegue até a aba do Farol (edições mais antigas podem chamá-lo de Auditoria).
Gerar um relatório de desempenho móvel e, em seguida, examinar a seção de desempenho resultante. O Largest Contentful Paint é mostrado com uma seção expansível, que identifica o elemento escolhido:
Você pode gerar informações idênticas na PageSpeed Insights on-line e ferramentas web.dev Measure se você não tiver acesso a um navegador baseado no Chromium:
O painel DevTools Performance também exibe um indicador LCP. Para começar, clique no ícone circular Record, recarregue a sua página e depois clique no botão Stop para ver o relatório. Clique no ícone LCP na seção Timings para identificar o elemento e ver um resumo das estatísticas.
A extensão Web Vitals está disponível para o Google Chrome, mas pode ser instalada na maioria dos navegadores baseados no Chromium. Ele calcula o Core Web Vitals metrics para cada site que você visita, e seu ícone fica verde, laranja ou vermelho, dependendo do resultado. Você também pode clicar no ícone de extensão para ver mais detalhes do LCP:
O Console de Pesquisa do Google oferece agora uma seção Core Web Vitals se o seu site for adicionado como uma propriedade. O relatório ilustra como as métricas do CWV mudaram ao longo do tempo. Note que ele não identifica métricas LCP específicas, e apenas sites com tráfego razoavelmente alto estão disponíveis:
O Relatório de experiência do utilizador Chrome permite-lhe consultar estatísticas de utilização reais, incluindo LCP em diferentes países, ligações e dispositivos, para um URL específico. É um projecto público no Google BigQuery, pelo que deve inscrever-se numa conta da Plataforma Google Cloud e fornecer detalhes de facturação. Mais uma vez, o relatório só será útil quando um URL tiver um nível de tráfego razoavelmente alto.
Finalmente, a biblioteca Javascript de 1 kB é um pequeno script de 1 kB que pode calcular LCP e outras métricas do Core Web Vital para usuários reais no seu site de produção (ao vivo). Como ela pode ser baixada de um CDN, você pode adicionar o seguinte script ao seu HTML < head>:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP() é uma função assíncrona que passa por um callback disparada quando o valor LCP foi calculado (embora possa nunca disparar se a página for carregada em uma guia de fundo). A função callback é passada por um objeto que contém:
name: o nome da métrica (“LCP”, neste caso)value: o valor calculadoid: uma identificação única que representa esta métrica para a página atualdelta: o delta entre o valor atual e o último valor reportadoentries: um conjunto de entradas utilizadas no cálculo do valor
O script acima envia o objeto para o console, embora seja mais prático enviar os dados para um servidor ou para o Google Analytics para análise posterior.
Causas comuns das piores pontuações do Largest Contentful Paint
Páginas de LCP fracas são normalmente causadas por páginas de carregamento lento que impedem que o maior bloco apareça rapidamente:
- A resposta do servidor pode ser lenta porque está sobrecarregada ou fazendo muito trabalho para renderizar uma página. Isto pode não ser necessariamente culpa do seu site – pode ser devido a restrições do servidor se você estiver usando um serviço de hospedagem compartilhado.
- Render-blocking CSS e JavaScript podem atrasar o carregamento da página se forem referenciados no HTML acima do conteúdo principal.
- Outros recursos como imagens e vídeos grandes podem reduzir a largura de banda disponível e demorar mais tempo a renderizar.
- O conteúdo da página gerado no cliente e não no servidor também leva mais tempo para aparecer.
Como melhorar as pontuações do Largest Contentful Paint
Uma auditoria completa pode identificar problemas de carregamento, mas geralmente é uma questão de reduzir a quantidade de dados enviados para o navegador. As seguintes dicas ajudarão a obter uma pontuação LCP mais saudável:
- Atualize o seu servidor e/ou serviço de hospedagem de WordPress. Certifique-se de que as velocidades de download permanecem rápidas, mesmo em momentos de alta utilização.
- Ative a compressão do servidor e HTTP/2+. Não há razão para não fazer!
- Reduzir o esforço do servidor. Remova o código não utilizado e os plugins do CMS e, em seguida, habilite o cache efetivo.
- Certifique-se de que o navegador pode fazer o cache de arquivos de forma eficaz. Defina Expires, Last-Modified e/ou ETag hashes apropriados no cabeçalho HTTP, para que os arquivos não sejam solicitados novamente.
- Use uma Rede de Entrega de Conteúdo (CDN) para dividir a carga e os ativos do host em servidores geograficamente mais próximos dos usuários.
- Aumente sua otimização geral usando o recurso de minificação de código que está embutido no painel MyKinsta.
- Otimize suas imagens. Reduza para suas menores dimensões e use um formato apropriado para minimizar o tamanho dos arquivos. Garanta que qualquer imagem no bloco de conteúdo maior seja solicitada o mais cedo possível; uma pré-carga pode ajudar.
- Carregue imagens preguiçosas adicionando um atributo
loading="lazy". Adicione atributos de largura e altura para garantir que o espaço apropriado seja reservado na página antes que a imagem termine de carregar. - Minimize os pedidos de terceiros e considere mover ativos para o seu domínio primário para evitar consultas externas ao DNS.
- Minimize o número e tamanho dos arquivos solicitados, especialmente na parte superior do seu HTML.
- Assegure-se de carregar somente as fontes web necessárias. Mude para fontes seguras para a web para obter o máximo desempenho.
- Remova os arquivos JavaScript e CSS não utilizados.
- Concatenar e minificar os seus arquivos JavaScript e CSS.
- Evite declarações CSS @import – elas são estilos de renderização e carregamento em série.
- Evite a codificação Base64 – ela aumenta o tamanho dos arquivos e requer processamento adicional.
- Considere o CSS crítico em linha. Incorpore o VCC essencial “acima da dobra” em um
<link>bloco no topo da página, depois carregue as folhas de estilo adicionais de forma assíncrona. - Use o JavaScript assíncrono, diferido, ou o módulo ES para executar scripts mais tarde. Executar processos JavaScript de longa duração em um prestador de serviços
First Input Delay (FID)
O First Input Delay mede a capacidade de resposta da sua página. Em essência, com que rapidez ele responde às ações do usuário, como clicar, tocar e rolar?
A métrica do FID é calculada como o tempo entre a interação do usuário e o processamento do seu pedido pelo navegador. Ela não mede o tempo para executar a função do manipulador, que normalmente processaria a entrada e atualizaria o DOM.
Páginas com um tempo FID de 100 milissegundos ou menos são consideradas boas (verdes). Páginas com tempo FID superior a 300 milissegundos são consideradas pobres (vermelho):
Ferramentas de análise do First Input Delay
First Input Delay é quase impossível de simular porque só pode ser medido quando a página é servida a um usuário real que interage com a página. O resultado depende, portanto, da velocidade e capacidade de processamento de cada dispositivo.
O FID não é calculado no painel do DevTools Lighthouse ou PageSpeed Insights. No entanto, eles podem determinar o Total Blocking Time (TBT). Esta é uma aproximação razoável para o Primeiro Atraso de Entrada. Ele mede a diferença de tempo entre eles:
- O First Contentful Paint (FCP), ou o momento em que o conteúdo da página começa a renderizar, e
- O Time to Interactive (TTI), ou o momento em que a página pode responder a entrada do usuário. A TTI é presumida quando nenhuma tarefa de longa duração está ativa e menos de três solicitações HTTP ainda não foram concluídas.
A extensão Web Vitals para o Google Chrome também pode mostrar uma métrica FID depois de interagir com a página, rolando ou clicando. Clique no ícone da extensão para revelar mais informações:
Tal como o LCP, o Relatório de Experiência do Utilizador do Chrome permite-lhe consultar estatísticas FID reais registadas em diferentes países, ligações e dispositivos para um URL específico.
A biblioteca de Javascript em formato web-vitals também pode calcular métricas FID para usuários reais no seu site ao vivo. Você pode adicionar o seguinte script ao seu HTML <head> para gerar métricas FID em uma função callback:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
Causas comuns de atrasos First Input Delay
A má pontuação de FID e TBT é geralmente causada pelo código do lado do cliente que atrapalha o processador, como por exemplo:
- Quantidades significativas de CSS e JavaScript de render-blocking, que param o carregamento da página à medida que o código é baixado e analisado.
- Scripts grandes, de processo intensivo, que são executados imediatamente quando a página é carregada.
- Tarefas JavaScript de longa duração ou mal optimizadas
Por padrão, os navegadores são executados em uma única linha, que só pode processar uma tarefa de cada vez. Se uma função JavaScript leva um segundo para ser executada, todos os outros processos de renderização são bloqueados durante esse segundo. A página não pode reagir à entrada do usuário, atualizar o DOM, mostrar animações, ou assim por diante. Mesmo as animações GIF podem ser bloqueadas em navegadores mais antigos.
Como melhorar as pontuações do First Input Delay
Uma auditoria JavaScript do lado do cliente pode identificar problemas, mas geralmente é uma questão de remover código redundante e garantir que as tarefas sejam executadas rapidamente.
As seguintes dicas vão ajudar a obter uma pontuação mais saudável no FID:
- Criar e armazenar no servidor o máximo de conteúdo HTML estático possível. Tente não confiar em frameworks JavaScript do lado do cliente para renderizar o mesmo HTML para todos.
- Certifique-se de que o navegador pode fazer o cache de arquivos de forma eficaz. Defina Expires, Last-Modified e/ou ETaghashes apropriados no cabeçalho HTTP, para que os arquivos não sejam solicitados novamente.
- Adote técnicas de melhoria progressiva, para que a interface seja utilizável em HTML e CSS antes da execução do JavaScript.
- Remova os arquivos JavaScript e CSS não utilizados.
- Concatenar e minificar os seus arquivos JavaScript e CSS.
- Evite o uso excessivo de propriedades CSS caras, tais como box-shadow e filtro.
- Use o JavaScript assíncrono, diferido, ou o módulo ES para executar scripts mais tarde.
- Minimize os pedidos Javascript de terceiros para análises, widgets de redes sociais, fóruns de discussão, etc. Estes podem montar rapidamente até vários megabytes de JavaScript.
- Carregue os componentes JavaScript sob demanda, por exemplo, widgets de chat, reprodutores de vídeo, etc.
- Atraso no carregamento de scripts menos críticos, tais como análises, anúncios e ferramentas de mídia social.
- Dividir tarefas JavaScript de longa duração em uma série de tarefas menores que são executadas após uma curta solicitaçãoIdleCallback, setTimeout, ou requestAnimationFrame delay.
- Considere a execução de processos JavaScript de longa duração em um web worker, que usa uma linha de fundo.
Cumulative Layout Shift (CLS)
O CLS mede a estabilidade visual da página. Em essência, o conteúdo da página move-se ou salta inesperadamente, especialmente durante a carga inicial?
O CLS calcula uma pontuação quando os elementos se movem sem aviso ou interação do usuário. Você provavelmente já experimentou isso ao ler um artigo em um dispositivo móvel – o texto salta repentinamente da tela, e você perde o seu lugar. Os piores exemplos podem fazer com que você clique em um link incorreto.
Os problemas do CLS são mais proeminentes quando uma imagem grande ou um anúncio é carregado acima da posição atual de rolagem e um espaço de altura zero cresce instantaneamente em várias centenas de pixels.
As pontuações acumuladas do Layout Shift são calculadas multiplicando as seguintes métricas juntas:
- A fração de impacto: Esta é a área total de todos os elementos instáveis no viewport, ou seja, aqueles que vão “saltar”. Se elementos que cobrem 60% do viewport forem deslocados durante a carga de página, a fração de impacto é de 0,6. Note que os elementos que causaram esse deslocamento, como uma imagem ou publicidade, são considerados estáveis porque não se movem necessariamente depois de serem renderizados.
- A fração de distância: Esta é a maior distância movida por qualquer elemento instável no viewport. Se o maior deslocamento ocorre em um elemento que se move de 0,100 para 0,800, ele foi deslocado por 700 pixels verticais. Se a porta de visualização do dispositivo é 1.000 px de altura, a fração de distância é 700 px / 1000 px = 0,7. A pontuação do Layout Shift acumulado calculado é portanto 0,6 x 0,7 = 0,42.
O Google fez alterações na métrica CLS para acomodar as seguintes situações:
- O Layout Shift são agrupados em “sessões” que duram cinco segundos, mas fecham após um segundo, se não ocorrerem mais Layout Shift. Se dois ou mais turnos ocorrerem dentro de um segundo, os seus resultados são adicionados.
- O Layout Shift não são gravados durante 500 ms após a interação do usuário, como por exemplo, um clique. Em alguns casos, isso aciona atualizações do DOM (por exemplo, abrir um menu, mostrar uma mensagem de erro, exibir um diálogo modal, etc.).
- Os aplicativos de página única que permanecem abertas por períodos mais longos e fazem numerosas atualizações DOM não são afetadas negativamente.
Páginas com uma pontuação CLS de 0,1 ou menos são consideradas boas (verdes). Páginas que excedam 0,25 são consideradas pobres (vermelho):
Ferramentas de análise do Cumulative Layout Shift
As métricas CLS são calculadas no painel DevTools Lighthouse, PageSpeed Insights, e ferramentas web.dev Measure:
A extensão WebVitals para o Google Chrome também mostra a métrica CLS:
Tal como o LCP e o FID, o Relatório de Experiência do Utilizador do Chrome permite-lhe consultar estatísticas CLS reais registradas em diferentes países, ligações e dispositivos para um URL específico.
A biblioteca de Javascript em formato web-vitals também pode calcular métricas CLS para usuários reais em seu site ao vivo, assim como faz com LCP e FID. O script a seguir pode ser adicionado ao seu HTML <head> para gerar métricas CLS para uma função callback :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
Causas comuns das más pontuações do Cumulative Layout Shift
As más pontuações do CLS são normalmente causadas por páginas de ativos com carregamento lento e elementos DOM dinâmicos ou não dimensionados:
- O espaço na página não é reservado para imagens, iframes, anúncios, etc.
- O conteúdo é injetado dinamicamente no DOM, normalmente depois de uma solicitação de rede para anúncios, widgets de mídia social, etc.
- O carregamento de fontes da Web causa um Flash visível de Texto Invisível (FOIT) ou Flash de Texto Não Esboçado (FOUT).
Como melhorar as pontuações do Cumulative Layout Shift
Uma auditoria do lado do cliente pode identificar problemas, mas geralmente é uma questão de garantir que o espaço é reservado para o conteúdo antes de fazer o download. As dicas de otimização do servidor sugeridas para o Largest Contentful Paint terão alguns benefícios, mas é possível melhorar ainda mais:
- Adicione atributos de largura e altura ao HTML
<img>e<iframe>tags ou use a nova propriedade CSS aspect-ratio para garantir que o espaço apropriado seja reservado na página antes do download de ativos. - Definir as dimensões apropriadas para os elementos do contentor que envolvem conteúdos de terceiros de carregamento mais lento, como anúncios e widgets.
- Certifique-se de que as imagens e outros recursos que aparecem no topo da página são solicitados o mais cedo possível – uma pré-carga pode ser útil.
- Minimize o uso de fontes da web e considere o uso de fontes de SO comumente disponíveis, quando possível.
- Carregar fontes web e definir a exibição de fontes CSS como opcional ou trocar. Certifique-se de usar uma fonte de tamanho se melhante para minimizar a mudança de layout.
- Evite inserir elementos na parte superior da página, a menos que responda a uma ação do usuário, como um clique.
- Certifique-se de que as interações do usuário estejam completas dentro de 500 milissegundos do gatilho de entrada.
- Use transformação CSS e opacidade para animações mais eficientes que não incorram em re-layout.
- Considere o CSS crítico em linha. Incorpore o CSS essencial “acima da dobra” em um
<link>bloco no topo da página, depois carregue as folhas de estilo adicionais de forma assíncrona. - Quando necessário, considere a contenção, uma nova funcionalidade CSS que lhe permite identificar sub-árvores isoladas de uma página. O navegador pode otimizar o processamento ao renderizar – ou não renderizar – blocos de conteúdo DOM específicos.
Resumo
Os desenvolvedores nem sempre estão interessados em dançar ao som da música do Google. A empresa tem um poder considerável, e pequenas atualizações do mecanismo de pesquisa podem afetar negativamente a produtividade e a lucratividade das organizações baseadas na web.
Dito isto, o Core Web Vitals tem uma abordagem “cenoura” em vez de “pau”. Sites bem otimizados e utilizáveis que renunciam a padrões escuros têm mais chances de sucesso do que sites inchados e pop-up-intensivos que oferecem uma interface móvel pobre.
O Core Web Vitals fornece uma forma mensurável de avaliar a experiência do usuário para ajudá-lo a focar nas melhorias mais críticas. As mudanças nos seus sinais vitais podem não aumentar as receitas, mas os seus utilizadores ficarão mais felizes e mais leais.
Você tem alguma outra dica sobre como melhorar o Core Web Vitals do núcleo da web? Compartilhe-as na seção de comentários!
Deixe um comentário