First Contentful Paint (FCP): O Que É, Como Medir e Corrigir

Corrigir o First Contentful Paint

O First Contentful Paint (FCP) é o momento em que um navegador desenha o primeiro elemento significativo em uma página para o visitante ver. Em outras palavras, é o momento em que um navegador renderiza algo na tela pela primeira vez. Como tal, o FCP é uma boa maneira de medir a velocidade de carregamento percebida da página.

Você pode melhorar o FCP garantindo que um navegador possa começar a renderizar sem nenhum atraso. Abaixo você aprenderá o que é o FCP, como medi-lo e 15 técnicas comprovadas para torná-lo mais rápido.

O que é o First Contentful Paint (FCP)?

O First Contentful Paint (FCP) é uma forma de medir a velocidade de carregamento da página. Você não pode resumir a velocidade da página como um único ponto no tempo; na verdade, existem vários momentos durante o processo de carregamento em que um visitante pode sentir que o site está carregando rápido ou devagar. O FCP mede a diferença de tempo entre a solicitação da página e quando o primeiro conteúdo significativo é renderizado na tela pela primeira vez.

Mas o que exatamente isso lhe diz? Isso lhe diz 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 um visitante realmente vê "algo" na tela.

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

1. First: Por First, é claro, queremos dizer o primeiro momento exato em que algo substancial aparece no seu navegador.
2. Contentful: Por contentful queremos dizer 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 deve estar pronto para calcular todas as características de um elemento. Abaixo está um exemplo do processo de renderização que é necessário antes que qualquer coisa possa ser adicionada na tela.

FCP vs LCP: Qual é a Diferença?

O FCP e o LCP (Largest Contentful Paint) medem o desempenho de carregamento, mas capturam momentos diferentes na linha do tempo de carregamento da página. Entender a diferença ajuda você a priorizar seu trabalho de otimização corretamente.

Na prática, o FCP geralmente dispara bem antes do LCP. Por exemplo, uma página pode renderizar um cabeçalho (FCP) em 400ms, mas esperar mais 2 segundos para a hero image carregar (LCP). Se o seu FCP for lento, o seu LCP quase certamente também será lento, porque o FCP captura o primeiríssimo gargalo no pipeline de renderização. Leia mais em nosso guia completo de LCP.

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

Uma boa pontuação FCP é qualquer valor abaixo de 1.8 segundos. Se a sua pontuação FCP estiver entre 1.8 e 3 segundos, ela precisa de melhorias. Qualquer pontuação FCP acima de 3 segundos é considerada ruim. Para atingir o limite recomendado para o First Contentful Paint, pelo menos 75% dos seus visitantes precisam ter uma "boa" pontuação FCP.

Como sempre ocorre com métricas de desempenho, uma pontuação First Contentful Paint mais rápida é melhor do que uma mais lenta.

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

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

Obtendo o First Contentful Paint do conjunto de dados CrUX

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

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

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

Medindo o FCP no Lighthouse

1. Abra a página (no Chrome) cujo FCP você deseja medir. Certifique-se de fazer isso em uma janela anônima para que os plugins não interfiram e possivelmente tornem o FCP da sua página mais lento.
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. Na parte superior do console, você verá a aba Lighthouse. Clique nela. Em seguida, em Categories, escolha Performance (deixe as outras em branco) e escolha Mobile em Device.
4. Agora clique em Generate Report. 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 do 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 diversas ferramentas online. As mais conhecidas são GTMetrix, pingdom e pagespeed.web.dev. É fácil trabalhar com essas ferramentas e elas fornecerão alguns dados sobre o FCP sob circunstâncias específicas de laboratório.

O Que os Dados Reais de FCP Mostram

Os dados do CoreDash mostram que o FCP acompanha de perto o TTFB: o p75 do FCP é de 392ms no geral, com desktop em 372ms e mobile em 692ms (1.9x mais lento). O delta entre o FCP e o TTFB é de apenas 248ms no desktop e 376ms no mobile, indicando que o tempo de bloqueio de renderização representa uma porção relativamente pequena do FCP em um site bem otimizado.

Globalmente, de acordo com o Web Almanac 2025, 70% das páginas em desktop alcançam um bom FCP, enquanto apenas 55% das páginas em mobile o fazem. Ambos melhoraram em relação a 2024, com o mobile ganhando 4 pontos percentuais, sugerindo que os desenvolvedores web estão lidando cada vez mais com recursos que bloqueiam a renderização.

