Guias

Cada métrica de desempenho responde a uma pergunta, e vale o que vale essa pergunta. O First Contentful Paint coloca uma que todo o visitante faz sem pensar: há quanto tempo estou a olhar para o nada? Não quanto falta para a página ser utilizável, nem quanto falta para chegar a imagem grande, apenas quanto falta para aparecer o que quer que seja.

Isso faz do FCP o primeiro sinal honesto que uma página consegue dar. Também não é um Core Web Vital, por razões que vale a pena perceber, e isso muda o peso que merece nas suas prioridades.

O que o FCP mede realmente

O FCP mede o tempo entre o início da navegação para a página e o momento em que alguma parte do conteúdo é desenhada no ecrã. Conteúdo tem aqui uma definição precisa e não intuitiva: texto, imagens incluindo as de fundo, elementos SVG e elementos canvas que não estejam num branco vazio.

A distinção que importa é entre First Paint e First Contentful Paint. O First Paint dispara assim que o browser muda um pixel, o que inclui pintar uma cor de fundo por cima da página anterior. Nesse instante nada foi comunicado. O FCP espera por algo que uma pessoa possa mesmo ler ou olhar.

Como o FCP é o primeiro conteúdo, é por definição anterior ou igual ao Largest Contentful Paint. Numa página cujo maior elemento é também o primeiro, ambos valem o mesmo número. Numa página que mostra um título de imediato e uma imagem de cabeçalho três segundos depois, estão muito afastados, e esse intervalo é a parte interessante da leitura.

Os limiares, e o Core Web Vital que não é

A Google publica três faixas para o FCP, medidas no percentil 75 dos carregamentos de página e separadas por dispositivo: bom com 1,8 segundos ou menos, a melhorar entre 1,8 e 3 segundos, e mau acima de 3 segundos. Telemóvel e computador são pontuados em separado, o que conta porque o mesmo site cai regularmente em faixas diferentes em cada um.

• Total Blocking Time - 30 %
• Largest Contentful Paint - 25 %
• Cumulative Layout Shift - 25 %
• First Contentful Paint - 10 %
• Speed Index - 10 %

O FCP não é um Core Web Vital. Os Core Web Vitals são o LCP, o INP e o CLS, e são esses três que alimentam os sinais de experiência de página da Google. O FCP fica ao lado como métrica de diagnóstico: reportado pelo PageSpeed Insights e pelo Chrome User Experience Report, ponderado na pontuação de desempenho do Lighthouse, mas sem fazer parte do conjunto que toca o posicionamento.

Não é motivo para o ignorar. É motivo para o usar naquilo em que é bom, que é dizer-lhe se o seu problema começa antes da renderização ou durante ela. Na pontuação de desempenho do Lighthouse 10 os pesos distribuem-se assim:

O que realmente o atrasa

O primeiro componente do FCP é o tempo até ao primeiro byte. Nada pode ser pintado antes de chegar o primeiro byte de HTML, por isso um servidor lento, uma consulta lenta ou uma origem distante colocam sob o FCP um chão que nenhum trabalho de front-end levantará. Se o TTFB for de 1,5 segundos, um FCP abaixo de 1,8 é quase impossível.

O segundo são os recursos que bloqueiam a renderização. Uma folha de estilos no head tem de ser descarregada e analisada antes de o browser pintar, porque pintar com os estilos errados e voltar a pintar é pior do que esperar. Os scripts síncronos no head bloqueiam a análise por completo. Cada um é uma ida e volta serializada inserida entre a chegada do HTML e o aparecimento de seja o que for.

O terceiro são as fontes web, e é o que se esquece. Uma fonte declarada com font-display: block dá ao browser um período durante o qual o texto nessa fonte é desenhado invisível enquanto o ficheiro descarrega. Texto invisível não é conteúdo, por isso o FCP espera por ele. Passar a font-display: swap pinta de imediato uma fonte de recurso e troca pela verdadeira quando chega, trocando um refluxo visível por um primeiro aparecimento de palavras mais cedo.

Medi-lo por si próprio

No terreno, o FCP vem do Chrome User Experience Report, que é o que o PageSpeed Insights mostra na secção de cima para utilizadores reais em ligações reais. É esse o número em que confiar, porque reflete os aparelhos e as redes que os seus visitantes têm mesmo e não a máquina em que está a testar.

No browser, um PerformanceObserver a ouvir o tipo de entrada paint reporta tanto first-paint como first-contentful-paint. Ler os dois é mais útil do que ler um só. Um intervalo grande entre eles significa que o browser tinha pixels para empurrar e escolheu primeiro uma cor de fundo, que é a assinatura de uma folha de estilos ou de uma fonte a interpor-se entre o seu HTML e o seu leitor.

FCP ou LCP: qual corrigir primeiro

Se o FCP e o LCP estiverem ambos maus, corrija a causa comum e ambos se mexem. O TTFB, o CSS bloqueante e as fontes bloqueantes estão a montante das duas métricas, por isso o trabalho gasto aí nunca se perde. Se o FCP estiver bom e o LCP mau, o problema é próprio do seu maior elemento, normalmente uma imagem de cabeçalho não otimizada ou descoberta demasiado tarde pelo preload scanner.

O padrão que convém reconhecer é o inverso: um FCP mau com um LCP aceitável. Quer dizer que o browser esteve parado antes de pintar o que quer que fosse e depois recuperou depressa, o que é quase sempre um recurso bloqueante no head e não um problema de peso. É também a mais barata de corrigir das três situações.