First Contentful Paint

O que é o First Contentful Paint (FCP)?

O First Contentful Paint (FCP) é uma forma de medir a velocidade de carregamento da página. Não é possível resumir a velocidade da página como um ponto no tempo; na verdade, existem vários momentos durante o processo de carregamento em que um visitante pode perceber o site como carregando rapidamente ou lentamente. O FCP mede a diferença de tempo entre a solicitação da página e o momento em que o primeiro conteúdo significativo é renderizado na tela pela primeira vez.

O que exatamente isso lhe diz? Isso indica que o FCP é principalmente uma "métrica centrada no usuário" porque diz algo sobre a velocidade de carregamento que um visitante experimenta. Diz algo sobre a user experience. No momento do FCP, você pode ter certeza de que o visitante realmente vê "algo" na tela.

Vamos decompor as palavras: 'First','Contentful' e 'Paint'.

1. First:  Por First, é claro, nos referimos ao primeiro momento exato em que algo substancial aparece no seu navegador.
2. Contentful: Com contentful nos referimos a um elemento HTML com conteúdo. Então não um elemento de layout como um elemento em branco ou cor de fundo, mas sim algum texto, uma imagem (incluindo imagem de fundo), SVG ou canvas.
   
3. Paint: Paint significa (mais ou menos) que o navegador está pronto para colocar algo na tela. Isso parece simples, mas na verdade é a tarefa mais complicada do navegador. Para colocar algo na tela, um navegador precisa estar pronto para calcular todas as características de um elemento. Abaixo está um exemplo do processo de renderização necessário antes que qualquer coisa possa ser adicionada na tela.

Qual é uma boa pontuação de First Contentful Paint?

Uma pontuação FCP boa é qualquer valor abaixo de 0 e 1,8 segundos. Se a sua pontuação FCP estiver entre 1,8 e 3 segundos, ela precisa de melhoria. Qualquer pontuação FCP acima de 3 segundos é considerada fraca. Para passar nos Core Web Vitals para o Largest Contentful Paint, pelo menos 75% dos seus visitantes precisam ter uma pontuação FCP 'boa'.

Como sempre com os Core Web Vitals, uma pontuação mais rápida de First Contentful Paint é melhor do que uma maior. 

Como você mede o seu First Contentful Paint (FCP)?

O FCP é medido pelo Google através da coleta de dados de usuários reais. Esses dados são armazenados no dataset CrUX. Esses dados estão disponíveis publicamente através da CrUX API ou Google BigQuery. O FCP também pode ser medido através dos chamados testes de laboratório. O teste de laboratório mais comum é chamado Lighthouse.

Obtendo o First Contentful Paint do dataset CrUX

O First Contentful Paint pode ser lido do dataset CrUX através do pagespeed.web.dev, da CrUX API ou do Google BigQuery.

Medindo o First Contentful Paint através de Real User Monitoring (RUM) 

RUM Tracking significa Real User Monitoring. Com Real User Monitoring, você pode rastrear o First Contentful Paint através de interações reais de usuários. A vantagem do RUM Tracking é que você não precisa esperar 28 dias por dados atualizados e os dados podem ser consultados e analisados com muito mais detalhes.

Medindo o FCP no Lighthouse

1. Abra a página – no Chrome – cujo FCP você deseja medir. Certifique-se de fazer isso em modo anônimo para que os plugins não interfiram e possivelmente diminuam o FCP da sua página.
2. Clique com o botão direito na página e selecione Inspecionar Elemento. Desta forma, você abre o console de desenvolvedor do Chrome.
3. No topo do console, você verá a aba Lighthouse. Clique nela. Depois em Categorias, escolha Performance (deixe as outras em branco) e escolha Mobile em Dispositivo.
4. Agora clique em Gerar Relatório. O Lighthouse criará um relatório de velocidade da sua página. No canto superior esquerdo do relatório, você verá qual é o FCP da sua página.

Esta é uma captura de tela do relatório Lighthouse para esta página. O FCP desta página em um dispositivo móvel é de 0,8 segundos! Nada mal, não é?

