Lá em 2022, um site de comparação de hospedagem chegou na minha caixa de entrada. Grande catálogo — cerca de 4.000 páginas, estrutura de categorias profundamente aninhada, links de afiliação espalhados por tudo quanto é lado, imagens hero do tamanho de pequenos continentes. O Google Search Console deles era um filme de horror. LCP em 4.2 segundos no celular. INP (na época ainda chamado de FID) borderline. O cliente já tinha gasto £6.000 com uma agência anterior que tinha jogado um CDN naquilo e chamado de resolvido.
Esse projeto é o que eventualmente moldou como pensamos sobre performance na Seahawk para sites com alto número de páginas — sites de diretório, plataformas de listagem, propriedades de review de hospedagem como construções no estilo HostList. O que vem a seguir é o playbook real.Seahawk for high-page-count sites — directory sites, listing platforms, hosting review properties like HostList-style builds. What follows is the actual playbook.
---
Por Que Sites Grandes Quebram LCP de Forma Diferente
Sites pequenos têm problemas simples. Uma imagem hero, um tema, um plugin fazendo muito. Conserte essas três coisas e você está abaixo de 2 segundos.
Sites grandes? Coisa bem diferente. O elemento LCP muda dependendo de qual página você está. Um arquivo de categoria tem um candidato LCP diferente de uma página de detalhe de produto, que tem um candidato diferente da homepage. A maioria das ferramentas de performance reporta um único score. Esse número é uma mentira — é uma média de um conjunto vastamente variado de páginas, e corrigir a homepage enquanto ignora as 3.800 páginas de listagem abaixo dela é exatamente como agências ganham má reputação.which page you're on. A category archive has a different LCP candidate than a product detail page, which has a different candidate than the homepage. Most performance tools report a single score. That number is a lie — it's an average of a wildly varied set of pages, and fixing the homepage while ignoring the 3,800 listing pages underneath it is exactly how agencies earn bad reputations.
A documentação de Core Web Vitals do Google deixa claro que field data — o que usuários reais experimentam, medido no Chrome User Experience Report — é o que o Google realmente usa para sinais de ranking. Lab data do PageSpeed Insights é direcional, não definitivo. Já vi sites com score 95 no PSI e ainda assim com LCP Ruim nos dados de CrSX. Não confunda os dois.Core Web Vitals documentation from Google is clear that field data — what real users experience, measured in Chrome User Experience Report — is what Google actually uses for ranking signals. Lab data from PageSpeed Insights is directional, not definitive. I've seen sites score 95 on PSI and still have Poor LCP in CrSX data. Don't confuse the two.
Os Três Culpados Reais em Sites de Listagem
Em todos os grandes sites que auditei (e já passei por centenas neste ponto), falhas de LCP rastreiam três causas raiz quase sempre:
- Imagens de hero ou card não otimizadas — frequentemente servidas em resolução completa, formato errado, sem hint fetchpriority — often served at full resolution, wrong format, no
fetchpriorityhint - Scripts de terceiros que bloqueiam render — affiliate trackers, redes de anúncios, comparison widgets carregando antes do navegador conseguir pintar qualquer coisa — affiliate trackers, ad networks, comparison widgets loading before the browser can paint anything
- TTFB inflacionando o orçamento de LCP — resposta lenta do servidor consumindo 600–900ms antes da página nem começar a carregar — slow server response eating 600–900ms before the page even starts loading
Aquele terceiro é o que as pessoas subestimam. Se seu TTFB é 700ms, você já gastou quase metade do seu orçamento de LCP "Bom" antes do navegador ter renderizado um único pixel. Escolha de hosting e cache do lado do servidor não são preocupações de DevOps — são preocupações de SEO.
---
Comece com TTFB: É Primeiro um Problema de Hosting e Caching
O projeto do tipo HostList que mencionei acima? A primeira coisa que fiz foi rodar WebPageTest de cinco localizações geográficas diferentes. TTFB foi consistentemente 680–820ms. O site estava em um host compartilhado na Virgínia. A maioria do tráfego orgânico deles vinha do Reino Unido e da Alemanha.WebPageTest from five different geographic locations. TTFB was consistently 680–820ms. The site was on a shared host in Virginia. Most of their organic traffic came from the UK and Germany.
Mudei para um host WordPress gerenciado com edge nodes em Londres e Frankfurt. Configurei cache de página completa com tempos de vida de 12 horas nas páginas de listagem (os dados não mudavam com tanta frequência mesmo assim). TTFB caiu para 120–180ms em requisições repetidas, 280–350ms em cache misses de primeiro acesso. Essa mudança única reduziu aproximadamente 500ms do LCP antes de eu tocar em uma única imagem.
Algumas coisas que sempre verifico no lado do hosting:
- O cache de página completa está realmente funcionando? Verifique o header de resposta X-Cache. Se disser MISS em cada requisição, sua camada de cache não está funcionando. Check the
X-Cacheresponse header. If it saysMISSon every single request, your caching layer isn't functioning. - O servidor de origem está geograficamente perto da sua audiência principal? Parece óbvio. Você ficaria surpreso com a frequência que está errado. This sounds obvious. You'd be surprised how often it's wrong.
- Keep-alive está habilitado? Alguns hosts mais baratos ainda desabilitam conexões persistentes. Estranho em 2024, mas acontece. Some cheaper hosts still disable persistent connections. Wild in 2024, but it happens.
- HTTP/2 ou HTTP/3 estão ativos? Execute curl -I --http2 https://yourdomain.com e verifique o protocolo na resposta. Run
curl -I --http2 https://yourdomain.comand check the protocol in the response.
Não toque em otimização de imagens até ter resolvido TTFB. Otimizar imagens em um servidor lento é como pintar uma casa que está pegando fogo.
---
The LCP Image Problem (And Why `fetchpriority` Changes Everything)
Certo. Imagens. Em um site de listagens com layouts de grade de cards, o elemento LCP é quase sempre a primeira imagem do card acima da dobra — ou o banner hero. O navegador precisa descobri-la, buscá-la, decodificá-la e renderizá-la. Cada uma dessas etapas pode ser atrasada.
Aqui está o que realmente fizemos no projeto HostList, em ordem:
- Convertemos todas as imagens dos cards para WebP — usando a conversão em lote do Imagify. O tamanho médio do arquivo caiu 58% sem perda de qualidade visível nos tamanhos de miniatura de card que estávamos usando (280×180px de exibição, servido em 2x para retina). — using Imagify's bulk conversion. Average file size dropped 58% without visible quality loss at the card thumbnail sizes we were using (280×180px display, served at 2x for retina).
- Adicionamos `fetchpriority="high"` à primeira imagem do card — Essa única mudança removeu aproximadamente 200ms do LCP medido no WebPageTest. O navegador para de tratá-la como uma imagem lazy comum e a coloca imediatamente na fila do scanner de preload. — This one change alone knocked ~200ms off measured LCP in WebPageTest. The browser stops treating it like a regular lazy image and queues it immediately in the preload scanner.
- Removemos `loading="lazy"` das duas primeiras linhas de imagens dos cards — Lazy loading é brilhante para imagens abaixo da dobra. Na primeira linha visível, isso prejudica ativamente. Diz ao navegador para não buscar a imagem até que ela esteja perto do viewport — o que ela já está. — Lazy loading is brilliant for below-fold images. On the first visible row, it actively hurts you. It tells the browser to not fetch the image until it's near the viewport — which it already is.
- Adicionamos uma tag `<link rel="preload">` para a imagem hero no `<head>` especificamente no template da homepage. in the
<head>on the homepage template specifically.
Essa sequência levou o LCP da homepage de 3.1s para 1.4s em condições de lab. Os dados de campo seguiram em aproximadamente 28 dias (é mais ou menos quanto tempo leva para os dados do CrUX refletirem mudanças em escala).
Uma Nota sobre Imagens Responsivas
Se você estiver servindo a mesma imagem de 1400px de largura para um dispositivo móvel, você está queimando largura de banda e adicionando tempo de decodificação. Use srcset adequadamente. Eu sei que isso soa como uma conversa de 2016, mas ainda vejo isso em provavelmente 40% dos sites que passam pela Seahawk. A função WordPress wp_get_attachment_image() gera srcset automaticamente — mas apenas se a imagem foi carregada com resolução suficiente e o tema não a suprimiu com add_filter('max_srcset_width', ...).srcset properly. I know this sounds like a 2016 conversation but I still see it on probably 40% of the sites that come through Seahawk. The WordPress wp_get_attachment_image() function generates srcset automatically — but only if the image was uploaded at sufficient resolution and the theme hasn't suppressed it with add_filter('max_srcset_width', ...).
---
Scripts que Bloqueiam a Renderização: O Imposto do Site de Afiliados
Sites de comparação de hospedagem e plataformas de listagem vivem de receita de afiliados. Isso significa scripts de rastreamento de terceiros. Commission Junction, Impact, Awin, rastreadores de pixel customizados — eles se acumulam. Já contei 14 origens de scripts de terceiros separadas em um único site de listagem. Cada uma delas é uma busca DNS separada, uma conexão TCP e um handshake TLS antes de um único byte daquele script ser recebido.
A solução não é remover os scripts. Você não pode — a receita depende deles. A solução é sequenciar.
Nenhum script de terceiros deve bloquear a renderização inicial do elemento LCP. Ponto final.
Na prática, isso significa:
- Mova todos os scripts de afiliados/análise para carregar após o evento DOMContentLoaded, não na <head>.after the
DOMContentLoadedevent, not in<head>. - Use atributos async ou defer em todos os scripts que você controla.
asyncordeferattributes on every script you control. - Para scripts que você não controla (injetados por gerenciadores de tags), carregue o Google Tag Manager com defer — sim, isso é seguro para a maioria dos casos de rastreamento de afiliados, e a própria documentação do GTM reconhece essa abordagem.
defer— yes, this is safe for most affiliate tracking use cases, and GTM's own documentation acknowledges this approach. - Use um gerenciador de scripts como Asset CleanUp Pro ou o recurso de atraso de script do WP Rocket para adiar terceiros não essenciais até a interação do usuário (primeiro scroll ou primeiro clique).
Na reconstrução do HostList, adiar scripts de terceiros reduziu o Total Blocking Time de 1.840ms para 290ms. TBT não é uma Core Web Vital diretamente, mas se correlaciona fortemente com INP, que é.is.
---
Carregamento de Fontes: O Assassino Silencioso do LCP que Ninguém Comenta
Fontes customizadas causam um modo de falha específico. O navegador renderiza seu layout, atinge o elemento de texto do LCP (às vezes o LCP é um heading, não uma imagem), e então aguarda o arquivo de fonte antes de pintar. Isso é chamado Flash of Invisible Text, e atrasa o LCP em qualquer lugar de 200ms a mais de um segundo, dependendo do tamanho do arquivo de fonte e proximidade do servidor.
Duas coisas resolvem isto:
font-display: swap na sua declaração @font-face — o navegador renderiza em uma fonte fallback imediatamente e faz a troca quando a fonte customizada carrega. O candidato a LCP é pintado no tempo certo.in your@font-facedeclaration — the browser renders in a fallback font immediately and swaps when the custom font loads. LCP candidate gets painted on time.- Auto-hospede suas fontes. Google Fonts adiciona uma requisição cross-origin. Auto-hospedar com a ferramenta google-webfonts-helper permite servir fontes do seu próprio domínio, cortando essa conexão extra.google-webfonts-helper tool lets you serve fonts from your own domain, cutting that extra connection.
Converti um grande diretório de sites da Google Fonts em cerca de 45 minutos usando essa ferramenta. O LCP melhorou por 180ms. Não é transformador sozinho, mas combinado com tudo mais, essas margens se acumulam.
---
Medindo o Que Realmente Importa no Campo
Dados do CrUX são a verdade absoluta. Mas só atualiza mensalmente e apenas para URLs com tráfego suficiente. Para sites grandes com milhares de páginas, você precisa de algo mais granular.
Uso a API do PageSpeed Insights executada em uma amostra representativa de URLs — tipicamente as 100 páginas principais por tráfego, 50 páginas no nível de categorias e 20 páginas de catálogo "finas" em profundidade. Executar isso mensalmente fornece uma distribuição apropriada de performance, não um score de ponto único.PageSpeed Insights API scripted across a representative sample of URLs — typically the top 100 pages by traffic, 50 category-level pages, and 20 "thin" deep-catalogue pages. Running this monthly gives a proper performance distribution, not a single-point score.
No Lighthouse CI (que rodamos em pipelines de CI/CD para clientes que têm ciclos de desenvolvimento), validamos contra:
- LCP ≤ 2.5s em lab (target conservador, já que field tende a ficar 10–15% atrás de lab)
- TBT ≤ 300ms
- CLS ≤ 0.1
Mas, honestamente — para um build tipo HostList onde o objetivo é LCP inferior a 1.5s — targets de lab precisam ser mais rigorosos. Definimos LCP ≤ 1.8s no Lighthouse CI para esses projetos, que tipicamente produz 1.3–1.5s em dados de field uma vez que o CrUX se atualiza.
---
Juntando Tudo: O Resultado de HostList
Depois de passar por tudo o que foi mencionado acima — migração de hosting, caching de página completa, conversão de formato de imagem, fetchpriority em candidatos a LCP, remoção de lazy-load de linhas acima da fold, deferral de scripts e auto-hospedagem de fontes — aqui está como os números ficaram:fetchpriority on LCP candidates, lazy-load removal from above-fold rows, script deferral, and font self-hosting — here's what the numbers looked like:
- TTFB: 780ms → 160ms (mediana, visitantes do UK): 780ms → 160ms (median, UK visitors)
- LCP (lab, mobile): 4.2s → 1.4s: 4.2s → 1.4s
- LCP (field, CrUX, 75º percentil): 3.8s → 1.6s (medido 60 dias após migração): 3.8s → 1.6s (measured 60 days post-migration)
- TBT: 1.840ms → 290ms: 1,840ms → 290ms
- CLS: já estava bom em 0.03, sem alterações: was already fine at 0.03, unchanged
Nem todo site vai ganhar uma melhoria de 2.8 segundos. Mas praticamente todo grande site de listagem com o qual trabalhei teve todos esses problemas simultaneamente, o que significa que os ganhos se acumulam. Corrija uma coisa e você ganha 300ms. Corrija todas e você ganha 2.5 segundos.
---
FAQ
A hospedagem realmente importa tanto para LCP?
Sim — provavelmente mais do que qualquer outra coisa no início. Se seu TTFB está acima de 500ms, nenhuma quantidade de otimização de imagens vai te levar a um LCP "Bom". TTFB é a base sobre a qual tudo mais se apoia. Coloque-o abaixo de 200ms primeiro, depois se preocupe com o resto.
Devo usar um CDN em vez de migrar de hospedagem?
Um CDN ajuda com a entrega de assets estáticos e pode reduzir TTFB para HTML full-page em cache, se configurado corretamente. Mas muitas configurações de CDN só fazem cache de assets, não de respostas HTML completas. Verifique se o seu CDN está realmente servindo HTML em cache ou só offloadando imagens. Se for o último caso, um host origin melhor fará mais pela LCP.
`fetchpriority="high"` tem suporte amplo agora?
A partir de 2024, sim — tem suporte em Chrome, Edge e Safari (desde Safari 17.2). O suporte do Firefox chegou em Firefox 132. Para browsers que não suportam, é ignorado com segurança. Não há desvantagem em adicionar ao seu elemento LCP image.
Quanto tempo leva para os dados do CrUX refletirem melhorias?
Aproximadamente 28 dias a partir de quando usuários reais começam a experimentar a versão mais rápida do site. CrUX usa uma janela de 28 dias contínua. Então se você fizer deploy de mudanças hoje, sua pontuação de field data não vai refletir totalmente por cerca de um mês. Não entre em pânico se PageSpeed Insights ainda mostrar "Needs Improvement" no dia depois do seu sprint de otimização.
Qual é a mudança de maior impacto para um site de listagem?
Em quase todo projeto, foi TTFB. Mas o segundo maior impacto tem sido consistentemente remover loading="lazy" de card images above-fold e adicionar fetchpriority="high". Essas duas coisas juntas geralmente representam 40–60% da melhoria total de LCP. Tudo mais é ganho composto em cima dessa base.loading="lazy" from above-fold card images and adding fetchpriority="high". Together those two things usually account for 40–60% of the total LCP improvement. Everything else is compounding gains on top of that foundation.
---
Trabalho de performance em sites grandes é principalmente plumbing. Sem glamour, metódico, e profundamente satisfatório quando você puxa uma LCP de 4 segundos para 1,4 segundos e vê o tráfego orgânico aumentar dois meses depois. Não existe uma única configuração mágica — apenas uma sequência de decisões específicas tomadas na ordem correta.
Deixe o servidor rápido. Depois faça o elemento LCP ser descoberto e buscado cedo. Depois tire tudo mais do caminho dele.