
Todo mundo quer um site rápido. Isso significa que sua página deve ser processada rapidamente. O ideal é que você alcance o tempo para a primeira interação em 1-3 segundos.
A pesquisa psicológica mostra que você realmente tem 1 segundo ou 1000ms segundos para começar a renderizar antes que a mente humana comece a perceber a latência e a aumentar a ansiedade. Como estudo após estudo mostra que os usuários finais desejam sites rápidos, Google, Bing e mecanismos de pesquisa medem a eficiência do carregamento da página como um sinal de classificação do mecanismo de pesquisa.
Obviamente, se a marcação da página não chegar ao navegador rapidamente, o restante dos ativos não poderá ser carregado.
Este tempo é chamado de tempo para primeiro byte e é uma medida de quanto tempo leva para os primeiros bits chegarem ao navegador da solicitação inicial ao servidor.
O TTFB é uma métrica muito importante porque o navegador não pode começar a renderizar o conteúdo até que tenha o marcação. A marcação da página contém referências a recursos externos como scripts, CSS, imagens, fontes, etc. Uma resposta lenta do servidor pode ser matadora.
No mundo on-line de hoje, uma pergunta-chave que você deve fazer é se esta é uma importante métrica de desempenho para medir? Ainda é relevante?
O que vou ensinar a você hoje é o que é o tempo para o primeiro byte (TTFB), por que é importante, como você pode medir o TTFB.
Ao longo do caminho Vou revisar como isso é relevante no mundo de hoje e como sua importância mudou.
Também vou oferecer algumas orientações que você pode aplicar aos seus servidores para ajudar a melhorar o seu tempo de primeiro byte.
Qual é a hora do primeiro byte?
Tempo até o primeiro byte ou TTFB é a quantidade de tempo gasto esperando pela resposta inicial. Em termos técnicos, é a latência de uma viagem de ida e volta para e do servidor.
É um indicador importante de desempenho a ser rastreado porque indica a velocidade ou lentidão do servidor. Se você tiver um TTFB ruim, precisará ajustar o servidor.
Embora as latências da rede afetem o tempo até o primeiro byte, geralmente a latência é introduzida devido às ineficiências do servidor. Você deseja que a latência da rede seja a maior parte do seu tempo para o primeiro byte, porque indica que seu servidor está otimizado.
É assim que 84 Lumber desperdiçou milhões em sua campanha publicitária do Super Bowl de 2017 , bem, isso e seus anúncios eram estranhos.
Seus o servidor estava mal otimizado, mesmo quando não estava sendo pressionado em resposta ao anúncio. Testei meus resultados alguns dias antes do jogo. O TTFB médio que encontrei em seu site era de mais de 30 segundos. E pior, quando o comercial foi ao ar, o servidor travou.
Por mais que você queira pensar que controla a rede, na verdade não controla. As solicitações são roteadas por diferentes roteadores de Internet em todo o lugar, como um pinball, entre o cliente e o servidor.
A distância e a velocidade da rede do cliente influenciam mais a latência da rede do que o data center. É realmente a última milha e, acredite, você não tem controle sobre isso.

Qualquer ferramenta confiável de medição de desempenho da web revelará as diferentes etapas no tempo integral para o primeiro byte. Isso inclui o seguinte:
- Tempo para iniciar a conexão
- Pesquisa DNS
- Negociação SSL
- Tempo para o primeiro byte ( tempo necessário para o servidor começar a enviar a resposta)
Ainda existem muitos sites com configurações de servidor ruins e medir e rastrear TTFB é uma métrica chave para garantir que seus servidores estejam funcionando com eficiência.
Você pode ter tudo otimizado e uma nova implantação apenas bagunça tudo. Se você tiver um teste automatizado, reconhecerá o problema rapidamente e será capaz de responder.
O Google sugere um tempo de 200 ms ou menos para o primeiro byte. Os 200 ms é o tempo para os primeiros bytes da resposta atingirem o navegador, sem a latência da rede. Isso significa o ciclo de renderização do seu servidor.
A regra de ouro do desempenho-ainda é de ouro?
O que parece ter sido décadas atrás, Steve Souders definiu a regra de ouro do desempenho da web como 80% de uma web os problemas de desempenho das páginas eram devidos à arquitetura do lado do cliente e 20% de preocupações do lado do servidor. Este foi o principal locatário dos Sites de alto desempenho de Steve, um livro que considero um dos os livros de desenvolvimento web mais importantes de todos os tempos.
Sério, este livro mudou a maneira como vejo o desenvolvimento web e provavelmente teve mais influência sobre minha trajetória de carerr do que qualquer outra referência.
Steve tem’saiu’da proporção 80/20 porque o celular é a plataforma dominante hoje e o JavaScript Dynamic. Nos últimos anos, ele modificou a proporção para 95/5.
Os 5% é o papel que o TTFB desempenha no tempo geral que leva para renderizar uma página típica.
Por que ?
As páginas da web de hoje são pilhas enormes de JavaScript, o que torna tudo mais lento.

