Estou trabalhando em um projeto de cliente no momento e, como eles são um site de comércio eletrônico, há muitas facetas de desempenho que estou interessado em procurá-las: os tempos de carregamento são um bom começo, a renderização é a chave para clientes que desejam ver as informações rapidamente (sugestão: são todas elas) e métricas específicas do cliente, como a rapidez com que a imagem principal do produto carregou? todos podem fornecer informações valiosas.
No entanto, uma métrica que sinto que os desenvolvedores de front-end ignoram muito rapidamente é o Time to First Byte (TTFB). Isso é compreensível – perdoável, quase – quando você considera que o TTFB começa a se mover para o território de back-end, mas se eu fosse resumir o problema da forma mais sucinta possível, eu diria:
Embora um bom TTFB não signifique necessariamente que você tenha um site rápido, um TTFB ruim certamente garante um site lento.
Mesmo que, como um desenvolvedor de front-end, você não esteja em condições de fazer melhorias no TTFB, é importante saber que qualquer problema com um TTFB alto deixará você para trás, e qualquer esforço que você fizer para otimizar imagens, limpar o caminho crítico e carregar de forma assíncrona seus webfonts serão todos feitos no espírito de reproduzir o catchup. Isso não quer dizer que mais otimizações orientadas para o front-end devam ser perdidas, mas infelizmente há um ar de fechar a porta do estábulo depois que o cavalo for aparafusado . Você realmente quer esmagar os erros TTFB assim que você puder.
O que é o TTFB?
TTFB é um pouco opaco para dizer o mínimo. É composto por tantas coisas diferentes que muitas vezes acho que tendemos a encobrir isso. Muitas pessoas supõem que o TTFB é meramente tempo gasto no servidor, mas isso é apenas uma pequena fração da verdadeira extensão das coisas.
A primeira – e muitas vezes mais surpreendente para as pessoas aprenderem – é uma coisa que quero chamar sua atenção é que o TTFB conta uma latitude de ida e volta . O TTFB não é apenas o tempo gasto no servidor, é também o tempo gasto indo do nosso dispositivo para o servidor e vice-versa (carregando, isso mesmo, o primeiro byte de dados!).
Munidos desse conhecimento, logo podemos entender por que o TTFB pode aumentar de forma tão drástica nos dispositivos móveis. Certamente, você já se perguntou antes, o servidor não faz ideia de que estou em um dispositivo móvel – como ele pode aumentar seu TTFB? A razão é porque as redes móveis são, via de regra, conexões de alta latência. Se o seu Tempo de ida e volta (RTT) do seu telefone para um servidor e vice-versa for, digamos, 250 ms, você verá imediatamente um aumento correspondente no TTFB.
Se há uma coisa importante que eu gostaria que você tirasse desse post, é que o TTFB é afetado pela latência .
Mas o que mais é o TTFB? Prenda-se; Aqui está uma lista não exaustiva apresentada em nenhuma ordem particular:
- Latência: como acima, estamos contando com uma viagem e uma viagem de retorno do servidor. Uma viagem de um dispositivo em Londres para um servidor em Nova York tem uma velocidade teórica de 28ms em fibra, mas isso faz muitas suposições muito otimistas. Espere mais perto de 75ms .
- É por isso que servir o seu conteúdo a partir de um CDN é tão importante: mesmo na era da internet, estar geograficamente mais perto de seus clientes é vantajoso.
- Roteamento: Se você estiver usando um CDN – e você deve estar! – um cliente em Leeds pode ser roteado para o datacenter MAN apenas para descobrir que o recurso que está solicitando não está no cache desse PoP . Assim, eles serão roteados todo o caminho de volta ao seu servidor de origem para recuperá-lo de lá. Se a sua origem estiver em, digamos, Virgínia, isso será um aumento grande e invisível no TTFB.
- Leituras do sistema de arquivos: O servidor que simplesmente lê arquivos estáticos, como imagens ou syleheets, do sistema de arquivos tem um custo. Tudo é adicionado ao seu TTFB.
- Priorização: O HTTP / 2 possui um mecanismo de (re) priorização, pelo qual pode optar por interromper as respostas de prioridade mais baixa no servidor, enquanto envia respostas de prioridade mais alta para o fio. Questões de priorização de H / 2 à parte, mesmo quando o H / 2 está funcionando sem problemas, esses atrasos esperados irão contribuir para o seu TTFB.
- Tempo de execução do aplicativo: é realmente óbvio, mas o tempo necessário para executar o código real do aplicativo será um grande contribuinte para o TTFB.
- Consultas de banco de dados: as páginas que exigem dados de um banco de dados incorrerão em um custo ao pesquisar sobre ele. Mais TTFB.
- Chamadas de API: se você precisar chamar qualquer API (interna ou não) para preencher uma página, a sobrecarga será contada no seu TTFB.
- Renderização no lado do servidor : O custo de renderização do servidor de uma página pode ser trivial, mas ainda contribuirá para o seu TTFB.
- Hospedagem barata: hospedagem otimizada para custo versus desempenho geralmente significa que você está compartilhando um servidor com qualquer número de outros sites, portanto espere um desempenho de servidor degradado que possa afetar sua capacidade de atender a solicitações ou simplesmente usar um hardware fraco tentando executar seu aplicação.
- DDoS ou carga pesada: no mesmo sentido do ponto anterior, o aumento de carga sem a necessidade de dimensionar automaticamente o aplicativo levará a um desempenho degradado, no qual você começará a investigar os limites de sua infraestrutura.
- WAFs e balanceadores de carga: serviços como firewalls de aplicativos da Webou balanceadores de carga que ficam à frente de seu aplicativo também contribuem para o seu TTFB.
- Recursos do CDN: Embora um CDN seja uma grande vitória líquida, em determinados cenários, seus recursos podem levar a um TTFB adicional. Por exemplo, solicite o recolhimento , inclusões do lado da borda , etc.).
- Latência de última milha: Quando pensamos em um computador em Londres visitando um servidor em Nova York, tendemos a simplificar muito essa jornada de forma bastante drástica, quase imaginando que as duas estavam diretamente conectadas. A realidade é que há uma série muito mais complexa de intermediários de nosso próprio roteador para nosso ISP; de uma torre de celular a um cabo submarino. A latência da última milha lida com a complexidade desproporcional em relação ao término de uma conexão.
É impossível ter um TTFB de 0ms, por isso é importante notar que a lista acima não representa coisas que são necessariamente ruins ou que diminuem o seu TTFB. Em vez disso, seu TTFB representa qualquer número dos itens apresentados acima. Meu objetivo aqui não é apontar os dedos para qualquer parte específica da pilha, mas sim ajudá-lo a entender o que exatamente o TTFB pode acarretar. E com tanto potencial acontecendo em nossa fase TTFB, é quase um milagre que os sites carreguem!
Assim. Muito de. Coisa!
Desmistificando o TTFB
Felizmente, nem tudo é tão claro! Com um pouco de trabalho extra gasto na implementação da Server Timing API , podemos começar a medir e exibir intrincados timings no front-end, permitindo que os desenvolvedores da Web identifiquem e depurem possíveis gargalos anteriormente ocultados da visualização.
A Server Timing API permite que os desenvolvedores aumentem suas respostas com um Server-Timingcabeçalho HTTP adicional que contém informações de tempo que o aplicativo mediu.
Isso é exatamente o que fizemos no BBC iPlayer no ano passado:
NB Server Timing não vem de graça: você precisa realmente medir os aspectos listados acima e depois preencher o seu Server-Timingcabeçalho com os dados relevantes. Tudo o que o navegador faz é exibir os dados no ferramental relevante, disponibilizando-o no front-end:
Para ajudar você a começar, Christopher Sidebottom escreveu sua implementação da Server Timing API durante nosso tempo otimizando o iPlayer.
É vital que entendamos exatamente o que o TTFB pode cobrir e o quão crítico ele pode ser para o desempenho geral. TTFB tem efeitos colaterais, o que pode ser uma coisa boa ou ruim, dependendo de estar começando com baixo ou alto.
Se você for lento fora do portão, você passará o resto da corrida jogando catchup.