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

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 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 quando o primeiro conteúdo significativo é renderizado na tela pela primeira vez.

Mas o que exatamente isso lhe diz? Diz que o FCP é principalmente uma "métrica centrada no usuário" porque indica algo sobre a velocidade de carregamento que o 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: Com First, é claro, queremos dizer o primeiro momento exato em que algo substancial aparece no seu navegador.
2. Contentful: Com contentful queremos dizer um elemento HTML com conteúdo. Então não um elemento de layout como um elemento vazio 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, o 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.

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 corretamente o seu trabalho de otimização.

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

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

Uma pontuação de FCP boa é qualquer valor abaixo de 1,8 segundos. Se a sua pontuação de FCP estiver entre 1,8 e 3 segundos, ela precisa de melhoria. Qualquer pontuação de 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 pontuação de FCP "boa".

Como sempre com métricas de desempenho, uma pontuação mais rápida de First Contentful Paint é 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 dataset CrUX. Esses dados estão disponíveis publicamente através da API CrUX ou do 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 API CrUX 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 as extensões não interfiram e possivelmente desacelerem o FCP da sua página.
2. Clique com o botão direito na página e selecione Inspecionar Elemento. Dessa forma você abre o console de desenvolvedor do Chrome.
3. No topo do console, você verá a aba Lighthouse. Clique nela. Em seguida, 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, certo?

Medindo o FCP com uma ferramenta online

Você também pode medir o FCP com várias ferramentas online. As mais conhecidas são GTMetrix, pingdom e pagespeed.web.dev. Essas ferramentas são fáceis de usar e fornecerão alguns dados sobre o FCP em condições 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 é 392ms no geral, com desktop em 372ms e mobile em 692ms (1,9x mais lento). O delta entre FCP e 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 HTTP Archive Web Almanac 2024, 68% das páginas desktop alcançam um bom FCP, enquanto apenas 51% das páginas mobile conseguem. O FCP se recuperou em 2024 após um leve declínio em 2023, sugerindo que os desenvolvedores web estão cada vez mais abordando os recursos bloqueadores de renderização.

A forte correlação entre FCP e TTFB significa que melhorar o seu Time to First Byte é frequentemente a forma mais eficaz de melhorar o seu First Contentful Paint. Neste site, o FCP está apenas cerca de 250ms acima do TTFB, o que significa que a maior parte do tempo de FCP é gasta esperando a resposta do servidor, e não em trabalho de bloqueio de renderização.

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 ruim de FCP.

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 o navegador começa a carregar a página até receber 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 do FCP ser completamente renderizado.

Dica de velocidade: Você pode facilmente eliminar os passos 2 e 3 garantindo que o elemento do FCP 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 velocidade de página 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, o seu navegador começa a fazer multitarefas 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 pelo 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, quanto menor, 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á a 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 pela 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 redes mais lentas como redes móveis. O seu administrador de rede pode informar se o seu servidor web já está preparado 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

103 Early Hints é um código de status HTTP relativamente novo que permite ao servidor enviar 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 do 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, folhas de estilo 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 103 Early Hints ainda. O Cloudflare tem suporte integrado para Early Hints, e o Apache e o Nginx podem ser configurados para enviá-los. Leia mais no nosso guia completo de 103 Early Hints.

4. Cache do Navegador

A conexão de rede é frequentemente um ponto fraco quando se trata de velocidade da página. Não seria muito mais fácil pular 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 estilo) podem ser armazenados pelo navegador do visitante. Toda vez que o visitante precisar de um desses arquivos novamente, eles aparecem do cache do navegador instantaneamente. 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 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 pelo 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 recebe a atenção que merece. Infelizmente, muitos webmasters "ativam a compressão" e depois não olham mais para ela. 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. O Gzip é a técnica de compressão mais usada, mas o Brotli está alcançando rapidamente. 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.

Há também 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 maneira muito mais inteligente de comprimir, mas raramente é usada.

6. Web-fonts antecipadas com resource hints

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 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 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 ótima ideia com fontes, scripts críticos e imagens na parte visível do site.