Em um artigo recente onde Steve avalia o impacto do JavaScript, especialmente scripts de terceiros, no ciclo geral de renderização da página, ele isola JavaScript como o gargalo principal.
JavaScript é a principal causa para tornar os sites lentos. Dez anos atrás eram gargalos de rede, mas o crescimento do JavaScript ultrapassou as melhorias de rede e CPU nos dispositivos de hoje.
Observe como ele afirma’10 anos atrás’? Foi mais ou menos quando o livro foi publicado, exatamente quando o JavaScript estava ganhando popularidade.
Vou até mesmo voltar aos sites de alto desempenho e citar a seguinte declaração profética:
existe mais potencial para melhorias no foco no front-end. Se pudéssemos cortar os tempos de resposta do back-end pela metade, o tempo de resposta do usuário final diminuiria apenas 5-10% no geral. Se, em vez disso, reduzíssemos o desempenho do front-end pela metade, reduziríamos os tempos de resposta gerais em 40-45%.
Então, mesmo então, Steve estava dizendo que o tempo para o primeiro byte não é importante ?
Bem, não, mas a oportunidade de realmente melhorar a experiência do usuário e vencer a concorrência está realmente em melhorar o seu front-end ou o que o navegador compila na página renderizada.
No entanto, ainda vejo que a grande maioria dos desenvolvedores não consegue entender por que essa regra é verdadeira e ainda concentra seus esforços nas otimizações do lado do servidor.
Não me interprete mal, o desempenho do lado do servidor é importante, mas é um ambiente diferente do cliente. É muito mais controlável. Isso significa que deve ser mais fácil obter ganhos de desempenho ajustando seu servidor do que a maioria dos front-ends hoje.
O impacto não será grande.
Com isso dito, se o HTML e outros recursos da página demoram a atravessar a rede, seu site nunca será renderizado.
O usuário simplesmente sairá.
Se sua página não for percebida como renderizada em 3 segundos 50 % dos visitantes irão embora. A pesquisa do Google DoubleClick mostrou 53% de rejeição de uma página se eles não acham que foi renderizado em 3 segundos.
Um tempo de 3 segundos para o primeiro byte significa que você pode dizer adeus ao seu tráfego.
Então, como você pode medir o tempo para o primeiro byte e como você pode melhorar seu tempo?
Medindo o tempo até o primeiro byte
A primeira etapa para qualquer campanha de otimização de desempenho na web é medir tudo. O primeiro lugar que eu começo é coletando uma cascata de rede.
** Observação: você pode fazer isso executando um site localhost, mas só obterá testes de dados reais em um servidor da web real. **
Isso pode ser feito usando as ferramentas de desenvolvedor F12 do seu navegador. Cada navegador tem uma guia de rede, na qual uma página é carregada registra cada solicitação de rede e exibe um gráfico, que chamamos de cascata.

