Agora estou trabalhando em um projeto para um cliente. Este é um site de comércio eletrônico, por isso estou muito interessado em alguns aspectos do desempenho. Para começar, esses são vários indicadores que caracterizam a hora de carregar um site. Próximo - é a hora de início da renderização da página, o que é importante para os visitantes que, após entrar no site, desejam ver seu conteúdo o mais rápido possível (naturalmente, todos os visitantes do site se enquadram nessa categoria). Entre os indicadores de desempenho que me interessam, estão aqueles que refletem as especificidades das atividades do meu cliente. Por exemplo: "Com que rapidez a imagem principal do produto é carregada?" Uma análise de todos esses indicadores pode fornecer informações valiosas sobre o estado do projeto.
No entanto, há um indicador que, ao que parece, os desenvolvedores de front-end geralmente não prestam atenção suficiente. É hora do primeiro byte (Time to First Byte, TTFB). Você pode entender isso, e pode pelo menos perdoar parcialmente aos desenvolvedores essa atitude em relação ao TTFB, especialmente considerando o fato de eles verem esse indicador como algo que depende apenas do back-end dos projetos. Mas se tentarmos expressar literalmente brevemente o problema em relação a esse indicador, podemos dizer o seguinte: "Embora um bom valor TTFB não signifique necessariamente que o site que o demonstra possa ser considerado rápido, um indicador TTFB ruim certamente indica problemas com o desempenho do projeto".
Mesmo se levarmos em conta o fato de que o desenvolvedor front-end pode estar em uma posição em que ele não é capaz de influenciar independentemente o back-end e o TTFB, é importante levar em consideração o fato de que altos valores de TTFB podem afetar significativamente o desempenho do site. Como resultado, os esforços de um desenvolvedor front-end que se esforça pela velocidade do site se assemelham a um jogo de recuperação. Isso se aplica, por exemplo, à otimização de imagens e à minimização do volume de materiais que compõem as seções mais importantes do projeto e ao download de fontes da Web de forma assíncrona. Isso não quer dizer que, sabendo disso, você pode desistir e abandonar as otimizações de front-end. Mas se o TTFB for muito alto, todas essas otimizações lembram a tentativa de corrigir um problema em condições em que ele já causou dano e em que é tarde demais para corrigir esse problema. De fato, é por isso que é muito importante para quem está desenvolvendo o front-end monitorar de perto o indicador TTFB e é muito importante, quando seus valores são altos demais, tomar medidas para melhorá-lo.
O que é TTFB?
TTFB não parece muito informativo ( imagem em tamanho real )TTFB é um indicador que parece, para dizer o mínimo, opaco. Tanto é influenciado por ele que tenho a sensação de que estamos o tempo todo ignorando sua análise séria. Muitos especulam que o TTFB é apenas o tempo que o servidor leva para preparar uma resposta, mas, na verdade, é apenas uma pequena parte do que afeta o TTFB.
A primeira coisa que gostaria de chamar sua atenção é que, ao aprender o que as pessoas geralmente ficam muito surpresas. Estamos falando do fato de que o TTFB inclui o tempo que a solicitação do cliente passa pela rede para o servidor e o tempo que leva para o cliente o caminho de resposta do servidor. Este é o chamado "tempo de ida e volta" (RTT). TTFB não é apenas um tempo gasto pelo servidor preparando uma resposta. Também é o tempo gasto na maneira como os dados vão de cliente para servidor e de servidor para cliente (esses dados, é claro, contêm o “primeiro byte” de seu interesse).
Agora, armados com esse conhecimento, podemos entender facilmente o motivo pelo qual, ao visualizar sites a partir de dispositivos móveis, o indicador TTFB geralmente é indecentemente grande. É bem possível que, em situações anteriores, você tenha perguntado algo assim: "Tenho certeza de que o servidor não sabe que estou visualizando o site a partir de um celular. Como, então, aumenta o TTFB? ” A razão para isso é que, via de regra, as conexões de rede móvel são de alta latência. Se o indicador RTT, que reflete o tempo necessário para que os dados viajem do telefone para o servidor e retorne, seja, por exemplo, 250 ms, o TTFB aumentará no valor correspondente.
Se eu gostaria que os leitores desse material retirassem apenas uma idéia importante, formularia essa idéia da seguinte maneira: "Atrasos na rede afetam o TTFB".
O que mais afeta o TTFB? De fato - muito de tudo. Aqui está uma lista longe de ser completa do que contribui para a formação desse indicador. Os itens desta lista estão em ordem aleatória.
- Atrasos na rede. Como já mencionado, o TTFB inclui o tempo necessário para entregar uma solicitação ao servidor e retornar uma resposta do servidor. Pegue, por exemplo, o tempo necessário para uma sessão de troca de dados entre um dispositivo localizado em Londres e um servidor localizado em Nova York. Idealmente, ao usar uma conexão de fibra óptica, isso é 28 ms. Mas isso é baseado em muitas suposições muito otimistas. Na realidade, você deve esperar algo como 75 ms . É por isso que é tão importante usar a CDN. Mesmo agora, na era da Internet, a proximidade geográfica de uma determinada empresa e de seus clientes é uma vantagem.
- Encaminhamento Se você usa a CDN (e deve ser assim!), A solicitação do seu cliente, digamos, de Leeds, pode ser redirecionada apenas para o data center MAN, para que o recurso de que o cliente precisa não esteja no cache PoP correspondente. . Em seguida, a solicitação será redirecionada para o servidor real com seus materiais, a fim de transmitir ao cliente o que ele precisa. Se este servidor estiver localizado, por exemplo, na Virgínia, todos os itens acima levarão a um aumento sério no TTFB sem motivo aparente.
- Trabalhe com arquivos. Mesmo se o servidor simplesmente ler dados estáticos de seu sistema de arquivos, como imagens ou arquivos de estilo, leva algum tempo para concluir esta operação. Desta vez também faz parte do TTFB.
- Priorização O protocolo HTTP / 2 possui mecanismos para priorizar o processamento de solicitações. Como resultado, pode acontecer que as solicitações de baixa prioridade possam ser atrasadas no servidor, dando lugar a solicitações de alta prioridade. Mesmo que você não leve em consideração os mecanismos de priorização HTTP / 2 e assuma que tudo funciona sem problemas, esses atrasos esperados podem contribuir para o TTFB.
- Executando aplicativos. Na verdade, isso é bastante óbvio, mas eu gostaria de observar que o tempo necessário para executar os aplicativos do servidor afeta seriamente o TTFB.
- Consultas de banco de dados. Se você precisar solicitar algo do banco de dados para formar a página, o tempo para concluir essa operação também será incluído no TTFB.
- Chamadas de API Se dados de determinadas APIs (internas ou externas) forem necessários para preparar a página, as chamadas para essas APIs afetarão o TTFB.
- Renderização do servidor É bastante óbvio que a renderização do lado do servidor leva tempo, dessa vez é fácil de avaliar, mas isso não nega a contribuição dessa operação para o TTFB.
- Hospedagem barata. Se você usa hospedagem barata, tentando economizar o máximo possível e sacrificando o desempenho, isso geralmente significa que vários outros projetos usam o servidor no qual o seu projeto está localizado. Talvez uma quantidade considerável. Como resultado, alguém que usa hospedagem barata pode esperar uma queda no desempenho do servidor, o que pode afetar a capacidade do projeto de processar solicitações. De fato, estamos falando sobre o fato de que o poder do hardware do servidor não é suficiente para satisfazer as necessidades do aplicativo.
- Ataques DDoS, alta carga no projeto. Aqui continuamos o tópico discutido no parágrafo anterior desta lista. Nomeadamente, se a carga no servidor aumentar e o projeto não fornecer uma escalabilidade flexível das capacidades do servidor, isso levará ao fato de que o equipamento começa a trabalhar até o limite. E, como resultado, o desempenho do aplicativo diminui.
- WAF, balanceadores de carga. Serviços, como WAF ou balanceadores de carga localizados na frente do aplicativo do servidor, aumentam o TTFB.
- Alguns recursos da CDN. O uso de CDNs é um fator que certamente tem um efeito benéfico no TTFB, mas alguns recursos das CDNs podem piorar as coisas. Por exemplo, isso é solicitação dobrável , ESI , etc.
- Atrasos na "última milha". Quando falamos de um computador de Londres que acessa um servidor localizado em Nova York, geralmente simplificamos demais a situação, quase reduzindo-a ao fato de que o computador e o servidor estão conectados diretamente um ao outro. Mas, na realidade, tudo é muito mais complicado. O sinal entre o computador e o servidor passa por muitos intermediários. Nosso roteador envia para o provedor; de uma rede sem fio, ele entra em um cabo no fundo do oceano ... Atrasos na "última milha" incluem todas as dificuldades que impedem a transferência de dados entre dispositivos finais.
Um TTFB de 0 ms é um sonho. Portanto, é importante observar que nada na lista afeta sempre negativamente o TTFB ou sempre piora esse indicador. Esta lista é melhor entendida como uma descrição da estrutura TTFB de um projeto. Meu objetivo não é criticar determinadas tecnologias, mas mostrar como certas tecnologias podem influenciar o TTFB. E, para ser sincero, considerando o quanto as coisas acontecem antes que o cliente receba o primeiro byte da resposta do servidor, já é surpreendente que os sites geralmente estejam carregando.
Descobrindo o mistério com o TTFB
Agora, espero que o TTFB não pareça mais tão misterioso. E se você gastar um pouco de tempo na implementação do API
Server Timing , poderá começar a medir indicadores complicados de tempo do servidor e enviá-los para os sistemas clientes. Isso permitirá que os desenvolvedores da Web detectem e eliminem possíveis gargalos de desempenho que antes estavam ocultos.
A API de tempo do servidor permite que os desenvolvedores estendam as respostas da consulta com o cabeçalho HTTP opcional
Server-Timing servidor. Ele contém informações de tempo medidas pelo próprio aplicativo.
Foi esse mecanismo que usamos no ano passado quando trabalhamos no BBC iPlayer.
Um novo cabeçalho de tempo do servidor pode ser adicionado a qualquer resposta ( imagem em tamanho real )
Observe que o tempo do servidor também causa estresse no sistema. No decorrer de seu trabalho, você precisa medir os indicadores relevantes e preencher o cabeçalho de
Server-Timing do
Server-Timing . O navegador permite apenas que o desenvolvedor front-end visualize esses dados usando as ferramentas apropriadas.
Agora, no navegador, você pode ver a estrutura TTFB ( imagem em tamanho normal )Se você deseja implementar a API de sincronização do servidor, consulte
este material .
Sumário
É muito importante que os desenvolvedores da Web entendam até que ponto o TTFB afeta o que eles chamam de "desempenho do site". O tempo para o primeiro byte é uma certa fronteira, após o cruzamento, sobre o qual podemos falar sobre otimização de sites. Quanto menor esse indicador, melhor.
Caros leitores! Você otimiza seus projetos da web com o TTFB?