Medindo o FCP com uma ferramenta online

Você também pode medir o FCP com várias ferramentas online. As mais conhecidas são o GTMetrix, pingdom e o pagespeed.web.dev. Essas ferramentas são fáceis de usar e fornecem alguns dados sobre o LCP em circunstâncias específicas de laboratório.

Melhorando o First Contentful Paint

Agora que você sabe o que é o First Contentful Paint, podemos trabalhar para torná-lo mais rápido. A ideia por trás de um FCP rápido é na verdade bastante simples: garantir que o navegador possa começar a renderizar imediatamente. Qualquer coisa que possa causar atraso na renderização resultará em uma pontuação FCP fraca.

Assim como com o Largest Contentful Paint, o First Contentful Paint pode ser dividido em 2 ou 4 categorias:

1. Time to First Byte (TTFB) - O tempo desde quando começa a carregar a página até quando o navegador recebe o primeiro byte do HTML. 
2. Atraso no carregamento do recurso - O tempo entre o TTFB e quando o navegador começa a carregar o recurso do FCP
   
3. Tempo de carregamento do recurso - O tempo que leva para carregar o próprio recurso do FCP.
   
4. Atraso na renderização do elemento - O tempo entre quando o recurso do FCP terminou de carregar até o elemento LCP ser completamente renderizado
   

Dica de velocidade: Você pode facilmente eliminar os passos 2 e 3 garantindo que o elemento LCP não requeira um recurso de rede. No caso de um elemento de texto, considere usar font-display:swap. No caso de um elemento de imagem pequeno, considere colocar a imagem inline.

Isso nos deixa apenas com o Time to First Byte e o atraso na renderização do elemento para otimizar.

Abaixo estão 14 soluções que frequentemente uso para melhorar o FCP. Mas tenha cuidado, usar uma solução no lugar errado pode na verdade criar atrasos. Por isso é melhor consultar um especialista em pagespeed antes de começar por conta própria.

1. Resposta rápida do servidor (TTFB)

O TTFB (o tempo entre a solicitação e o primeiro byte que o servidor envia) é sempre o primeiro passo no processo de renderização. A partir desse ponto, seu navegador começa a fazer multitarefa e o impacto de otimizações adicionais começa a diminuir. O código HTML é a única solicitação que afeta diretamente todas as métricas de velocidade.

A velocidade com que o código HTML é enviado do servidor é frequentemente medida como o Time to First Byte (TTFB). É importante tornar isso o mais rápido possível. Frequentemente, você faz isso habilitando o cache do lado do servidor.

Quando se trata de Time to First Byte, menor é sempre melhor. 

Você pode medir facilmente o Time to First Byte por conta própria. É feito da seguinte forma:

1. Use o atalho Ctrl-Shift-I para abrir o console de desenvolvedor do Google Chrome.
   
2. No topo do console, você verá uma aba Network. Clique nela.
3. Recarregue a página através de Ctrl-R.
   
4. Agora você verá todas as solicitações de rede que o Chrome enviou ao seu servidor.
5. Clique na solicitação de rede do topo, que é a solicitação da própria página.
6. Agora você terá mais informações sobre esta solicitação de rede.  Clique na aba timing no topo dessas informações para ver qual é o TTFB da sua página.

2. HTTP/3

HTTP/3 é a terceira versão do protocolo HTTP. O HTTP/3 resolve muitos dos problemas encontrados nos protocolos mais antigos HTTP/1.1 e HTTP/2. Por exemplo, desde o HTTP/2, você pode enviar múltiplos arquivos ao mesmo tempo através da mesma conexão. O HTTP/3 proporciona uma conexão inicial mais rápida e menos problemas com pequenas interrupções de rede.

Sem entrar em muitos detalhes, o HTTP/3 permite um ganho significativo de velocidade, especialmente em uma rede mais lenta como uma rede móvel. O administrador da sua rede pode informar se o seu servidor web já é adequado para o protocolo HTTP/3 mais rápido.