Ao selecionar a primeira solicitação, que seria para o HTML da sua página, você pode obter mais detalhes sobre a solicitação e a resposta. Você deve selecionar a guia de tempo.
Como você pode ver, o tempo real para o primeiro byte é uma combinação de etapas.
- Parado
- Busca DNS
- Conexão inicial
- Negociação SSL
- Tempo para o primeiro byte
Para que o documento completo seja carregado também deve incluir o valor carregado do conteúdo. Somente depois de concluir a etapa Conteúdo carregado, o navegador pode analisar o documento e começar a solicitar recursos adicionais.
Se o tempo médio para o primeiro byte for 500 ms ou mais, você precisará de otimizações do lado do servidor. Os gargalos comuns incluem consultas de banco de dados e servidores da web mal otimizados. Recomendamos o uso de um banco de dados NoSQL ou serviço de cache de front-end como MongoDB, Rediis ou um dos serviços hospedados em nuvem.
Existem muitos outros lugares que você pode otimizar. Mas você precisa entender como o servidor compõe o HTML que serve.
Como o servidor compõe uma resposta
Um servidor perfeito responde instantaneamente, deixando apenas a latência da rede para retardar a resposta.
A realidade é que o servidor tem muitos processos que devem ser executados para renderizar a marcação antes de enviá-la pelo cabo. Isso pressupõe que seu servidor precisa renderizar a marcação cada vez que o recurso é solicitado.
Você pode pensar nesses processos como um atrito necessário. A menos que a página de destino seja HTML estático, o que é mais comum hoje, você tem pelo menos dois processos primários, recuperação de dados e pipeline de renderização.

Para entender o que o servidor faz, quero examinar dois cenários, conteúdo estático e dinâmico.
Conteúdo estático é simplesmente retornar um arquivo sem qualquer renderização, do jeito que está. Isso normalmente significa que você tem um arquivo index.html em uma pasta. Eu uso um fluxo de trabalho da função AWS Lambda usando Nodejs hoje em dia para pré-renderizar meus arquivos HTML e servi-los via CloudFront usando AWS S3 como a origem do CDN.
Ok, isso pode ter ficado um pouco técnico demais, mas eu queria esclarecer que os sites estáticos são o que eu recomendo hoje. Isso ocorre porque os mecanismos de renderização sob demanda exigem muita sobrecarga quando a velocidade da página é crítica.
Outros arquivos estáticos incluem CSS, JavaScript, imagens, vídeos e fontes.
Dinâmico envolve um processo de composição , conhecido como renderização. Normalmente, isso significa examinar a rota de solicitação, string de consulta, cabeçalhos, possivelmente cookies, etc. e construir a resposta.
Normalmente, o processo do servidor também precisará acessar um armazenamento de dados (banco de dados) diretamente ou por meio de serviços da web. É por isso que o conteúdo dinâmico costuma demorar mais para retornar do que o estático. Se você adicionar a compactação, que afeta tanto o conteúdo estático quanto o dinâmico, você terá outra etapa que o servidor precisa realizar antes que qualquer coisa seja servida.
As pilhas de servidor dinâmico incluem ASP.NET, Java Server Pages, Ruby, Express , PHP, etc. A maioria das plataformas CMS, como o WordPress, opera usando essa metodologia.
O WordPress é um ótimo exemplo. Freqüentemente, os proprietários de sites ficam entusiasmados demais com plug-ins e exageram. Freqüentemente, instalam muitos plug-ins bem como plug-ins mal escritos. Você deve auditá-los regularmente para garantir que estejam atualizados e agreguem valor real ao seu site.
Essas pilhas geralmente são hospedadas em servidores da web como IIS, Apache, NGINX, Websphere, etc. ASP. NET tem mais de 20 eventos separados em seu pipeline de renderização antes mesmo de você considerar os modelos de navalha (MVC) usados para definir a marcação para renderizar em um modelo de dados.

