O Largest Contentful Paint (LCP) é uma métrica de experiência do utilizador do Google integrada nos sistemas de classificação em 2021.
O LCP é um dos três Core Web Vitals (CWV) métricas que acompanham as métricas de desempenho técnico com impacto na experiência do utilizador.
Os Core Web Vitals existem paradoxalmente, com a Google a fornecer orientações que realçam a sua importância, mas minimizando o seu impacto nas classificações.
O LCP, tal como os outros sinais CWV, é útil para diagnosticar problemas técnicos e garantir que o seu sítio Web cumpre um nível básico de funcionalidade para os utilizadores.
O que é o Largest Contentful Paint?
O LCP é uma medida do tempo que leva para que o conteúdo principal de uma página seja descarregado e esteja pronto para ser interagido.
Especificamente, o tempo que demora desde o início do carregamento da página até à apresentação da maior imagem ou bloco de texto dentro da janela de visualização do utilizador. Tudo o que estiver abaixo da dobra não conta.
Imagens, imagens de vídeo, imagens de fundo e elementos de texto ao nível do bloco, como etiquetas de parágrafo, são elementos típicos medidos.
O LCP consiste nas seguintes submétricas:
Otimizar para o LCP significa otimizar para cada uma destas métricas, para que demore menos de 2,5 segundos a carregar e a apresentar os recursos do LCP.
Aqui está uma escala de limiares para sua referência:
Limiares LCPVamos analisar o significado destas submétricas e como pode melhorar.
Tempo até o primeiro byte (TTFB)
O TTFB é o tempo de resposta do servidor e mede o tempo que o browser do utilizador demora a receber o primeiro byte de dados do seu servidor. Isto inclui o tempo de pesquisa de DNS, o tempo que demora a processar os pedidos pelo servidor e os redireccionamentos.
A otimização do TTFB pode reduzir significativamente o tempo de carregamento geral e melhorar o LCP.
O tempo de resposta do servidor depende em grande parte de:
- Consultas à base de dados.
- Falhas de cache CDN.
- Renderização ineficiente do lado do servidor.
- Alojamento.
Vamos analisar cada um deles:
1. Consultas a bases de dados
Se o seu tempo de resposta for elevado, tente identificar a origem.
Por exemplo, pode ser devido a consultas mal optimizadas ou a um elevado volume de consultas que diminuem o tempo de resposta do servidor. Se tiver uma base de dados MySQL, pode registar as consultas lentas para descobrir quais as consultas que são lentas.
Se tiver um sítio Web WordPress, pode utilizar o Monitor de consultas para ver quanto tempo demoram as consultas SQL.
Outras ferramentas excelentes são Blackfire ou Nova relíquia, que não dependem do CMS ou da pilha que utiliza, mas requerem a instalação no seu alojamento/servidor.
2. Falhas na cache da CDN
Uma perda de cache CDN ocorre quando um recurso solicitado não é encontrado na cache da CDN e o pedido é reencaminhado para ser obtido no servidor de origem. Este processo demora mais tempo, o que leva a um aumento da latência e a tempos de carregamento mais longos para o utilizador final.
Normalmente, o seu fornecedor de CDN tem um relatório sobre o número de cache misses que você tem.
Exemplo de relatório de cache de CDNSe observar uma percentagem elevada ( >10% ) de cache misses, poderá ter de contactar o seu fornecedor de CDN ou o suporte de alojamento, caso tenha um alojamento gerido com cache integrada, para resolver o problema.
Um motivo que pode causar falhas de cache é quando tem um ataque de spam de pesquisa.
Por exemplo, uma dúzia de domínios com spam ligam às suas páginas de pesquisa interna com consultas aleatórias com spam, como [/?q=甘肃代], que não são armazenadas em cache porque o termo de pesquisa é diferente de cada vez. O problema é que o Googlebot rastreia-os agressivamente, o que pode causar tempos de resposta elevados do servidor e falhas na cache.
Nesse caso, e no geral, é um boa prática bloquear URLs de pesquisa ou facetas através de robots.txt. Mas depois de os bloquear através do robots.txt, pode descobrir que esses URLs a serem indexados porque têm backlinks de sítios Web de baixa qualidade.
No entanto, não tenha medo. John Mueller disse que seria resolvido a tempo.
Aqui está um exemplo real da consola de pesquisa de um tempo de resposta elevado do servidor (TTFB) causado por falhas na cache:
Pico de rastreio de páginas de pesquisa 404 que têm um tempo de resposta do servidor elevado3. Renderização ineficiente do lado do servidor
Poderá ter certos componentes no seu sítio Web que dependem de APIs de terceiros.
Por exemplo, já viu números de leituras e partilhas nos artigos do SEJ. Nós vamos buscar esses números a diferentes APIs, mas em vez de os ir buscar quando é feito um pedido ao servidor, vamos buscá-los previamente e armazená-los na nossa base de dados para uma visualização mais rápida.
Imagine que nos ligamos às APIs share count e GA4 quando é feito um pedido ao servidor. Cada pedido demora cerca de 300-500 ms a ser executado, e acrescentaríamos cerca de ~1.000 ms de atraso devido à renderização ineficiente do lado do servidor. Portanto, certifique-se de que seu backend esteja otimizado.
4. Alojamento
Tenha em atenção que o alojamento é muito importante para um TTFB baixo. Se escolher o alojamento correto, poderá reduzir o seu TTFB em duas a três vezes.
Escolha um alojamento com CDN e caching integrados no sistema. Isto ajudá-lo-á a evitar a compra de uma CDN separadamente e a poupar tempo na sua manutenção.
Portanto, investir no alojamento certo vai compensar.
Leia orientações mais pormenorizadas:
Agora, vamos analisar outras métricas mencionadas acima que contribuem para o LCP.
Atraso na carga de recursos
O atraso no carregamento do recurso é o tempo que o navegador leva para localizar e começar a descarregar o recurso LCP.
Por exemplo, se tiver uma imagem de fundo na sua secção de heróis que exija o carregamento de ficheiros CSS para ser identificada, haverá um atraso igual ao tempo que o browser necessita para descarregar o ficheiro CSS para começar a descarregar a imagem LCP.
No caso de o elemento LCP ser um bloco de texto, este tempo é zero.
Ao otimizar a rapidez com que estes recursos são identificados e carregados, pode melhorar o tempo necessário para apresentar conteúdo crítico. Uma forma de o fazer é pré-carregar ficheiros CSS e imagens LCP com fetchpriority=”high”, para que o browser dê prioridade ao carregamento de imagens e estilos acima da dobra.
<link rel="preload" fetchpriority="high" as="style" href="https://www.searchenginejournal.com/assets/css/styles.css" onload="this.onload=null;this.rel="stylesheet"">
<link rel="preload" fetchpriority="high" as="image" href="http://www.searchenginejournal.com/media/hero.webp" type="image/webp">Mas uma abordagem melhor – se tiver controlo suficiente sobre o Web site – é coloque em linha o CSS crítico necessárias para a parte superior da dobra, para que o browser não perca tempo a descarregar o ficheiro CSS. Isto poupa largura de banda e ajuda a carregar imagens mais rapidamente.
Obviamente, é ainda melhor se conceber as páginas Web de modo a evitar imagens de herói ou barras deslizantes, uma vez que estas normalmente não acrescentam valore os utilizadores tendem a passar por cima delas porque as distraem.
Outro fator importante que contribui para o atraso no carregamento é redireccionamentos.
Se tiver backlinks externos com redireccionamentos, não há muito que possa fazer. Mas tem controlo sobre os seus links internos, por isso tente encontrar links internos com redireccionamentos, normalmente devido à falta de barras finais, versões não-WWW ou URLs alterados, e substitua-os por destinos reais.
Há uma série de ferramentas técnicas de SEO que pode utilizar para rastrear o seu sítio Web e encontrar redireccionamentos que devem ser substituídos.
Duração da carga de recursos
A duração da carga do recurso refere-se ao tempo efetivo gasto no descarregamento do recurso LCP.
Mesmo que o browser encontre e inicie rapidamente o descarregamento de recursos, as velocidades de descarregamento lentas podem afetar negativamente o LCP. Depende do tamanho dos recursos, da velocidade de ligação à rede do servidor e das condições de rede do utilizador.
Pode reduzir a duração da carga dos recursos implementando:
- Formato WebP.
- Imagens corretamente dimensionadas (faça com que o tamanho intrínseco da imagem corresponda ao tamanho visível).
- Priorização de carga usando fetchpriority=”high” em recursos importantes e fetchpriority=”low” em recursos não críticos.
- CDN.
Atraso de renderização do elemento
O atraso de renderização do elemento é o tempo que o navegador leva para processar e renderizar o elemento LCP.
Essa métrica é influenciada pela complexidade do seu HTML, CSS e JavaScript.
Minimizar os recursos de bloqueio de renderização e otimizar o seu código pode ajudar a reduzir esse atraso. No entanto, pode acontecer que tenha scripts JavaScript pesados em execução, o que bloqueia o thread principale a renderização do elemento LCP é atrasada até que essas tarefas estejam concluídas.
É aqui que os valores baixos da métrica Total Blocking Time (TBT) são importantes, pois mede o tempo total durante o qual a thread principal é bloqueada por tarefas longas no carregamento da página, indicando a presença de scripts pesados que podem atrasar a renderização e capacidade de reação.
Uma forma de melhorar não só a duração e o atraso do carregamento, mas também todas as métricas CWV, quando os utilizadores navegam no seu sítio Web é implementar API de regras de especulação para futuras navegações. Ao pré-renderizar páginas à medida que os utilizadores passam o rato por cima de links ou páginas que provavelmente irão navegar, pode fazer com que as suas páginas carreguem instantaneamente.
Cuidado com estes “erros” de pontuação
Todos os elementos no ecrã do utilizador (a janela de visualização) são utilizados para calcular o LCP. Isto significa que as imagens renderizadas fora do ecrã e depois deslocadas para o layout, uma vez renderizadas, podem não contar como parte da pontuação do Largest Contentful Paint.
No extremo oposto, os elementos que começam na janela de visualização do utilizador e depois são empurrados para fora do ecrã podem ser contabilizados como parte do cálculo do LCP.
Como medir a pontuação do LCP
Existem dois tipos de ferramentas de pontuação. A primeira chama-se Ferramentas de campoe o segundo chama-se Ferramentas de laboratório.
As ferramentas de campo são medições reais de um sítio.
As ferramentas de laboratório dão uma pontuação virtual com base num rastreio simulado utilizando algoritmos que se aproximam das condições da Internet que um utilizador típico de telemóvel pode encontrar.
Aqui está uma forma de encontrar recursos LCP e medir o tempo para os apresentar através de DevTools > Desempenho relatório:
Pode ler mais no nosso guia pormenorizado sobre como medir as métricas de CWVonde pode aprender a solucionar problemas não só do LCP, mas também de outras métricas.
A otimização do LCP é um assunto muito mais aprofundado
Melhorar o LCP é um passo crucial para melhorar a CVW, mas pode ser a métrica CWV mais difícil de otimizar.
O LCP consiste em várias camadas de sub-métricas, cada exigindo um conhecimento profundo para uma otimização eficaz.
Este guia deu-lhe uma ideia básica sobre como melhorar o LCP, e os conhecimentos que adquiriu até agora ajudá-lo-ão a fazer melhorias significativas.
Mas ainda há mais para aprender. A otimização de cada submétrica é uma ciência cheia de nuances. Fique atento, pois publicaremos guias detalhados dedicados à otimização de cada submétrica.
Mais recursos:
Crédito da imagem em destaque: BestForBest/Shutterstock