Você pode verificar por conta própria se o seu site já está usando o protocolo HTTP/3 mais rápido. Use o atalho Ctrl-Shift-I para abrir o inspetor de rede do Google Chrome. Clique com o botão direito no cabeçalho da tabela e selecione Protocol. Agora recarregue a página para ver qual protocolo o seu site está usando.

3. Cache do Navegador

A conexão de rede é frequentemente um ponto fraco quando se trata de velocidade de página. Não seria muito mais fácil ignorar a rede completamente?

Quando um visitante já esteve no seu site antes, você pode indicar se e por quanto tempo os recursos de rede  (por exemplo, uma folha de estilos)  podem ser armazenados pelo navegador do visitante. Toda vez que o visitante precisar de um desses arquivos novamente, eles aparecem do cache do navegador em pouco tempo. Como resultado, o navegador pode começar a renderizar muito mais rápido e acelerar o FCP.

4. Compressão

A velocidade da rede é, em quase todos os casos, um ponto fraco. Para um bom First Contentful Paint, é muito importante que os arquivos sejam enviados pela rede o mais rápido possível. A compressão reduz o número de bytes que devem ser enviados do servidor – menos bytes significa menos tempo esperando por um recurso de rede. A compressão, na minha opinião, é uma técnica que não está recebendo a atenção que merece. Infelizmente, muitos webmasters "ativam a compressão" e depois não olham mais para isso. E isso é uma pena porque é apenas uma maneira fácil de tornar as coisas um pouco mais rápidas.

Existem duas técnicas populares de compressão: Gzip e Brotli. Gzip é a técnica de compressão mais utilizada, mas o Brotli está rapidamente a alcançando. O Brotli foi criado pelo próprio Google e tem resultados 15 a 20% melhores quando se trata de arquivos HTML, JavaScript ou CSS. O Brotli é, portanto, ideal para a web.

Também existe uma diferença entre compressão dinâmica e compressão estática. Com compressão dinâmica, você comprime o arquivo logo antes de enviá-lo pelo seu servidor web; com compressão estática, o arquivo comprimido é armazenado no servidor. Esta é frequentemente uma forma muito mais inteligente de comprimir, mas raramente é usada.

5. Web-fonts antecipadas com resource hints

Os resource hints iniciam um download ou conexão de rede antes que o navegador o fizesse por conta própria. Alguns recursos de rede, como web fonts ou imagens, só são baixados depois que o navegador tem certeza de que precisa exibi-los.

Se você tem certeza de que precisa de um recurso para renderizar a parte visível do site, quase sempre é uma boa ideia incluir um "resource hint". Isso garantirá que o navegador comece a baixar ou conectar ao recurso imediatamente. Como resultado, o recurso fica disponível mais cedo e o navegador pode começar a renderizar mais cedo.

Mas tenha cuidado com resource hints, se você usá-los incorretamente, eles podem na verdade desacelerar sua página.

Download antecipado com "preloading"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

O link preload é uma das ferramentas mais poderosas no arsenal de velocidade de página. Através do link preload, você baixa um recurso de rede que precisará mais tarde. Isso é frequentemente uma ideia muito boa com fontes, scripts críticos e imagens na parte visível do site.

Conectando antecipadamente com preconnect

O link preconnect já conecta a um servidor. Isso é útil quando você hospeda arquivos em um servidor de terceiros, como um CDN ou Google Analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

6. Pré-buscar a próxima página com prefetch

<link rel="prefetch" href="/page2.html">

Com prefetch, você pode buscar recursos de baixa prioridade. Esta é uma forma útil de buscar recursos que você acha que precisará mais tarde – quando espera que alguém clique no link da próxima página, por exemplo.

7. Evite redirecionamentos

Um erro comum é ter uma cadeia de redirecionamento muito longa. Deixe-me explicar: O seu site provavelmente funciona através de uma conexão segura. Quando um visitante digita o seu site, sem adicionar https, ele será redirecionado para a versão não segura do seu site. No entanto, se tudo estiver configurado corretamente, o visitante será redirecionado para o site seguro. Você pode ver isso no exemplo verde abaixo.