A estreita correlação entre o FCP e o TTFB significa que melhorar o seu Time to First Byte costuma ser a maneira mais eficaz de melhorar o seu First Contentful Paint. Neste site, o FCP fica apenas cerca de 250ms acima do TTFB, o que significa que a maior parte do tempo de FCP é gasta esperando a resposta do servidor em vez de em trabalhos que bloqueiam a renderização.

Melhorando o First Contentful Paint

Hora de tornar o FCP mais rápido. A ideia por trás de um FCP rápido é na verdade bastante simples: garantir que um navegador possa começar a renderizar imediatamente. Qualquer coisa que possa causar atraso na renderização resultará em uma pontuação ruim de FCP.

Assim como no 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 o navegador começa a carregar a página até quando recebe o primeiro byte do HTML.
2. Atraso de 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 de renderização do elemento: O tempo entre quando o recurso do FCP termina de carregar até o elemento do FCP ser totalmente renderizado.

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

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

Abaixo estão 14 soluções que costumo usar para melhorar o FCP. Mas tenha cuidado, usar uma solução no lugar errado pode, na verdade, criar atrasos. É por isso que é melhor consultar um especialista em velocidade de página antes de começar sozinho.

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 realizar multitarefas, e o impacto de outras otimizações começa a diminuir. O código HTML é a única requisição que afeta diretamente todas as métricas de velocidade.

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

Quando se trata do Time to First Byte, quanto menor, melhor.

Você pode facilmente medir 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 desenvolvedores do Google Chrome.
2. Na parte superior do console, você verá uma aba Network. Clique nela.
3. Recarregue a página com Ctrl-R.
4. Você verá agora todas as requisições de rede que o Chrome enviou para o seu servidor.
5. Clique na primeira requisição de rede, que é a requisição da própria página.
6. Agora você obterá mais informações sobre esta requisição de rede. Clique na aba Timing na parte superior dessas informações para ver qual é o TTFB da sua página.

2. HTTP/3

O HTTP/3 é a terceira versão do protocolo HTTP. O HTTP/3 resolve muitos dos problemas encontrados nos antigos protocolos HTTP/1.1 e HTTP/2. Por exemplo, desde o HTTP/2, você pode enviar vários arquivos ao mesmo tempo através da mesma conexão. O HTTP/3 fornece uma conexão inicial mais rápida e menos problemas causados por 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 lhe dizer se o seu servidor web já está adaptado 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. 103 Early Hints

O 103 Early Hints é um código de status HTTP relativamente novo que permite que um servidor envie cabeçalhos de resposta preliminares antes que a resposta final esteja pronta. Isso é especialmente útil quando o seu servidor precisa de tempo para gerar o HTML (por exemplo, consultando um banco de dados ou executando lógica no lado do servidor). Em vez de fazer o navegador esperar ocioso, o servidor envia uma resposta 103 com dicas de preload e preconnect para que o navegador possa começar a buscar recursos críticos imediatamente.

Isso melhora diretamente o FCP porque o navegador pode começar a baixar fontes, stylesheets e outros recursos críticos para renderização antes mesmo do HTML chegar. O impacto é mais significativo em páginas com um TTFB alto.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

Nem todos os provedores de hospedagem suportam o 103 Early Hints ainda. A Cloudflare possui suporte nativo para Early Hints, e o Apache e o Nginx podem ser configurados para enviá-los. Leia mais em nosso guia completo sobre 103 Early Hints.

4. Cache no Navegador

A conexão de rede é muitas vezes um elo fraco quando se trata da velocidade da página. Não seria muito mais fácil pular a rede por completo?

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

5. Compressão

A velocidade da rede é, em quase todos os casos, um elo 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 pelo servidor; menos bytes significam 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 dão mais atenção a isso. E isso é uma pena, porque é apenas uma maneira fácil de fazer as coisas andarem um pouco mais rápido.

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

Há também uma diferença entre compressão dinâmica e compressão estática. Com a compressão dinâmica, você comprime o arquivo logo antes de enviá-lo pelo seu servidor web; com a compressão estática, o arquivo comprimido fica armazenado no servidor. Muitas vezes, essa é uma maneira muito mais inteligente de comprimir, mas raramente é usada.

6. Fontes da web antecipadas com resource hints

Os resource hints iniciam um download ou conexão de rede antes que o navegador o faça 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 se 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 os resource hints. Se você usá-los incorretamente, eles podem, na verdade, tornar a sua página mais lenta.

