Veja o carregamento do seu site pelos olhos do visitante
Tenha uma boa ideia do que seus visitantes estão realmente experimentando quando visitam seu site.
Notou algo carregando lentamente ou fora do lugar? Isso pode ajudá-lo a identificar atrasos importantes e problemas de conversão que seus visitantes enfrentam.
Captura de tela mostrando o resultado de um teste de desempenho da Web do DebugBear, outubro de 2022 A tira de filme da linha do tempo mostra o progresso da renderização do site ao longo do tempo.
Por exemplo, esta página começa a renderizar após 0,7 segundos e a imagem principal é renderizada após 1,3 segundos.
O site é totalmente renderizado, também conhecido como Visualmente Completo, quando o widget de bate-papo é exibido após 3,7 segundos.
Captura de tela do DebugBear mostrando o progresso da renderização de um site ao longo do tempo, outubro de 2022 Dentro da ferramenta, você também pode assistir a uma gravação em vídeo do processo de renderização.
Essa é uma ótima maneira de demonstrar o impacto dos problemas de desempenho para clientes ou outros membros de sua equipe.
Captura de tela mostrando uma gravação de vídeo de um site parcialmente renderizado no DebugBear, outubro de 2022 Teste as mudanças de velocidade do site vendo suas estatísticas reais de carregamento
Digamos que você esteja otimizando seu site e queira entender se essas alterações causarão impacto.
Essa ferramenta executa um “teste de laboratório” em um ambiente ideal para descobrir se você está otimizando seu site corretamente.
Ao testar seu site, você receberá um “Lab Score” oficial, que é um resumo de seis métricas de desempenho provenientes da pontuação de desempenho da ferramenta Lighthouse do Google:
- Primeira pintura de conteúdo (10% da pontuação geral).
- Índice de velocidade (10%).
- Maior pintura de conteúdo (25%).
- Tempo para Interativo (10%).
- Tempo Total de Bloqueio (30%).
- Mudança de layout cumulativa (15%).
Usando esses dados, você descobrirá o quão útil foi sua última rodada de otimizações e o que pode ser necessário alterar.
Até agora, você provavelmente está se perguntando o que precisa mudar. Vamos aprender como otimizar seu site usando cada métrica principal da Visão geral de métricas.
Como otimizar a velocidade do site
Executar um teste de velocidade é a primeira parte da jornada de otimização do seu site.
Depois de ter suas métricas, você precisará saber como interpretá-las e o que fazer para corrigi-las.
Na área Visão geral das métricas do relatório de velocidade do seu site, você verá as principais métricas nas quais focaremos para ajudar a acelerar seu site:
- Primeira pintura de conteúdo: Isso pode ser acelerado reparando a velocidade de comunicação do servidor.
- Maior pintura de conteúdo: Isso pode ser acelerado otimizando a mídia e os recursos.
Além disso, você pode usar a cascata de solicitações para ver quanto tempo as solicitações levam e como isso afeta essas métricas.
Como acelerar a primeira pintura de conteúdo (FCP)
Vamos começar fazendo com que seu site apareça mais cedo para seus visitantes; vamos abordar a primeira pintura de conteúdo, primeiro.
O que é a primeira pintura de conteúdo?
O First Contentful Paint mede a rapidez com que o conteúdo de uma página começa a aparecer depois que o visitante navega para essa página.
É importante que seu conteúdo principal apareça rapidamente para evitar que seu visitante saia do seu site. Quanto mais rápido um usuário sai do seu site, mais rápido o Google descobre que a experiência da página pode ser ruim.
Mas como você sabe exatamente o que está causando o carregamento lento do seu site?
Como você descobre quais problemas de servidor estão deixando seu site lento? Vamos descobrir.
Por que minha primeira pintura de conteúdo está demorando tanto?
Seu FCP pode ser afetado pela velocidade de conexão do servidor, solicitações do servidor, recursos de bloqueio de renderização e muito mais.
Parece muito, mas há uma maneira fácil de ver exatamente o que está diminuindo a velocidade do seu FCP – a cascata de solicitações.
Essa ferramenta útil mostra quais solicitações são feitas pelo seu site e quando cada solicitação começa e termina.
Por exemplo, nesta captura de tela, vemos primeiro uma solicitação para o documento HTML e, em seguida, duas solicitações para carregar folhas de estilo referenciadas no documento.
Captura de tela mostrando dados de depuração para a métrica First Contentful Paint no DebugBear, outubro de 2022 Por que a primeira pintura de conteúdo acontece após 0,6 segundos? Podemos detalhar o que está acontecendo na página para entender isso.
Entendendo o que acontece antes de uma primeira pintura com conteúdo
Antes que as primeiras partes do conteúdo possam ser carregadas em sua página da Web, o navegador do usuário deve primeiro se conectar ao seu servidor e recuperar o conteúdo.
Se esse processo demorar muito, levará muito tempo para o usuário ver seu site.
Seu objetivo é saber o que está acontecendo antes que seu site comece a carregar para que você possa identificar problemas e acelerar a experiência.
Carregamento de página parte 1: o navegador cria uma conexão de servidor
Antes de solicitar um site de um servidor pela primeira vez, o navegador do visitante precisa estabelecer uma conexão de rede com esse servidor.
Isso normalmente leva três etapas:
- Verificando os registros DNS para procurar o endereço IP do servidor com base no nome de domínio.
- Estabelecendo uma conexão de servidor confiável (conhecida como conexão TCP).
- Estabelecendo uma conexão de servidor segura (conhecida como conexão SSL).
Essas três etapas são executadas pelo navegador, uma após a outra. Cada etapa requer uma viagem de ida e volta do navegador do visitante para o servidor do seu site.
Nesse caso, leva cerca de 251 milissegundos para estabelecer a conexão com o servidor.
Captura de tela do DebugBear mostrando as viagens de ida e volta da rede usadas para estabelecer uma conexão de servidor, outubro de 2022 Carregamento de página parte 2: o navegador solicita o documento HTML (o tempo para o primeiro byte acontece aqui)
Uma vez estabelecida a conexão com o servidor, o navegador do seu visitante pode solicitar o código HTML que contém o conteúdo do seu site. Isso é chamado de solicitação HTTP.
Nesse caso, a solicitação HTTP leva 102 milissegundos. Essa duração inclui o tempo gasto na viagem de ida e volta da rede e o tempo gasto esperando o servidor gerar uma resposta.
Após 251 milissegundos para criar a conexão e 102 milissegundos para fazer a solicitação HTTP, o navegador do visitante pode finalmente começar a baixar a resposta HTML.
Esse marco é chamado de Time to First Byte (TTFB). Nesse caso, isso acontece após um total de 353 milissegundos.
Depois que a resposta do servidor estiver pronta, o navegador do visitante passará algum tempo adicional baixando o código HTML. Nesse caso, a resposta é bastante pequena e o download leva apenas 10 milissegundos adicionais.
Captura de tela do DebugBear mostrando os diferentes componentes de uma solicitação HTTP, outubro de 2022 Carregamento de página, parte 3: seu site carrega recursos adicionais de bloqueio de renderização
Os navegadores não renderizam ou mostram páginas imediatamente após carregar o documento. Em vez disso, geralmente há recursos adicionais de bloqueio de renderização.
A maioria das páginas ficaria ruim sem qualquer estilo visual, então as folhas de estilo CSS são carregadas antes de uma página começar a renderizar.
O carregamento das 2 folhas de estilo adicionais neste exemplo de teste de velocidade do site leva 137 milissegundos.
Observe que essas solicitações não exigem uma nova conexão de servidor. Os arquivos CSS são carregados do mesmo domínio de antes e podem reutilizar a conexão existente.
Captura de tela do DebugBear mostrando recursos adicionais de bloqueio de renderização sendo carregados após o documento HTML, outubro de 2022 Carregamento de página Parte 4: O navegador renderiza a página
Finalmente, uma vez carregados todos os recursos necessários, o navegador do seu visitante pode começar a renderizar a página. No entanto, fazer esse trabalho também leva algum tempo de processamento – neste caso, 66 milissegundos. Isso é indicado pelo marcador laranja de tarefa da CPU na visualização em cascata.
Captura de tela do DebugBear mostrando as etapas que levam desde o carregamento do documento HTML até a renderização da página da Web, outubro de 2022 Agora entendemos por que o FCP acontece após 632 milissegundos:
- 364 milissegundos para a solicitação de documento HTML.
- 137 milissegundos para carregar as folhas de estilo.
- 66 milissegundos para renderizar a página.
- 65 milissegundos para outros trabalhos de processamento.
O outro trabalho de processamento inclui pequenos trabalhos, como executar scripts embutidos ou analisar o código HTML e CSS depois de baixado. Você pode ver essa atividade como pequenas linhas cinzas logo abaixo da tira de filme de renderização.
Como otimizar a primeira pintura de conteúdo (FCP)
Agora que você entende o que leva à renderização do seu site, você pode pensar em como otimizá-lo.
- O servidor pode responder à solicitação HTML mais rapidamente?
- Os recursos podem ser carregados na mesma conexão em vez de criar uma nova?
- Existem solicitações que podem ser removidas ou alteradas para não bloquear mais a renderização?
Agora que as partes iniciais do seu site estão sendo carregadas mais cedo, é hora de se concentrar em tornar o carregamento completo do site mais rápido.
Como acelerar a maior pintura de conteúdo (LCP) com as recomendações do DebugBear
Há muitas maneiras de acelerar seu LCP.
Para facilitar, o DebugBear nos dá grandes próximos passos em sua seção de Recomendações.
Vamos dar uma olhada em alguns exemplos de recomendações e aprender como acelerar o LCP deste site.
Recomendação 1: iniciar solicitações de imagem LCP a partir do documento HTML
Se o maior elemento de conteúdo da sua página for uma imagem, a melhor prática é garantir que a URL esteja diretamente contida no documento HTML inicial. Isso ajudará a começar a carregar o mais rápido possível.
No entanto, essa prática recomendada nem sempre é usada e, às vezes, leva muito tempo até que o navegador descubra que precisa baixar a imagem principal.
No exemplo abaixo, o maior conteúdo, que é uma imagem, é adicionado à página usando JavaScript. Como resultado, o navegador precisa baixar e executar um script de 200 kilobytes antes de descobrir a imagem e iniciar o download.
Captura de tela do DebugBear mostrando uma cadeia de solicitação sequencial que leva a uma solicitação de imagem, outubro de 2022 Como corrigir: Dependendo do site, existem duas soluções possíveis.
Solução 1: se você estiver usando JavaScript para carregar lentamente uma imagem grande, otimize o tamanho da imagem e remova o script de carregamento lento ou substitua-o pelo atributo moderno loading=”lazy”, que não requer JavaScript.
Solução 2: em outros casos, a renderização do lado do servidor evitaria a necessidade de baixar o aplicativo JavaScript antes que a página pudesse renderizar. No entanto, isso às vezes pode ser complexo de implementar.
Recomendação 2: certifique-se de que as imagens do LCP sejam carregadas com alta prioridade
Depois de carregar o código HTML de uma página, os navegadores de seus visitantes podem descobrir que, além de sua imagem principal, um grande número de recursos adicionais, como folhas de estilo, pode precisar ser carregado.
O objetivo aqui é garantir que sua imagem principal maior seja carregada para atender ao requisito de maior conteúdo de pintura do Google.
Outros recursos, como scripts de análise de terceiros, não são tão importantes quanto sua imagem principal.
Além disso, a maioria das imagens referenciadas no HTML do seu site estará abaixo da dobra assim que a página for renderizada. Alguns podem estar completamente ocultos em uma navegação de cabeçalho aninhada.
Por causa disso, os navegadores inicialmente definem a prioridade de todas as solicitações de imagem como Baixa. Depois que a página é renderizada, o navegador descobre quais imagens são importantes e altera a prioridade. Você pode ver um exemplo disso na captura de tela abaixo, conforme indicado pelo asterisco na coluna de prioridade.
Captura de tela do DebugBear mostrando uma imagem LCP sendo carregada com baixa prioridade inicial, outubro de 2022 A cascata mostra que, embora o navegador soubesse da imagem desde o início, ele não começou a baixá-la, conforme indicado pela barra cinza.
Como corrigir: Para resolver isso, você pode usar um novo recurso do navegador chamado dicas de prioridade. Se você adicionar o atributo fetchpriority=”high” a um elemento img, o navegador começará a carregar a imagem desde o início.
Recomendação 3: não esconda o conteúdo da página usando CSS
Às vezes, você pode olhar para uma cascata de solicitações e todos os recursos de bloqueio de renderização foram carregados, mas ainda assim, nenhum conteúdo da página aparece. O que está acontecendo?
As ferramentas de teste A/B geralmente ocultam o conteúdo da página até que as variações de teste sejam aplicadas aos elementos de conteúdo da página. Nesses casos, o navegador renderizou a página, mas todo o conteúdo é transparente.
O que você pode fazer se não conseguir remover a ferramenta de teste A/B?
Como corrigir: Verifique se você pode configurar a ferramenta para ocultar apenas o conteúdo afetado por testes A/B. Como alternativa, você pode verificar se há uma maneira de fazer com que a ferramenta de teste A/B seja carregada mais rapidamente.
Captura de tela do DebugBear mostrando uma tira de filme de renderização em que o conteúdo está oculto por uma ferramenta de teste A/B, outubro de 2022 Monitore a velocidade do seu site com o DebugBear
Quer testar continuamente seu site? Experimente nossa ferramenta de monitoramento paga com uma avaliação gratuita de 14 dias.
Dessa forma, você pode verificar se suas otimizações de desempenho estão funcionando e ser alertado sobre quaisquer regressões de desempenho em seu site.
Captura de tela mostrando as tendências de velocidade do site para um site no DebugBear, outubro de 2022 
Captura de tela mostrando dados do Core Web Vitals no DebugBear, outubro de 2022