Mas às vezes o redirecionamento acontece através de um ou mais passos intermediários, como mostrado no exemplo vermelho. São esses passos intermediários que fazem o site funcionar lentamente, resultando em uma pontuação fraca de First Contentful Paint. Cada passo intermediário custa tempo extra, que pode se acumular rapidamente. Portanto, sempre garanta que você chegue à página certa com apenas um redirecionamento.

8. Minimize o CSS

Um arquivo CSS externo é sempre bloqueante para renderização. O que isso significa é que um navegador normalmente não pode começar a exibir conteúdo até que todas as folhas de estilo tenham sido baixadas e analisadas. Portanto, é melhor manter as folhas de estilo o menor possível. Desta forma, você não precisa esperar tanto tempo para a folha de estilo ser baixada.

Reduzindo o tamanho do CSS com shortcode

Uma das formas de reduzir o tamanho do CSS é usando shortcodes. São instruções de uma linha que permitem escrever as propriedades mais importantes de um seletor CSS em uma linha.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

Você também pode escrevê-lo como:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Reduzindo ainda mais o tamanho do CSS

É possível reduzir ainda mais o tamanho do CSS mesclando seletores com vírgula,  removendo quebras de linha e espaços e escrevendo códigos de cor mais curtos.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Poderia ser encurtado para