Download antecipado com "preloading"

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

A tag link com preload é uma das ferramentas mais poderosas no arsenal de velocidade da página. Por meio do link preload, você baixa um recurso de rede de que precisará mais tarde. Muitas vezes, essa é uma ótima ideia com fontes, scripts críticos e imagens na parte visível do site.

Conectando com antecedência com preconnect

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

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

Ainda melhor do que usar preconnect para o Google Fonts é hospedar suas próprias fontes do Google Fonts. Isso elimina totalmente a conexão com terceiros e lhe dá controle total sobre o cache e a entrega.

7. Use prefetch para buscar a próxima página

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

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

8. Evite redirecionamentos

Um erro comum é ter uma cadeia de redirecionamento muito longa. Deixe-me explicar: seu site provavelmente roda por meio de uma conexão segura. Quando um visitante digita o seu site sem adicionar https, o visitante 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 ocorre por meio de uma ou mais etapas intermediárias, como mostrado no exemplo em vermelho. São essas etapas intermediárias que fazem com que o site fique lento, resultando em uma pontuação ruim no First Contentful Paint. Cada etapa intermediária custa um tempo extra, que pode se acumular rapidamente. Portanto, sempre certifique-se de chegar à página certa em até um redirecionamento.

9. Minimize o CSS

Um arquivo CSS externo é sempre algo que bloqueia a renderização. O que isso significa é que um navegador normalmente não pode começar a exibir o conteúdo até que todos os stylesheets tenham sido baixados e analisados. Portanto, é melhor manter os stylesheets o menores possíveis. Dessa forma, você não precisa esperar tanto tempo para o download do stylesheet. Para um guia mais completo, leia nosso artigo sobre como corrigir e remover o CSS não utilizado.

Reduzindo o tamanho do CSS com shortcodes

Uma das maneiras de reduzir o tamanho do CSS é usando shortcodes. Tratam-se de linhas únicas que permitem que você anote as propriedades mais importantes de um seletor CSS em uma única 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 o tamanho do CSS ainda mais unindo os seletores com uma vírgula, removendo quebras de linha e espaços e escrevendo códigos de cores mais curtos.

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

Pode ser encurtado como

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

10. Critical CSS

Podemos levar o CSS um passo adiante usando o Critical CSS. O Critical CSS é obrigatório para um site rápido e um First Contentful Paint rápido.

O Critical CSS é uma coleção de todos os seletores (como body, p, h1 etc.) de que você precisa para mostrar a parte visível da página. Não coloque este Critical CSS em um stylesheet separado; em vez disso, adicione-o diretamente no <head> da página. Dessa forma, você não precisa baixar um novo arquivo e o navegador pode começar a renderizar na velocidade da luz. 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 perceberá os novos estilos ainda sendo adicionados em segundo plano.

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

Exemplo de Critical CSS Inline

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. Adiar o carregamento do JavaScript

Um dos motivos mais comuns para um First Contentful Paint lento é o JavaScript. Dependendo de como você usa o 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 consegue colocar nada na tela, e isso inclui o FCP. Para uma visão completa das técnicas de adiamento, leia sobre 14 métodos para adiar o JavaScript.

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 de script, a construção da página não fica mais bloqueada enquanto o JavaScript é baixado. O atributo async indica que o download e a construção da árvore de renderização podem acontecer ao mesmo tempo.

Depois 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="deferred.js"></script>

O atributo defer funciona mais ou menos da mesma forma que o atributo async. Ao adicionar o atributo defer a uma tag de script, o script também pode ser baixado simultaneamente com a 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.

12. Não dependa de recursos externos

Recursos externos, como fontes externas, imagens externas, stylesheets externos ou scripts externos, são um gargalo potencial quando se trata do First Contentful Paint. Como você não tem controle sobre o servidor onde os arquivos estão hospedados, não sabe a rapidez com que 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 deve ser estabelecida, e isso leva tempo.

Um dos recursos externos mais comuns na web é o Google Fonts. Hospedar suas próprias fontes do Google Fonts elimina toda uma conexão de terceiros e lhe dá controle total sobre cache, compressão e comportamento de exibição de fontes.

Recursos externos que bloqueiam a renderização

Sem recursos externos

13. Use o formato de fonte correto

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