Como fazer mprove Tempo para o primeiro byte
Para quase todos os mecanismos de renderização, não apenas você renderiza com base nos dados recuperados, o mecanismo também deve compor a marcação de vários arquivos, geralmente chamados de includes.
Isso pode ser o shell do aplicativo principal, um ou mais layouts filhos e componentes de IU individuais.
Sempre que os processos do servidor precisam de um arquivo, eles devem realizar I/O de disco para recuperar o conteúdo antes de compor a resposta. E/S de disco é caro, mesmo em unidades SSD modernas. Um bom exemplo de como esse efeito pode ser amplificado revise o estudo de caso de escalabilidade do Instagram e veja como não ter um favicon fazia com que seus servidores travassem devido à sobrecarga de disco.
Um servidor da web configurado corretamente tentará armazenar em cache tanto quanto pode na memória e servir a resposta do cache em vez de acertar o disco e executar o processo de renderização. ASP.NET utiliza um recurso chamado Cache de saída para habilitar o controle de cache granular. Ele funciona armazenando em cache o produto final renderizado na memória. Você pode até designar partes de uma página para serem armazenadas em cache na memória, enquanto outras podem ser dinâmicas.
Os desenvolvedores podem controlar como o Cache de Saída funciona correlacionando objetos armazenados em cache por valores de cabeçalho, parâmetros de string de consulta, linguagem etc. Isso é útil porque uma página pode ser composta por muitos parâmetros diferentes, portanto, oferece o cenário mais flexível. Quando o servidor da web pode evitar atingir o disco e o processo de composição bruto, ele pode fornecer a resposta muito mais rápido.
Quando o servidor está compondo uma resposta e precisa aguardar uma consulta lenta ao banco de dados (por exemplo) a resposta fica atrasada. Em vez disso, você deve tentar liberar qualquer conteúdo que não dependa da consulta ao banco de dados. Novamente, a maioria das plataformas oferece algum tipo de mecanismo de liberação de resposta.
Por exemplo, o PHP oferece o função ob_flush . Este recurso parecia estar faltando na ASP.NET MVC, então meu amigo Nik Molnar criou Cortesia Flush para habilitar essa funcionalidade.
Ao liberar conteúdo, você está enviando bytes iniciais, enquanto mantém a conexão e o processo ativos para conteúdo adicional. O conteúdo inicial deve incluir CSS e quaisquer scripts para começar a construir a página. Criar uma boa liberação inicial de conteúdo é uma arte, então provavelmente você precisará experimentar para otimizar isso.
É claro que você sempre pode procurar reduzir seus tempos de acesso a dados e serviços. Este é um dos motivos pelos quais bancos de dados de documentos como Elastic Search, MongoDB, DynamoDB e Cosmos se tornaram populares.
7 maneiras de melhorar seu tempo para o primeiro byte
- Use um pré-Rendered Static Website
- Use uma Content Delivery Network
- Otimize o processo de renderização da página (ASP.NET, PHP, Express, etc)
- Otimize as consultas de banco de dados
- Use um banco de dados de documentos
- Cache de ativos dinâmicos na memória
- Libere conteúdo renderizado enquanto espera por conteúdo adicional
Eles permitem aplicativos para reduzir a sobrecarga do banco de dados, eliminando consultas. Em vez disso, eles aproveitam os dados desnormalizados, nos quais os resultados da consulta conhecidos são armazenados antecipadamente em um estado de recuperação rápida. Em vez de compor uma instrução SQL complicada, um banco de dados de documentos depende de você solicitar um registro ou conjunto de registros por um índice simples. Esta solução fornece um tempo de resposta muito rápido e elimina o banco de dados relacional tradicional do pipeline de serviço da Web.
Se você precisar consultar um banco de dados relacional, certifique-se de que essas consultas estejam otimizadas. Não posso dizer com que frequência encontro procedimentos armazenados mal escritos ou índices ausentes que fazem com que a solicitação SQL de alta demanda leve minutos em vez de milissegundos.
Outras etapas que você pode realizar incluem o uso de rede de entrega de conteúdo (CDN) . Freqüentemente, você pode usar um CDN como um cache de front-end que também distribui seu conteúdo mais perto dos usuários.
Vamos encerrar
O tempo para o primeiro byte é a métrica de velocidade de página mais comum medido por desenvolvedores e profissionais de marketing. Embora importante, é apenas uma pequena parte do perfil de carregamento da página da web moderna.
Para melhorar seu tempo para o primeiro byte, você deve otimizar o processo de renderização do servidor. Eu recomendo migrar para um site estático onde a marcação é pré-renderizada e usar uma pequena quantidade de JavaScript para compor alguns aspectos dinâmicos na maioria das páginas.
No momento, o TTFB é responsável por 5% ou menos do carregamento de uma página tempo devido à quantidade excessiva de JavaScript consumida pela maioria das páginas da web. Mas um momento ruim para o primeiro byte significa que nem mesmo sua marcação inicial está disponível para o navegador iniciar o processo de renderização do lado do cliente.
Você deve ter como objetivo 500 ms ou menos para o primeiro byte em uma conexão de alta velocidade e 1 segundo ou menos sobre 3G. Isso lhe dá a chance de tornar sua página interativa nos 3 segundos que os consumidores permitem antes de saltar de sua página.