Conectando antecipadamente com preconnect

O link preconnect já se 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>

Melhor ainda do que preconnect ao Google Fonts é hospedar suas Google Fonts localmente. Isso elimina totalmente a conexão com terceiros e dá a você controle total sobre cache e entrega.

7. Prefetch da próxima página com prefetch

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

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

8. Evitar redirecionamentos

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

9. Minimizar CSS

Um arquivo CSS externo é sempre bloqueador de 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. Dessa forma você não precisa esperar tanto tempo pelo download da folha de estilo. Para um guia mais completo, leia nosso artigo sobre como corrigir e remover CSS não utilizado.

Reduzindo o tamanho do CSS com shortcode

Uma das maneiras de reduzir o tamanho do CSS é usando shortcodes. São linhas únicas 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 escrever 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 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}

10. CSS Crítico

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

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 estilo separada; 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 em 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 na ferramenta e nós fazemos o resto para você!

Exemplo de CSS Crítico 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 de JavaScript

Uma das razões mais comuns para um First Contentful Paint lento é o JavaScript. Dependendo de como você usa JavaScript, ele pode bloquear a renderização da página. Normalmente o JavaScript é baixado e executado antes que a render tree seja construída. Sem a render tree, o navegador não pode colocar nada na tela, e isso inclui o FCP. Para uma visão completa das técnicas de adiamento, leia 14 métodos para adiar 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 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 render tree 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="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 script, o script também pode ser baixado simultaneamente à construção da página. Após todos os scripts serem 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 na maioria dos casos o First Contentful Paint já está na tela.

12. Não dependa de recursos externos

Recursos externos, como fontes externas, imagens externas, folhas de estilo externas ou scripts externos, são um gargalo potencial 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 a velocidade 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 Google Fonts localmente elimina uma conexão inteira com terceiros e dá a você controle total sobre cache, compressão e comportamento de font-display.

Recursos externos bloqueadores

Sem recursos externos

13. 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, precisa baixar essas fontes de um servidor primeiro, o que naturalmente 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');
}

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 é 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 web font.

Você pode resolver isso usando a declaração font-display:swap. Com isso você pode optar por mostrar o texto na página mesmo assim, em uma fonte que o navegador conhece, enquanto a web font é 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 otimização do FCP:

/* swap: Shows fallback font immediately, swaps when webfont loads */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Shows fallback font, only uses webfont if already cached */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

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

15. Minimizar 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. Isso é uma estrutura em árvore de elementos HTML que é posteriormente usada para construir a render tree. A partir da render tree, o 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 da árvore determina quão complicado é para o 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:

• 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 posteriormente.
• Utilize content-visibility
  A propriedade CSS content-visibility diz ao navegador para pular estilo, layout e pintura 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 carregamento lazy: ao rolar por 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 querySelectorAll 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, verificar o status de last-child para 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 rodar 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 executou o comando, ele o passa para a página original. A vantagem disso é que você ainda pode executar JavaScript complexo sem a página travar.

Guias de Otimização Relacionados

Melhorar o FCP requer trabalho em múltiplas áreas. Aqui estão nossos artigos mais relevantes com análises aprofundadas:

• Hospedar Google Fonts localmente: Elimine uma conexão com terceiros e tenha controle total sobre a entrega de fontes.
• Garantir que o texto permaneça visível durante o carregamento da web font: Use font-display para garantir renderização rápida de texto.
• 14 métodos para adiar JavaScript: Todas as técnicas para impedir que JavaScript bloqueie seu FCP.
• Corrigir e remover CSS não utilizado: Reduza o CSS bloqueador de renderização ao mínimo.
• 103 Early Hints: Permita que o navegador comece a buscar recursos antes do HTML chegar.
• Guia de Largest Contentful Paint (LCP): FCP e LCP compartilham muitas estratégias de otimização. Se o seu FCP é lento, o seu LCP também será.
• Guia de Time to First Byte (TTFB): O TTFB é o maior contribuidor individual para o FCP. Comece aqui se a resposta do seu servidor é lenta.