Recentemente, as web fonts vêm recebendo mais atenção e há mais formatos de fonte novos e rápidos. O formato de fonte mais rápido no momento é o woff2, seguido pelo 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');
}

14. 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 acontece diretamente às custas do First Contentful Paint. Leia nosso guia completo sobre como garantir que o texto permaneça visível durante o carregamento da webfont.

Você pode resolver isso usando a declaração font-display:swap. Com ela, você pode optar por mostrar o texto na página de qualquer maneira, em uma fonte que o navegador conhece, enquanto a webfont é carregada em segundo plano.

Sem font-display:swap

Com font-display:swap

font-display: swap vs optional

Existem duas estratégias comuns de font-display para a otimização do FCP:

/* swap: Mostra a fonte de fallback imediatamente, troca quando a webfont carrega */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Mostra a fonte de fallback, só usa a webfont se já estiver em cache */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

O uso de font-display: swap garante o FCP mais rápido possível porque o texto é renderizado imediatamente na fonte de fallback. O uso de font-display: optional evita totalmente o flash of unstyled text (FOUT) na primeira visita, mas a webfont só será exibida se já estiver no cache do navegador. Para a maioria dos sites, o swap é a melhor escolha para o FCP.

15. 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 do DOM. Trata-se de uma estrutura de árvore de elementos HTML que mais tarde é usada para construir a árvore de renderização. A partir da árvore de renderização, o navegador começa a renderizar; eventualmente, a página web aparece na tela.

A quantidade de nós do DOM (elementos HTML) que você tem e quão profundos esses nós do DOM estão na estrutura da árvore determina o quão complicado é para um navegador construir a sua página. O CSS e o JavaScript também levam mais tempo para serem analisados quando você tem muitos nós no DOM. Isso, mais uma vez, ocorre diretamente às custas do FCP.

Resolva isso através de:

• Carregamento preguiçoso (lazy load) de partes da sua página web
  Para acelerar a exibição inicial, considere carregar partes do seu site, como o rodapé, via AJAX em um momento posterior.
• Faça uso de content-visibility
  A propriedade CSS content-visibility diz a um navegador para pular o estilo, layout e pintura durante a renderização. Ele faz isso pouco antes de o elemento se tornar visível.
• Divida páginas grandes em várias páginas
  O número de nós do DOM pode ser reduzido dividindo páginas grandes em várias páginas.
• Implemente a rolagem infinita
  A rolagem infinita é basicamente lazy loading: ao rolar por elementos repetidos, como imagens (Pinterest) ou grandes tabelas de dados, o infinite scroll pode acelerar significativamente a sua página.
• Evite a interação do JavaScript com o DOM
  Tenha cuidado redobrado com o JavaScript quando você tiver um grande número de nós do DOM em sua página. Um comando como querySelectorAll pode então carregar um grande número de nós do DOM, aumentando o uso de memória.
• Evite declarações CSS complicadas
  Tenha cuidado redobrado com comandos CSS complicados com um grande número de nós do DOM. Por exemplo, verificar o status de last-child de cada elemento div na sua página pode ser custoso.
• Use web workers para poupar a thread principal do seu navegador
  Web workers são JavaScript que podem ser executados em paralelo com a sua página web. Você pode dar a esses web workers comandos que são executados em segundo plano. Quando o web worker executa o comando, ele o repassa para a página original. A vantagem disso é que você ainda pode executar JavaScript complexo sem que a página congele.

Guias de Otimização Relacionados

Melhorar o FCP exige trabalho em várias áreas. Aqui estão nossos guias mais relevantes:

• Hospede suas fontes do Google Fonts: Elimine uma conexão de terceiros e obtenha controle total sobre a entrega da fonte.
• Garanta que o texto permaneça visível durante o carregamento da webfont: Use font-display para garantir uma renderização rápida do texto.
• 14 métodos para adiar o JavaScript: Todas as técnicas para impedir que o JavaScript bloqueie seu FCP.
• Corrija e remova o CSS não utilizado: Reduza o CSS que bloqueia a renderização ao mínimo.
• 103 Early Hints: Deixe o navegador começar a buscar recursos antes que o HTML chegue.
• Guia do Largest Contentful Paint (LCP): O FCP e o LCP compartilham muitas estratégias de otimização. Se o seu FCP for lento, o seu LCP também será.
• Guia do Time to First Byte (TTFB): O TTFB é o maior contribuidor individual para o FCP. Comece por aqui se a resposta do seu servidor estiver lenta.