Primeira pintura de conteúdo (FCP)
O que o First Contentful Paint mede, qual é uma boa pontuação de FCP, por que ele não é um Core Web Vital, como difere de First Paint e LCP e como corrigir um FCP lento.
Idiomas
First Contentful Paint (FCP) é o tempo desde o início do carregamento da página até o primeiro momento em que qualquer parte do conteúdo — texto, imagem, SVG ou canvas não branco — é renderizada. Bom é ≤1,8 s no percentil 75 de usuários reais. FCP NÃO é um Core Web Vital: os sinais de ranking são LCP, INP e CLS. FCP é uma métrica diagnóstica (de laboratório e de campo) e um componente do LCP — acontece no mesmo momento ou antes do LCP — portanto é principalmente útil para encontrar recursos que bloqueiam a renderização e TTFB lento. No Lighthouse 10 ele representa 10% da pontuação de Performance. Corrija-o eliminando CSS/JS que bloqueiam a renderização, reduzindo TTFB, colocando CSS crítico inline, usando font-display: swap e fazendo preconnect às origens necessárias.
TL;DR — First Contentful Paint (FCP) é o momento em que um visitante vê o primeiro pedaço da página — qualquer texto, imagem ou gráfico — em vez de uma tela branca. Quanto mais rápido, melhor; abaixo de 1,8 segundos é a marca de “bom”. É uma verificação útil de velocidade, mas não é uma das métricas que o Google usa para ranking.
O que é FCP de verdade
Quando alguém clica em um link para sua página, existe um breve intervalo em que a pessoa encara o vazio — uma tela branca — enquanto o navegador busca e processa sua página. First Contentful Paint é o instante em que essa tela branca se transforma em algo real: um título, um logotipo, uma foto, qualquer coisa que o visitante consiga ver.
Essa é a ideia toda. FCP responde a uma pergunta simples: “How long until the user sees the page is alive and doing something?” Tradução: “Quanto tempo até o usuário ver que a página está viva e fazendo alguma coisa?” Uma página que pinta conteúdo em meio segundo parece rápida. Uma página que fica em branco por três segundos parece quebrada — e as pessoas vão embora. Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paint
O que conta como “conteúdo”
O FCP dispara quando o navegador desenha qualquer um destes elementos na tela:
- Texto (um título, um parágrafo, um link de navegação)
- Imagens, incluindo imagens de fundo
- Gráficos
<svg> - Um elemento
<canvas>que não seja branco
Uma cor de fundo simples, sozinha, não conta — isso é outra coisa, anterior, chamada First Paint. FCP só conta quando aparece conteúdo real.
Qual é uma boa pontuação?
As faixas do Google, medidas em visitantes reais:
| Tempo de FCP | Avaliação |
|---|---|
| 1,8 segundos ou menos | Bom |
| 1,8 – 3,0 segundos | Precisa melhorar |
| Acima de 3,0 segundos | Ruim |
Você verá seu FCP em ferramentas como PageSpeed Insights e Lighthouse — os mesmos relatórios que mostram seus Core Web Vitals.
O FCP afeta meus rankings no Google?
Não — não diretamente. Esta é a parte que a maioria entende errado. As métricas que o Google realmente usa para ranking são os três Core Web Vitals: LCP, INP e CLS. FCP não é um deles.
Mas veja por que ainda vale acompanhá-lo: as coisas que tornam o FCP lento — um servidor vagaroso, folhas de estilo grandes e scripts que bloqueiam o desenho da página — geralmente são as mesmas coisas que prejudicam o Largest Contentful Paint (LCP), que é um sinal de ranking. Portanto, corrigir as causas-raiz do FCP frequentemente também ajuda o LCP — mas não é garantia, pois o LCP tem causas próprias (o tamanho e a prioridade de carregamento do seu elemento específico maior). Pense no FCP como um alarme de fumaça: vale verificar, mas não prova que o incêndio acabou.
As correções rápidas
Se seu FCP está lento, estes são os suspeitos de sempre (e o que fazer):
- Arquivos que bloqueiam a renderização. CSS e JavaScript no
<head>da página podem impedir o navegador de desenhar qualquer coisa até terminarem de carregar. Esta é a causa nº 1. - Um servidor lento. Se o servidor demora para responder (alto Time to First Byte), o navegador não pode pintar até os bytes chegarem.
- Fontes que escondem seu texto. Algumas configurações deixam o texto invisível por até três segundos enquanto uma fonte web carrega. Mudar a regra para
font-display: swapmostra o texto de fallback imediatamente.
Quer a versão técnica — a diferença entre laboratório e campo, a cadeia diagnóstica FCP/LCP e a lista completa de correções? Mude para a aba Avançado.
TL;DR — FCP é o tempo do início da navegação até o primeiro momento em que qualquer conteúdo da página (texto, imagem,
<svg>ou<canvas>não branco) é renderizado. Ele não é um Core Web Vital — é uma métrica diagnóstica suplementar, de laboratório e de campo, e um componente do LCP (o FCP acontece no mesmo momento ou antes do LCP). Limites de campo (p75): Bom ≤ 1,8 s, precisa melhorar ≤ 3,0 s, ruim > 3,0 s. No Lighthouse 10 ele representa 10% da pontuação de Performance. Como o relógio do FCP começa na navegação — incluindo tempo de redirecionamento, configuração da conexão e TTFB — os números de laboratório (Lighthouse) e campo (CrUX) frequentemente divergem. Corrija-o onde ele nasce: primeiro CSS/JS que bloqueiam a renderização, depois TTFB, depois fontes.
O que o FCP mede (com precisão)
A definição do Google, do artigo de Philip Walton no web.dev, é a coluna de precisão aqui: “First Contentful Paint (FCP) measures the time from when the user first navigated to
the page to when any part of the page’s content is rendered on the screen.” Tradução: “First Contentful Paint (FCP) mede o tempo desde a primeira navegação do usuário até o momento em que qualquer parte do conteúdo da página é renderizada na tela.” “Conteúdo”, segundo a mesma documentação, significa “text, images (including background images), <svg> elements,
or non-white <canvas> elements.” Tradução: “texto, imagens (incluindo imagens de fundo), elementos <svg> ou elementos <canvas> não brancos.”
A palavra que faz todo o trabalho é qualquer. O FCP não se importa com o que renderiza — um logotipo de 40 pixels conta tanto quanto uma imagem hero completa. É o sinal “já há alguma coisa na tela?”, exatamente por isso é um indicador inicial, não uma métrica de conclusão. Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paint
Um detalhe fácil de perder e que muda como você lê o número: o relógio do FCP começa na navegação, então inclui tudo que acontece antes de seu HTML sequer ser analisado. O Ponto-chave do próprio Google diz: “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” Tradução: “O FCP inclui qualquer tempo de descarregamento da página anterior, tempo de configuração da conexão, tempo de redirecionamento e Time To First Byte (TTFB), que pode ser significativo quando medido em campo.” Um servidor que leva 1,5 s para responder já consumiu a maior parte do seu orçamento de 1,8 s antes de o navegador processar um único byte.
FCP NÃO é um Core Web Vital
Vou ser direto, porque a maioria das páginas faz ressalvas: FCP não é um Core Web Vital e não faz parte dos sinais de ranking do Google. Os Core Web Vitals são LCP, INP e CLS — e FCP não é mencionado em nenhuma parte da página de Core Web Vitals de ranking da Pesquisa Google.
O que FCP é, na taxonomia do Google, é um “Other Web Vital” — uma métrica suplementar útil para diagnóstico. O web.dev coloca assim: “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” Tradução: “as métricas Time to First Byte (TTFB) e First Contentful Paint (FCP) são aspectos vitais da experiência de carregamento e ambas são úteis para diagnosticar problemas com LCP (tempos lentos de resposta do servidor ou recursos que bloqueiam a renderização, respectivamente).”
Portanto, o enquadramento honesto para as partes interessadas tem dois lados, e você deve declarar ambos sem hesitar:
- FCP não afeta rankings diretamente. Não otimize FCP “para SEO”.
- FCP é um ótimo diagnóstico para LCP, que afeta rankings. Recursos que bloqueiam a renderização aparecem primeiro no FCP.
FCP versus First Paint (FP)
Esses dois são confundidos o tempo todo:
- First Paint (FP) dispara quando o navegador pinta qualquer coisa — inclusive uma cor de fundo simples sem conteúdo real.
- FCP dispara apenas quando conteúdo elegível renderiza: texto, imagens (incluindo imagens de fundo), elementos
<svg>ou elementos<canvas>não brancos. Esta é uma lista específica, definida pela especificação — não uma regra vaga de “qualquer conteúdo do DOM” — e vale mantê-la precisa, pois uma imagem de fundo conta mesmo não sendo texto no DOM.
Portanto, FP ≤ FCP, sempre. Na maioria das páginas eles são quase idênticos, porque é raro pintar uma cor de fundo sem conteúdo por cima. Quando existe uma diferença significativa, geralmente significa que um fundo cosmético foi pintado antes de qualquer conteúdo real. A Paint Timing API retorna entradas first-paint e first-contentful-paint — mas FCP é o que vale analisar; FP raramente informa algo acionável.
FCP versus LCP
O outro par que as pessoas misturam:
- FCP = quando qualquer conteúdo é pintado. Dispara cedo. Pode ser um logotipo pequeno ou um link de navegação.
- LCP = quando o maior elemento na viewport é renderizado. Dispara no mesmo momento ou depois do FCP.
A formulação do Google: FCP mede quando qualquer conteúdo é pintado e LCP quando o conteúdo principal é pintado, então LCP pretende ser mais seletivo. Leia isso como “mais seletivo”, não como “certificado como correto” — nenhuma das métricas prova que o conteúdo principal real da página está completo ou é útil para o visitante. FCP apenas confirma que algo elegível foi pintado; LCP confirma que o maior candidato elegível foi pintado. Uma página pode ter FCP rápido (logotipo em 0,5 s) e LCP lento (imagem hero em 4 s) — essa diferença é um diagnóstico útil por si só. E, se seu FCP estiver próximo do LCP, isso costuma ser um bom sinal: significa que a primeira coisa pintada também é a maior, sem pintura inicial desperdiçada em elementos de interface que não importam para o usuário. Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)
Vale conhecer uma peculiaridade de medição: por causa de restrições de segurança na temporização de imagens de origem cruzada, a API do navegador pode em casos raros informar LCP antes de FCP. Isso é um artefato de medição, não algo que aconteceu fisicamente.
Limites — e por que laboratório e campo discordam
Limites de campo (CrUX, p75): Bom ≤ 1,8 s · precisa melhorar ≤ 3,0 s · ruim > 3,0 s. A orientação do Google é medir no percentil 75 dos carregamentos de página, separado entre dispositivos móveis e desktop. Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful Paint
Mas o Lighthouse desktop usa limites diferentes e mais rígidos — verde é aproximadamente 0–0,9 s, laranja 0,9–1,6 s, vermelho acima de 1,6 s — porque o laboratório executa um Chrome limpo e limitado em um dispositivo simulado, não em condições do mundo real. (Essas faixas, como os pesos da pontuação abaixo, são específicas da versão do Lighthouse — isto reflete a documentação de auditoria atual no momento da redação.) A pontuação FCP do Lighthouse é “a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” Tradução: “uma comparação do tempo de FCP da sua página com os tempos de FCP de sites reais, baseada em dados do HTTP Archive.”
Esta é a fonte mais comum de confusão sobre FCP, então memorize:
A linha de “bom” em 1,8 s é o limite de campo (CrUX p75). A linha “verde” do Lighthouse desktop é ~0,9 s. São escalas diferentes para trabalhos diferentes.
Os números de campo e de laboratório divergem principalmente porque amostram populações diferentes, não porque um seja universalmente “mais verdadeiro”. O Lighthouse executa uma sessão limpa em condições fixas de dispositivo e rede. Campo/CrUX agrega dispositivos reais, redes reais, estados de cache e tipos de navegação — incluindo restaurações do cache de voltar/avançar e páginas pré-renderizadas, que não recebem automaticamente um FCP novo como uma navegação normal; precisam de seu próprio tratamento de ciclo de vida (a biblioteca web-vitals faz isso por você). Na maioria dos sites, o número de campo é maior — usuários reais carregam cadeias de redirecionamento, tempo de descarregamento da página anterior e conexões frias que o laboratório evita — mas isso é uma tendência, não uma regra. Antes de ler uma diferença de laboratório/campo como problema, confirme que está comparando coisas equivalentes (mesma classe de dispositivo, mesmas condições de rede). Use dados de campo para o número do mundo real e o Lighthouse para o diagnóstico.
Onde o FCP fica na pontuação do Lighthouse
No Lighthouse 10 — a versão atual no momento da redação, não uma cifra permanente — FCP representa 10% da pontuação de Performance. A ponderação completa:
| Métrica | Peso |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
A pontuação de Performance é uma média ponderada das pontuações individuais das métricas, e o Google observa que os pesos mudam com o tempo à medida que sua pesquisa evolui — FCP permaneceu em 10% do Lighthouse 8 ao 10, mas confirme na versão que você estiver executando antes de tratar “10%” como algo eterno. A leitura prática: um FCP perfeito só consegue mover sua pontuação do Lighthouse até certo ponto — e um FCP ruim frequentemente aponta para um LCP ruim também (eles compartilham causas-raiz), embora isso seja uma sobreposição a verificar, não algo garantido pela pontuação.
O que causa um FCP lento
Em ordem aproximada de prioridade:
- Recursos que bloqueiam a renderização — o maior causador. CSS e JS síncrono no
<head>obrigam o navegador a esperar: ele não consegue construir o CSSOM e a árvore de renderização, então não consegue pintar nada até esses arquivos serem baixados e analisados. - TTFB alto — FCP não pode disparar antes de os bytes chegarem. Um servidor lento é o primeiro dominó, e está dentro da medição do FCP.
- Cadeias de redirecionamento — cada redirecionamento é uma viagem de ida e volta completa adicionada antes do primeiro byte.
- Estratégia de carregamento de webfonts —
font-display: block(ou nenhuma regra) pode deixar o texto invisível por até ~3 segundos. Mesmo que a pintura dispare tecnicamente sobre um fundo, o usuário não vê nada útil.
Como corrigir
A lista completa, mas com uma ordem de prioridade que a documentação não fornece. Estas são alavancas comuns, não universais — verifique primeiro seu trace ou filmstrip para descobrir qual recurso ou fase realmente está atrasando seu candidato de FCP antes de buscar correções (preconnect, preload ou mudança de font-display) que podem não se aplicar à sua página:
Faça isto primeiro (maiores ganhos):
- Elimine CSS e JavaScript que bloqueiam a renderização. Coloque o CSS crítico acima da dobra diretamente no
<head>; carregue o restante de forma assíncrona; adicioneasync/defera scripts não críticos. Reposicionar uma tag<link>não ajuda — o navegador não pintará até todo o CSS ser carregado e analisado, independentemente de onde a tag estiver. - Reduza o TTFB (tempo de resposta do servidor). Cache, CDN, uma origem mais rápida — qualquer coisa que entregue o primeiro byte antes reduz diretamente o FCP.
- Corrija o carregamento de fontes. Use
font-display: swap(mostra o texto de fallback imediatamente e troca pela fonte web quando pronta) oufont-display: optional(pula a fonte web se ela ainda não estiver em cache). Evitefont-display: blockpara texto crítico — é o pior para FCP.
Depois organize o restante:
- Faça preconnect às origens necessárias com
<link rel="preconnect">— estabelecer conexões antecipadas com origens importantes de terceiros pode economizar 100–500 ms. - Faça preload de solicitações importantes (
<link rel="preload">) para uma fonte crítica ou a imagem LCP. - Minifique CSS, remova CSS não utilizado e remova JavaScript não utilizado — arquivos menores são analisados e liberam a pintura mais rapidamente.
- Evite vários redirecionamentos, payloads de rede enormes, sirva assets estáticos com uma política de cache eficiente, evite um DOM excessivamente grande e minimize a profundidade das solicitações críticas. Higiene geral de payload que alimenta toda primeira pintura.
A cadeia diagnóstica FCP → TTFB → LCP
É assim que eu realmente usaria FCP, e é o enquadramento que a documentação sugere sem desenvolver. Trate as três métricas de carregamento como um único fluxo de trabalho:
- FCP alto → verifique recursos que bloqueiam a renderização (CSS/JS no
<head>). É a causa mais comum e o ganho mais rápido. - Verifique também o TTFB — como FCP o inclui, um servidor lento infla o FCP antes mesmo de qualquer bloqueio de renderização entrar em cena. A orientação do web.dev: como TTFB precede FCP e LCP, seu servidor deve responder rápido o bastante para que o percentil 75 dos usuários atinja um FCP “bom”.
- Esses mesmos problemas frequentemente se propagam para o LCP — a métrica que de fato é sinal de ranking — porque FCP e LCP compartilham causas-raiz com frequência. É uma sobreposição a verificar, não uma garantia: o LCP tem fatores próprios (tamanho, prioridade e caminho de carregamento do seu maior elemento específico), então corrigir as causas do FCP não promete corrigir o LCP. É o lugar certo para começar, não o último passo.
Esse é o valor do FCP para um profissional de SEO: uma leitura barata e antecipada sobre a saúde do caminho de carregamento, antes de a medição mais seletiva do LCP sequer terminar.
Resumo de IA
Uma versão condensada da versão Avançada:
- FCP = tempo do início da navegação até o primeiro render de qualquer conteúdo — texto, imagens (incluindo fundo),
<svg>ou<canvas>não branco. É o sinal “já existe algo na tela?”. - FCP NÃO é um Core Web Vital. Os sinais de ranking são LCP, INP e CLS. FCP é uma métrica diagnóstica suplementar, de laboratório e de campo — não um fator de ranking direto.
- É um componente do LCP (FCP acontece no mesmo momento ou antes do LCP), então frequentemente captura os mesmos recursos que bloqueiam a renderização e o TTFB lento que prejudicam LCP — e LCP afeta rankings — mas corrigir as causas do FCP não garante que o LCP esteja corrigido; o LCP tem fatores próprios.
- Limites de campo (CrUX p75): Bom ≤ 1,8 s · precisa melhorar ≤ 3,0 s · ruim > 3,0 s.
- Laboratório ≠ campo, e “campo é sempre maior” é uma tendência, não uma regra. A linha “verde” de ~0,9 s do Lighthouse desktop é mais rígida que o limite de campo de 1,8 s porque é uma execução limpa em condições fixas; campo/CrUX agrega dispositivos reais, redes, estados de cache e tipos de navegação (incluindo restaurações do bfcache e páginas pré-renderizadas). Combine as populações antes de ler uma diferença como problema — use campo para o mundo real e laboratório para diagnóstico.
- FCP versus FP: First Paint dispara em qualquer pintura (até uma cor de fundo); FCP precisa de conteúdo elegível (texto, imagens incluindo fundo, SVG, canvas não branco). FP ≤ FCP sempre.
- FCP versus LCP: FCP = qualquer conteúdo elegível; LCP = o maior candidato elegível. Nenhum prova que o conteúdo principal real da página está completo ou é útil — são proxies. FCP rápido + LCP lento é uma diferença real e comum.
- Peso do Lighthouse 10 (atual no momento da redação): 10% — TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%; os pesos mudam entre versões do Lighthouse.
- Principais correções, em ordem: elimine CSS/JS que bloqueiam a renderização → reduza TTFB → corrija fontes (
font-display: swap/optional) → preconnect/preload → minificação/cache/higiene do DOM.
Documentação oficial
Documentação de fonte primária sobre FCP do Google.
web.dev (Google)
- First Contentful Paint (FCP) — definição canônica de Philip Walton, a lista do que conta como conteúdo, o limite de 1,8 s, o Ponto-chave sobre TTFB/redirecionamentos e como medir FCP com a Paint Timing API e a biblioteca web-vitals.
- Web Vitals — onde FCP se encaixa: um “Other Web Vital”, suplementar aos Core Web Vitals (LCP, INP, CLS), útil para diagnosticar LCP.
- Largest Contentful Paint (LCP) — a distinção FCP versus LCP e a relação entre os dois.
- Time to First Byte (TTFB) — por que TTFB precede (e está incluído no) FCP.
- User-centric performance metrics — a classificação do FCP como métrica de laboratório e de campo.
Lighthouse / Chrome Developers
- First Contentful Paint audit — as faixas de avaliação do Lighthouse desktop (verde ≤ 0,9 s) e como a pontuação FCP é calculada em comparação com dados do HTTP Archive.
- Lighthouse performance scoring — os pesos das métricas, incluindo FCP em 10% da pontuação de Performance no Lighthouse 10.
Google Search Central
- Core Web Vitals & Google Search — a página de ranking; lista LCP, INP e CLS. FCP não está nela, e esse é o ponto.
Citações da fonte
Declarações registradas da documentação do Google. Cada link é um link profundo que salta para a passagem citada na página de origem.
web.dev — a definição
- “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” Tradução: “First Contentful Paint (FCP) mede o tempo desde a primeira navegação do usuário até o momento em que qualquer parte do conteúdo da página é renderizada na tela.” — Philip Walton, First Contentful Paint (FCP), web.dev (atualizado em 6 de dezembro de 2023). Ir para a citação
web.dev — o limite
- “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” Tradução: “os sites devem buscar ter um First Contentful Paint de 1,8 segundos ou menos.” — mesma fonte. Ir para a citação
web.dev — o que o FCP inclui (o Ponto-chave)
- “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” Tradução: “O FCP inclui qualquer tempo de descarregamento da página anterior, tempo de configuração da conexão, tempo de redirecionamento e Time To First Byte (TTFB), que pode ser significativo quando medido em campo.” — mesma fonte.
web.dev — o papel do FCP em relação aos Core Web Vitals
- “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” Tradução: “as métricas Time to First Byte (TTFB) e First Contentful Paint (FCP) são aspectos vitais da experiência de carregamento e ambas são úteis para diagnosticar problemas com LCP (tempos lentos de resposta do servidor ou recursos que bloqueiam a renderização, respectivamente).” — Web Vitals, web.dev. Ir para a citação
Lighthouse — como a pontuação FCP é calculada
- “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” Tradução: “Sua pontuação FCP é uma comparação entre o tempo de FCP da sua página e os tempos de FCP de sites reais, baseada em dados do HTTP Archive.” — First Contentful Paint audit, developer.chrome.com.
Lighthouse — como funciona a pontuação de Performance
- “The Performance score is a weighted average of the metric scores.” Tradução: “A pontuação de Performance é uma média ponderada das pontuações das métricas.”
- “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” Tradução: “Os pesos mudaram ao longo do tempo porque a equipe do Lighthouse pesquisa e coleta feedback regularmente para entender o que tem o maior impacto no desempenho percebido pelo usuário.” — Lighthouse performance scoring, developer.chrome.com.
#:~:text= profundo; confirme-as nas páginas ativas antes de tratar qualquer citação como final. Os pesos são citados para o Lighthouse 10 — verifique novamente se uma versão mais nova do Lighthouse tiver sido lançada. Checklist de triagem de FCP lento
Quando o FCP está alto, percorra esta lista em ordem — aproximadamente do maior ganho para o menor:
- Verifique o número de campo, não apenas o Lighthouse. Leia o p75 do CrUX/PageSpeed Insights para o FCP real; use o Lighthouse apenas para diagnosticar.
- Procure recursos que bloqueiam a renderização. CSS e JS síncrono no
<head>são a causa nº 1 — a auditoria “Eliminar recursos que bloqueiam a renderização” do Lighthouse os lista. - Coloque CSS crítico acima da dobra inline; carregue o restante de forma assíncrona.
- Adicione
async/defera scripts não críticos; mova tags de terceiros para depois da primeira pintura. - Meça o TTFB. Ele está dentro do FCP — um servidor lento infla o FCP antes de qualquer outra coisa. Adicione cache / CDN / uma origem mais rápida.
- Elimine cadeias de redirecionamento — cada salto é uma viagem completa antes do primeiro byte.
- Corrija fontes: use
font-display: swapouoptional; nuncablockpara texto crítico. Faça preload do arquivo de fonte crítica. - Faça preconnect às origens de terceiros necessárias; preload da imagem LCP / solicitações importantes.
- Enxugue o payload: minifique CSS, remova CSS/JS não utilizados, use política de cache eficiente, DOM menor e menor profundidade de solicitações críticas.
- Verifique o LCP novamente depois — as mesmas correções deveriam tê-lo movido, e LCP é o que afeta rankings.
Cheat sheet do FCP
Limites de campo (CrUX, percentil 75)
| Tempo de FCP | Avaliação |
|---|---|
| ≤ 1,8 s | Bom |
| 1,8 – 3,0 s | Precisa melhorar |
| > 3,0 s | Ruim |
Avaliação do Lighthouse desktop (laboratório — observe: mais rígida que a de campo)
| Tempo de FCP | Cor |
|---|---|
| 0 – 0,9 s | Verde (rápido) |
| 0,9 – 1,6 s | Laranja (moderado) |
| Acima de 1,6 s | Vermelho (lento) |
Pesos da pontuação de Performance do Lighthouse 10 (atuais no momento da redação — os pesos mudam entre versões do Lighthouse)
| Métrica | Peso |
|---|---|
| Total Blocking Time | 30% |
| Largest Contentful Paint | 25% |
| Cumulative Layout Shift | 25% |
| First Contentful Paint | 10% |
| Speed Index | 10% |
As três métricas de carregamento, sem confusão
| Métrica | Dispara quando… | Core Web Vital? |
|---|---|---|
| First Paint (FP) | o navegador pinta qualquer coisa, até uma cor de fundo | Não |
| First Contentful Paint (FCP) | qualquer conteúdo real é pintado (texto/imagem/SVG/canvas) | Não (diagnóstica) |
| Largest Contentful Paint (LCP) | o maior elemento da viewport é renderizado | Sim |
Ordem dos eventos: FP ≤ FCP ≤ LCP.
O que conta como “conteúdo” para FCP
texto · imagens (incluindo imagens de fundo) · elementos <svg> · elementos <canvas> não brancos
Fatos rápidos
- O relógio do FCP começa na navegação — ele inclui tempo de redirecionamento, configuração da conexão e TTFB.
- FCP pode ser medido tanto em laboratório quanto em campo.
font-display: useswap/optional; eviteblock(texto invisível por até ~3 s).- Preconnect a origens de terceiros pode economizar 100–500 ms.
Ferramentas para medir FCP
Dados de campo (usuários reais)
- PageSpeed Insights — mostra o FCP p75 do CrUX da sua URL (campo) ao lado de uma execução do Lighthouse (laboratório).
- Chrome User Experience Report (CrUX) — o conjunto de dados de usuários reais por trás dos números de campo, via API ou BigQuery.
- Biblioteca JavaScript web-vitals — use
onFCP(console.log)(ou envie para seu analytics) para capturar FCP dos próprios visitantes; ela trata bfcache e casos de abas em segundo plano.
Dados de laboratório (simulados)
- Lighthouse — no Chrome DevTools, PageSpeed Insights ou CLI. Use-o para diagnosticar FCP (a auditoria “Eliminar recursos que bloqueiam a renderização” é a principal).
- Painel Performance do Chrome DevTools — veja exatamente quando First Paint e First Contentful Paint disparam em um carregamento gravado.
Meça você mesmo com a Paint Timing API
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});Ou use a biblioteca web-vitals (recomendado)
import {onFCP} from 'web-vitals';
onFCP(console.log);Algumas ressalvas que a API bruta não trata, mas a biblioteca web-vitals trata: ela ignora FCP disparado para abas em segundo plano, continua informando FCP quando uma página é restaurada do cache de voltar/avançar (um evento de navegação novo não dispara automaticamente numa restauração do bfcache, então é preciso tratá-la explicitamente) e usa activationStart em vez do início da navegação como origem do relógio para páginas pré-renderizadas. A temporização da pintura em iframe de origem cruzada continua sendo uma lacuna conhecida — uma página cujo conteúdo principal renderiza dentro de um pode mostrar um FCP enganosamente rápido.
Erros de FCP que escondem o gargalo real
- Tratar FCP como Core Web Vital. FCP é um diagnóstico útil, mas LCP, INP e CLS são os Core Web Vitals usados nos sistemas de ranking do Google. Use FCP para investigar a fase de tela branca, não como substituto dos dados de CWV de campo.
- Otimizar um logotipo minúsculo porque ele vira a primeira pintura. Uma pintura mais cedo, mas sem significado, pode melhorar FCP enquanto o conteúdo útil chega tarde. Verifique LCP e o filmstrip junto com FCP para que a mudança melhore o que o visitante realmente vê.
- Começar pela compressão de imagens quando a página está em branco. Se nada pode pintar, os bloqueadores habituais são tempo de resposta do servidor, CSS que bloqueia a renderização, JavaScript síncrono ou fontes. Siga o waterfall de solicitações antes de mudar assets não relacionados.
- Comparar execuções não relacionadas do Lighthouse. Emulação de dispositivo, condições de rede, estado do cache e variação entre execuções movem um FCP de laboratório. Compare execuções repetidas com as mesmas configurações e confirme o resultado com dados de campo quando disponíveis.
O orçamento de tela branca
Divida o FCP em três perguntas consecutivas em vez de tratar o número final como um único problema:
- Quanto tempo até o HTML chegar? Inspecione o TTFB. Uma resposta lenta significa que o navegador não pode começar trabalho útil, então comece pelo servidor, cache, redirecionamentos ou configuração da conexão.
- Quanto tempo até o navegador poder renderizar? Inspecione folhas de estilo que bloqueiam a renderização, scripts síncronos e comportamento das fontes. O HTML pode estar presente enquanto a thread principal ou o caminho de renderização ainda está bloqueado.
- O que realmente vira o primeiro conteúdo? Use um filmstrip ou trace para confirmar que a primeira pintura é texto ou imagem significativo, não um elemento simbólico que melhora a métrica sem melhorar a experiência.
O modelo mantém as correções em ordem: entrega primeiro, renderização em segundo, utilidade em terceiro. Execute novamente o mesmo perfil de laboratório após cada mudança para saber qual fase se moveu.
Teste seus conhecimentos: First Contentful Paint
Cinco perguntas rápidas sobre o que FCP mede e como diagnosticá-lo. Escolha uma resposta para cada uma e depois confira.
Recursos que valem seu tempo
Google / web.dev
- First Contentful Paint (FCP) — a referência canônica: definição, limites, código de medição e a lista completa de otimização.
- Web Vitals — como FCP se relaciona aos Core Web Vitals e por que é uma métrica diagnóstica.
- Largest Contentful Paint (LCP) — a métrica que FCP ajuda a diagnosticar e que é um Core Web Vital.
- Time to First Byte (TTFB) — a métrica de resposta do servidor que vive dentro do FCP.
Lighthouse
- First Contentful Paint audit — faixas de avaliação desktop e como a pontuação é calculada.
- Lighthouse performance scoring — os pesos das métricas, com FCP em 10%.
Meus textos relacionados
- The Beginner’s Guide to Technical SEO — onde a velocidade de página se encaixa no quadro maior.
- Core Web Vitals: What They Are & How to Improve Them — as métricas de sinal de ranking nas quais FCP contribui.
De outras fontes do setor
- First Contentful Paint (FCP) — artigo canônico de Philip Walton no Google: definição, limites, código da Paint Timing API e lista completa de otimização.
- Web Vitals — estrutura do Google que explica onde FCP fica (um “Other Web Vital”, suplementar aos Core Web Vitals) e seu papel no diagnóstico de LCP.
- First Contentful Paint audit — documentação do Chrome Developers sobre faixas de avaliação desktop do Lighthouse e como a pontuação FCP é calculada com dados do HTTP Archive.
- Time to First Byte (TTFB) — guia do Google sobre por que TTFB precede e está incluído no FCP e como um servidor lento consome o orçamento de FCP antes de o navegador pintar um único pixel.
- Eliminate render-blocking resources — guia do Chrome Developers sobre o maior causador de FCP: CSS e JS síncrono no <head> que impedem o navegador de pintar.
- Ensure text remains visible during webfont load — auditoria do Chrome Developers que explica valores de font-display e por que
blockatrasa FCP enquantoswapouoptionalmantém o texto visível. - First Contentful Paint — guia prático de FCP da NitroPack com dicas de otimização específicas de CMS e uma explicação clara de campo versus laboratório.
Estatísticas que valem citar
- FCP bom = ≤ 1,8 s no percentil 75 dos usuários reais; precisa melhorar até 3,0 s; ruim acima disso (limites de campo/CrUX). Fonte
- Lighthouse desktop é mais rígido: ~0–0,9 s é “verde”, porque o laboratório executa em um ambiente simulado e limitado, em vez de condições reais. Fonte
- FCP representa 10% da pontuação de Performance do Lighthouse 10 (atual no momento da redação — os pesos mudam entre versões) — junto a TBT 30%, LCP 25%, CLS 25% e Speed Index 10%. Fonte
- Preconnect a origens de terceiros pode economizar 100–500 ms de carregamento ao estabelecer conexões antecipadas. Fonte
Registro de alterações
Atualizado em 17 de jul. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.