h1,h2,h3,h4,h5{color:#000}

9. CSS Crítico

Podemos levar o CSS um passo adiante usando CSS crítico. O CSS crítico é indispensável para um site rápido e um First Contentful Paint rápido.

O CSS crítico é uma coleção de todos os seletores (como body, p, h1 etc.) que você precisa para mostrar a parte visível da página. Não coloque este CSS crítico em uma folha de estilos separada; em vez disso, adicione-o diretamente no <head> da página. Desta forma, você não precisa baixar um novo arquivo e o navegador pode começar a renderizar com velocidade máxima. Isso resulta em um FCP mais rápido. O CSS que você não precisa diretamente para a parte visível da página é carregado após o primeiro ciclo de renderização ser concluído. Para o seu visitante, a página já está pronta – ninguém vai notar os novos estilos ainda sendo adicionados em segundo plano.

O CSS crítico pode ser facilmente gerado com a nossa própria ferramenta de CSS crítico. Basta colar a URL da sua página web na ferramenta e nós fazemos o resto por você!

10. Adiar o carregamento do JavaScript

Uma das razões mais comuns para um First Contentful Paint lento é JavaScript. Dependendo de como você usa JavaScript, ele pode bloquear a renderização da página. Normalmente o JavaScript é baixado e executado antes da árvore de renderização ser construída. Sem a árvore de renderização, um navegador não pode colocar nada na tela – isso inclui o FCP.

Podemos contornar isso adiando o JavaScript. Você pode fazer isso de três maneiras

JavaScript Async

<script async src="async.js"></script>

Ao adicionar o atributo async a uma tag script, a construção da página não é mais bloqueada enquanto o JavaScript está sendo baixado. O atributo async indica que o download e a construção da árvore de renderização podem acontecer ao mesmo tempo.

Uma vez que o script é executado, a página é bloqueada. Na maioria dos casos, graças ao atributo async, o navegador teve tempo suficiente para construir uma parte importante da página, com o First Contentful Paint já na página.

JavaScript Defer

<script defer src="async.js"></script>

O atributo defer funciona mais ou menos da mesma forma que o atributo async. Ao adicionar o atributo defer a uma tag script, o script também pode ser baixado simultaneamente à construção da página. Depois que todos os scripts são baixados, eles são executados na ordem em que foram encontrados no código HTML. Isso também pode bloquear a exibição da página, mas em muitos casos o First Contentful Paint já está na tela.

11. Não dependa de recursos externos

Recursos externos, como fontes externas, imagens externas, folhas de estilo externas ou scripts externos, são um potencial gargalo quando se trata do First Contentful Paint. Como você não tem controle do servidor onde os arquivos estão hospedados, você não sabe quão rápido eles serão enviados. Além disso, você não pode usar a conexão existente com o servidor web. Uma nova conexão com um novo servidor precisa ser estabelecida – e isso leva tempo.

Recursos externos bloqueantes

Sem recursos externos

12. Use o formato de fonte correto

As fontes merecem atenção extra quando se trata do First Contentful Paint. Em cerca de 99% das páginas que analisamos, o elemento FCP é uma linha de texto. Quando você usa web fonts externas, você deve baixar essas fontes de um servidor primeiro, o que – claro – leva tempo. 

Recentemente, as web fonts têm recebido mais atenção e existem mais formatos de fonte novos e mais rápidos. O formato de fonte mais rápido no momento é woff2, seguido por woff. O Woff2 é suportado por todos os navegadores modernos. 

Você pode especificar a ordem preferida da sua web font na declaração CSS font-face. Você faz isso da seguinte forma:

 @font-face {  
   font-family: 'myFont';  
   font-weight: 400;  
   font-style: normal;  
   font-display: swap;
   unicode-range: U+000-5FF 
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

13. Font display:swap

Ao usar web fonts, o comportamento padrão dessas fontes é não mostrar o texto na página até que a fonte seja carregada. Isso geralmente é diretamente às custas do First Contentful Paint. 

Você pode resolver isso usando o font-display:swap. Com isso, você pode escolher mostrar o texto na página de qualquer forma, em uma fonte que o navegador conhece, enquanto a web font é carregada em segundo plano.

Sem font-display:swap

Com font-display:swap

Leia nosso artigo completo  Ensure text remains visible during webfont load

14. Minimize o tamanho do DOM

Uma página web consiste em HTML. A primeira coisa que um navegador faz é converter o HTML em nós DOM. Essa é uma estrutura em árvore de elementos HTML que é posteriormente usada para construir a árvore de renderização. A partir da árvore de renderização, um navegador começa a renderizar; eventualmente a página web aparece na tela. 

Quantos nós DOM (elementos HTML) você tem e quão profundos esses nós DOM estão na estrutura em árvore determina quão complicado é para um navegador construir sua página. CSS e JavaScript também levam mais tempo para analisar quando você tem muitos nós DOM. Isso, novamente, é tudo diretamente às custas do FCP.

Resolva isso da seguinte forma:

• Carregue partes da sua página web de forma lazy
  Para acelerar a exibição inicial, considere carregar partes do seu site, como o rodapé, via AJAX em um momento posterior.
• Use content-visibility
  A propriedade CSS content-visibility diz ao navegador para pular estilo, layout e paint durante a renderização. Ela faz isso logo antes do elemento se tornar visível.
•  Divida páginas grandes em múltiplas páginas
  O número de nós DOM pode ser reduzido dividindo páginas grandes em múltiplas páginas.
•  Implemente scroll infinito
  O scroll infinito é basicamente lazy loading: ao percorrer elementos repetidos como imagens (pinterest) ou grandes tabelas de dados, o scroll infinito pode acelerar significativamente sua página.
• Evite interação JavaScript com o DOM
  Tenha cuidado extra com JavaScript quando você tem um grande número de nós DOM na sua página. Um comando como esse pode então carregar um grande número de nós DOM, aumentando o uso de memória.
• Evite declarações CSS complicadas
  Tenha cuidado extra com comandos CSS complicados com um grande número de nós DOM. Por exemplo, você deve verificar o status last-child para cada elemento div na sua página.
• Use web workers para poupar a thread principal do seu navegador
  Web workers são JavaScript que podem ser executados em paralelo com sua página web. Você pode dar a esses web workers comandos que são executados em segundo plano. Quando o web worker executou o comando, ele o passa para a página original. A vantagem disso é que você ainda pode executar JavaScript complexo sem que a página congele.