Reduzir a subparte Waiting Duration do Time to First Byte

Reduzir a Waiting Duration do Time to First Byte

Este artigo faz parte do nosso guia [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte (TTFB)[\/url]. A waiting duration é a primeira subparte do TTFB e consiste principalmente no tempo de redirect e no enfileiramento do navegador (browser queuing). Uma waiting duration alta é quase sempre causada por redirects desnecessários que adicionam round trips antes que o servidor possa começar a processar a requisição real.

O Time to First Byte (TTFB) pode ser dividido nas seguintes subpartes:

• Waiting + Redirect (ou waiting duration)
• [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Worker + Cache (ou cache duration)
• [url=\/core-web-vitals\/time-to-first-byte\/dnsduration]DNS (ou DNS duration)
• [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection (ou connection duration)
• [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request (ou request duration)

  Quer otimizar o Time to First Byte? Este artigo cobre a parte de waiting duration do Time to First Byte. Se você deseja entender ou corrigir o Time to First Byte e não sabe o que waiting duration significa, leia [url=\/core-web-vitals\/time-to-first-byte]o que é o Time to First Byte[\/url] e [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]identificar e corrigir problemas de Time to First Byte[\/url] antes de começar este artigo.

  A parte waitingDuration do Time to First Byte consiste no tempo em que o navegador pode estar executando outras tarefas antes de começar a se conectar a um servidor web, além de qualquer tempo de redirect. Quando os dados de Real User Monitoring (RUM) mostram uma waitingDuration alta, você pode ter certeza de que a causa é o tempo de redirect.

  
  

  Redirects podem ter um grande impacto no Time to First Byte (TTFB) porque cada redirect é adicionado ao tempo que um navegador leva para receber o primeiro byte de dados de um servidor. Veja como os redirects influenciam o TTFB:

  [include]toc.html[\/include]

  Como os Redirects Aumentam o Time to First Byte?

  Redirects são normalmente incluídos na medição completa do TTFB (veja o quadro azul). Isso significa que o tempo gasto em todos os redirects é fatorado na pontuação geral do TTFB, potencialmente fazendo-o parecer mais alto do que o esperado.

  Quando uma página é redirecionada, estes são os passos habituais que ocorrem:

  • O navegador envia uma requisição inicial para a URL original.
  • O servidor processa essa requisição e responde com um código de status de redirect (ex: 301 ou 302).
  • O navegador envia então uma nova requisição para a URL redirecionada.
  • O servidor processa essa segunda requisição e começa a enviar o conteúdo real.

    Tipos de Redirects e seu Impacto

    Nem todos os redirects são iguais. Entender os diferentes tipos ajuda você a priorizar quais redirects eliminar primeiro:

    Tipo de Redirect	Status HTTP	Caso de Uso	Impacto no TTFB
    Redirect permanente	301	A página mudou permanentemente para uma nova URL	Os navegadores podem armazenar em cache, reduzindo o impacto repetido
    Redirect temporário	302	A página está temporariamente em uma URL diferente	Não é armazenado em cache pelos navegadores; round trip completo sempre
    Redirect temporário (explícito)	307	Igual ao 302, mas preserva o método HTTP	Não armazenado em cache; mesmo impacto que o 302
    Redirect permanente (explícito)	308	Igual ao 301, mas preserva o método HTTP	Os navegadores podem armazenar em cache, semelhante ao 301 Um único redirect normalmente adiciona de 50 a 300 milissegundos ao TTFB, dependendo das condições da rede e do tempo de resposta do servidor. Quando dois ou três redirects se encadeiam, esses tempos se somam e podem levar o TTFB bem acima do limite "bom" de 800ms. Aumento no Tempo de Processamento do Servidor Este processamento adicional aumenta o TTFB geral, pois cada etapa requer tempo para o servidor lidar com a requisição e responder. Cadeias de Redirect Em alguns casos, vários redirects podem ocorrer antes de chegar ao destino final. Isso cria uma "cadeia de redirect" que aumenta o TTFB. Cada redirect na cadeia adiciona seu próprio tempo de processamento, aumentando o atraso antes que o primeiro byte do conteúdo real seja recebido. Um exemplo comum de cadeia de redirect: http:\/\/example.com -> 301 -> https:\/\/example.com -> 301 -> https:\/\/www.example.com -> 301 -> https:\/\/www.example.com\/en\/ Neste exemplo, ocorrem três redirects antes que o navegador receba qualquer conteúdo. O primeiro redirect (HTTP para HTTPS) pode ser eliminado com HSTS. O segundo e o terceiro redirects podem ser eliminados atualizando os links internos para apontar diretamente para a URL final. Latência de Rede Redirects geralmente envolvem round trips de rede adicionais entre o cliente e o servidor. Isso introduz latência de rede extra, especialmente se os redirects envolverem domínios ou servidores diferentes. A distância física entre o cliente e o servidor para cada redirect pode impactar ainda mais o TTFB. Redirects de JavaScript vs Redirects de servidor: Apenas redirects de servidor (que funcionam com um cabeçalho de redirect 30x) são adicionados ao Time to First Byte. Redirects de JavaScript não são adicionados ao Time to First Byte porque uma resposta completa (200) foi enviada pelo servidor. Pode-se pensar que os redirects de JavaScript devem ser preferidos, pois não adicionam ao Time to First Byte. Infelizmente, os redirects de JavaScript são muito mais lentos para usuários reais e causarão uma má experiência do usuário. Impacto na Experiência do Usuário (e SEO) Embora os redirects sejam às vezes necessários, seu impacto no TTFB pode ter implicações mais amplas: Experiência do Usuário: Um TTFB mais lento devido a redirects pode atrasar a renderização inicial da página, potencialmente frustrando os usuários. SEO: Embora o TTFB não seja um fator de ranqueamento direto, ele influencia outras métricas como o [url=\/core-web-vitals\/largest-contentful-paint]Largest Contentful Paint (LCP)[\/url], que é um Core Web Vital considerado pelos motores de busca. Crawl budget: Os rastreadores dos motores de busca seguem redirects, o que significa que cada redirect consome orçamento de rastreamento adicional. Para sites grandes, isso pode retardar a descoberta de conteúdo novo ou atualizado. Como Medir Problemas de TTFB Causados por Redirects Para encontrar o impacto que os usuários reais experimentam causado por redirects, você precisará usar uma ferramenta RUM como o CoreDash. O Real User Monitoring permitirá que você acompanhe os Core Web Vitals com grande detalhe. No CoreDash, basta clicar em "redirect count" para visualizar seus dados segmentados por contagem de redirects. Então, por exemplo, clique no segmento "1 redirect" para filtrar os dados RUM por "1 redirect" e visualizar todas as URLs afetadas. Como Auditar seu Site para Redirects Uma auditoria sistemática de redirects envolve três etapas: Passo 1: Rastreie seu Site Use uma ferramenta de rastreamento (como MarketingTracer, Screaming Frog ou Sitebulb) para rastrear todo o seu site. O rastreador informará todas as URLs internas que respondem com um código de status 3xx. Exporte a lista e classifique pelo número de links internos de entrada que apontam para cada URL redirecionada. Passo 2: Identifique Cadeias de Redirect Filtre os resultados do rastreamento para qualquer URL que redirecione para outra URL que também redireciona. Essas cadeias devem ser corrigidas primeiro porque multiplicam a penalidade do TTFB. Passo 3: Corrija e Verifique Atualize seus links internos para apontar diretamente para a URL de destino final. Após atualizar os links, rastreie novamente para verificar se os redirects não são mais acionados pela navegação interna. Use o seguinte trecho de JavaScript para detectar redirects a partir do navegador: new PerformanceObserver((entryList) => { const [nav] = entryList.getEntriesByType('navigation'); if (nav.redirectCount > 0) { console.warn('Redirect detectado!', { redirectCount: nav.redirectCount, redirectTime: nav.redirectEnd - nav.redirectStart, finalUrl: nav.name }); } }).observe({ type: 'navigation', buffered: true }); Como Minimizar o Impacto de Redirects Como regra geral, siga estes 3 passos simples para evitar problemas de redirect: Minimize o uso de redirects sempre que possível. Evite cadeias de redirect atualizando os links para apontar diretamente para a URL de destino final. Use redirects de servidor em vez de redirects de cliente quando possível, pois eles são geralmente mais rápidos. Redirects de mesma origem (same origin). Redirects de mesma origem originam-se de links no seu próprio site. Você deve ter controle total sobre esses links e deve priorizar a correção desses links ao trabalhar no Time to First Byte. O método típico de encontrar esses redirects internos é usar qualquer uma das ferramentas disponíveis que permitirão verificar todo o seu site em busca de redirects. Redirects de origem cruzada (cross-origin). Redirects de origem cruzada originam-se de links em outros sites. Você tem muito pouco controle sobre eles. Para links de alto impacto que geram muito tráfego, considere entrar em contato com o webmaster do site para atualizar a URL vinculada. Cadeias de redirect. Múltiplos redirects ou cadeias de redirect ocorrem quando um único redirect não redireciona para o local final do recurso. Esses tipos de redirects colocam mais pressão no Time to First Byte e devem ser evitados a todo custo. Novamente, use uma ferramenta para encontrar esses tipos de redirects e corrigi-los. Redirects de HTTP para HTTPS e HSTS Redirects de HTTP para HTTPS são um dos tipos de redirect mais comuns. Cada visitante que digita seu domínio sem "https:\/\/" ou segue um link HTTP antigo experimentará um redirect 301. O cabeçalho Strict-Transport-Security (HSTS) elimina esse redirect para visitantes recorrentes, dizendo ao navegador para sempre usar HTTPS. Para ativar o HSTS, adicione o seguinte cabeçalho à resposta do seu servidor: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Aqui está o que cada diretiva significa: max-age=31536000: o navegador se lembrará de usar HTTPS para este domínio por um ano (31.536.000 segundos). includeSubDomains: aplica o requisito de HTTPS a todos os subdomínios também. preload: permite que seu domínio seja incluído na lista de pré-carregamento HSTS integrada do navegador, o que significa que mesmo a primeiríssima visita usará HTTPS sem um redirect. Para enviar seu domínio para a lista de pré-carregamento HSTS, visite hstspreload.org. Assim que seu domínio estiver na lista de pré-carregamento, os navegadores nunca farão uma requisição HTTP para o seu domínio, eliminando completamente o redirect de HTTP para HTTPS para todos os visitantes. No Apache, você pode adicionar HSTS com: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" No Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; Em geral, recomendamos: Verificar e atualizar regularmente seus links internos. Sempre que você alterar o local de uma página, atualize seus links internos para essa página para garantir que não restem referências ao local anterior da página. Lidar com redirects no nível do servidor. O método de redirect preferido é o redirect 301. Um redirect 301 é um redirect permanente, enquanto um redirect 302 é um redirect temporário. Redirects temporários, por exemplo, podem não ser atualizados nos motores de busca. Usar URLs relativas: ao criar links para páginas no seu próprio site, use URLs relativas em vez de URLs absolutas. Isso ajudará a evitar redirects desnecessários. Usar URLs canônicas: se você tiver várias páginas com conteúdo semelhante, use uma URL canônica para indicar a versão preferida da página. Isso ajudará a evitar conteúdo duplicado e redirects desnecessários. Leitura Adicional: Guias de Otimização Guias relacionados: [url=\/pagespeed\/103-early-hints]103 Early Hints[\/url]: reduza o TTFB percebido enviando dicas de recursos enquanto o servidor processa a resposta completa. [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Configurar a Cloudflare para Performance[\/url]: otimize sua configuração de CDN para reduzir cadeias de redirect e melhorar o TTFB global. Subpartes do TTFB: Guias Completos A waiting duration é uma das cinco subpartes do TTFB. Explore as outras subpartes para entender o quadro completo: [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]Identificar e Corrigir Problemas de TTFB[\/url]: o ponto de partida diagnóstico para toda otimização de TTFB. [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Cache Duration[\/url]: performance de service worker, pesquisas de cache do navegador e bfcache. [url=\/core-web-vitals\/time-to-first-byte\/dnsduration]DNS Duration[\/url]: seleção de provedor de DNS, configuração de TTL e dns-prefetch. [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection Duration[\/url]: TCP handshake, otimização de TLS, HTTP\/3 e preconnect. [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request Duration[\/url]: tempo de processamento do servidor, consultas ao banco de dados e otimização de backend. [include]sidebarcwv.html[\/include] [include]blogfooter.html[\/include]