Considerações gerais de desempenho de HTML

A primeira etapa para criar um site com carregamento rápido é receber uma resposta oportuna do servidor para o HTML de uma página. Quando você insere um URL na barra de endereço do navegador, ele envia uma GET ao servidor para recuperá-lo. A primeira solicitação de uma página da Web é para um recurso HTML, e garantir que o HTML chegue rapidamente com atrasos mínimos é uma meta de desempenho fundamental.

Essa solicitação inicial de HTML passa por várias etapas, cada uma levando algum tempo. Reduzir o tempo gasto em cada etapa resulta em um tempo para o primeiro byte (TTFB) mais rápido. Embora o TTFB não seja a única métrica em que você deve se concentrar quando se trata da velocidade de carregamento das páginas, um TTFB alto dificulta o alcance dos limites "bons" designados para métricas como Maior exibição de conteúdo (LCP) e First Contentful Paint (FCP).

Minimizar redirecionamentos

Quando um recurso é solicitado, o servidor pode responder com um redirecionamento, seja permanente (uma resposta 301 Moved Permanently) ou temporário (uma resposta 302 Found).

Os redirecionamentos diminuem a velocidade de carregamento da página porque exigem que o navegador faça uma solicitação HTTP adicional no novo local para recuperar o recurso. Há dois tipos de redirecionamentos:

  1. Redirecionamentos de mesma origem que ocorrem totalmente na sua origem. Esses tipos de redirecionamentos estão totalmente sob seu controle, já que a lógica para gerenciá-los reside inteiramente no seu servidor da Web.
  2. Redirecionamentos entre origens iniciados por outra origem. Esses tipos de redirecionamentos geralmente estão fora do seu controle.

Os redirecionamentos de origem cruzada são usados com frequência por anúncios, serviços de encurtamento de URL e outros serviços de terceiros. Embora os redirecionamentos de origem cruzada estejam fora do seu controle, talvez seja interessante verificar se você evita vários redirecionamentos. Por exemplo, ter um anúncio que vincula a uma página HTTP que, por sua vez, redireciona para o equivalente HTTPS ou um redirecionamento de origem cruzada que chega à sua origem, mas aciona um redirecionamento de mesma origem.

Armazenar em cache respostas HTML

É difícil armazenar em cache respostas HTML, já que elas podem incluir links para outros recursos críticos, como CSS, JavaScript, imagens e outros tipos de recursos. Esses recursos podem incluir uma impressão digital exclusiva nos respectivos nomes de arquivo, que mudam de acordo com o conteúdo de um arquivo. Isso significa que seu documento HTML em cache pode ficar desatualizado após uma implantação, já que ele contém referências a sub-recursos desatualizados.

No entanto, um tempo de vida curto do cache, em vez de nenhum cache, pode ter benefícios, como permitir que um recurso seja armazenado em cache em uma CDN, reduzindo o número de solicitações atendidas pelo servidor de origem, e no navegador, permitindo que os recursos sejam revalidados em vez de baixados novamente. Essa abordagem funciona melhor para conteúdo estático que não muda em nenhum contexto, e um tempo adequado para armazenar em cache os recursos pode ser definido como um número de minutos que você considerar adequado. Cinco minutos para recursos HTML estáticos é uma aposta segura e garante que as atualizações periódicas não passem despercebidas.

Se o conteúdo HTML de uma página for personalizado de alguma forma, como para um usuário autenticado, provavelmente não será interessante armazenar em cache o conteúdo por vários motivos, incluindo segurança e atualização. Se uma resposta HTML for armazenada em cache pelo navegador do usuário, não será possível invalidar o cache. Portanto, é melhor evitar o cache de HTML nesses casos.

Uma abordagem cautelosa para o armazenamento em cache de HTML pode ser usar os cabeçalhos de resposta ETag ou Last-Modified. Um cabeçalho ETag, também conhecido como tag de entidade, é um identificador que representa exclusivamente o recurso solicitado, geralmente usando um hash do conteúdo do recurso:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Sempre que o recurso mudar, um novo valor de ETag precisará ser gerado. Em solicitações subsequentes, o navegador envia o valor ETag pelo cabeçalho de solicitação If-None-Match. Se o ETag no servidor corresponder ao enviado pelo navegador, o servidor responderá com uma resposta 304 Not Modified, e o navegador usará o recurso do cache. Embora isso ainda cause latência de rede, uma resposta 304 Not Modified é muito menor do que um recurso HTML inteiro.

No entanto, a latência de rede envolvida na revalidação da atualização de um recurso ainda é uma desvantagem. Como em muitos outros aspectos do desenvolvimento da Web, as compensações e concessões são inevitáveis. Cabe a você decidir se o esforço adicional para armazenar em cache o HTML dessa forma vale a pena ou se é melhor não se preocupar com o armazenamento em cache de conteúdo HTML.

Medir os tempos de resposta do servidor

Se uma resposta não for armazenada em cache, o tempo de resposta do servidor vai depender muito do provedor de hospedagem e da pilha de aplicativos de back-end. Uma página da Web que veicula uma resposta gerada dinamicamente, como buscar dados de um banco de dados, por exemplo, pode ter um TTFB maior do que uma página da Web estática que pode ser veiculada imediatamente sem um tempo de computação significativo no back-end. Mostrar um spinner de carregamento e buscar todos os dados no lado do cliente move o esforço de um ambiente mais previsível do lado do servidor para um ambiente potencialmente imprevisível do lado do cliente. Minimizar o esforço do lado do cliente geralmente resulta em métricas aprimoradas centradas no usuário.

Se os usuários estiverem enfrentando um TTFB lento no campo, você poderá expor informações sobre onde o tempo foi gasto no servidor usando o cabeçalho de resposta Server-Timing:

Server-Timing: auth;dur=55.5, db;dur=220

O valor de um cabeçalho Server-Timing pode incluir várias métricas, além de uma duração para cada uma delas. Esses dados podem ser coletados dos usuários em campo usando a API Navigation Timing e analisados para verificar se os usuários estão enfrentando atrasos. No snippet de código anterior, o cabeçalho da resposta inclui duas marcações de tempo:

  • O tempo para autenticar um usuário (auth), que levou 55,5 milissegundos.
  • O tempo de acesso ao banco de dados (db), que levou 220 milissegundos.

Revise também sua infraestrutura de hospedagem e confirme se você tem recursos adequados para lidar com o tráfego que seu site está recebendo. Os provedores de hospedagem compartilhada geralmente são suscetíveis a um TTFB alto, e as soluções dedicadas que oferecem tempos de resposta mais rápidos podem ser mais caras.

Compactação

Respostas baseadas em texto, como HTML, JavaScript, CSS e imagens SVG, precisam ser compactadas para reduzir o tamanho da transferência pela rede e serem baixadas mais rapidamente. Os algoritmos de compactação mais usados são gzip e Brotli. O Brotli resulta em uma melhoria de cerca de 15% a 20% em relação ao gzip.

A compactação geralmente é configurada automaticamente pela maioria dos provedores de hospedagem na Web, mas há algumas coisas importantes a considerar se você estiver em uma posição para configurar ou ajustar as configurações de compactação por conta própria:

  1. Use o Brotli sempre que possível. Como mencionado anteriormente, o Brotli oferece uma melhoria bastante perceptível em relação ao gzip, e ele é compatível com todos os principais navegadores. Use o Brotli sempre que possível, mas se o site for usado por um grande número de usuários em navegadores legados, use o gzip como alternativa, já que qualquer compactação é melhor do que nenhuma.
  2. O tamanho do arquivo é importante. Recursos muito pequenos (menos de 1 KiB) não são compactados muito bem ou às vezes nem são compactados. A eficácia de qualquer tipo de compactação de dados depende de uma grande quantidade de dados com que um algoritmo de compactação possa trabalhar para encontrar bits de dados mais compactáveis. Quanto maior o arquivo, melhor a compactação funciona. No entanto, não envie recursos muito grandes apenas porque eles podem ser compactados de forma mais eficaz. Recursos grandes, como JavaScript e CSS, levam muito mais tempo para serem analisados e avaliados depois que o navegador os descompacta. Eles podem mudar com mais frequência, mesmo que tenham mudado marginalmente, já que qualquer mudança resulta em um hash de arquivo diferente.
  3. Entenda a diferença entre compactação dinâmica e estática. A compressão dinâmica e estática são abordagens diferentes para quando um recurso deve ser comprimido. A compactação dinâmica compacta um recurso no momento em que ele é solicitado e, às vezes, sempre que ele é solicitado. Por outro lado, a compressão estática compacta arquivos antes do tempo, sem exigir que a compressão seja realizada no momento da solicitação. A compactação estática remove a latência envolvida na compactação, o que pode aumentar os tempos de resposta do servidor no caso da compactação dinâmica. Recursos estáticos, como JavaScript, CSS e imagens SVG, precisam ser compactados de forma estática. Já os recursos HTML, principalmente se forem gerados dinamicamente para usuários autenticados, precisam ser compactados de forma dinâmica.

Fazer a compressão por conta própria é difícil. Geralmente, é melhor deixar que uma rede de fornecimento de conteúdo (CDN), que será abordada na próxima seção, faça isso por você. No entanto, conhecer esses conceitos pode ajudar você a discernir se o provedor de hospedagem está usando a compactação corretamente. Esse conhecimento pode ajudar você a encontrar oportunidades para melhorar as configurações de compactação e gerar o máximo de benefícios para seu site.

Redes de fornecimento de conteúdo (CDNs)

Uma rede de fornecimento de conteúdo (CDN) é uma rede distribuída de servidores que armazenam recursos em cache do seu servidor de origem e, por sua vez, os fornecem de servidores de borda que estão fisicamente mais próximos dos seus usuários. A proximidade física dos seus usuários reduz o tempo de ida e volta (RTT), enquanto otimizações como HTTP/2 ou HTTP/3, armazenamento em cache e compactação permitem que a CDN veicule conteúdo mais rapidamente do que se ele fosse buscado do servidor de origem. Usar uma CDN pode melhorar significativamente o TTFB do seu site em alguns casos.

Teste seus conhecimentos

Qual tipo de redirecionamento está totalmente sob seu controle?

Um redirecionamento de mesma origem.
Um redirecionamento de origem cruzada.

O cabeçalho Server-Timing pode conter várias métricas.

Falso
Verdadeiro.

Qual tipo de servidor provavelmente está mais perto dos seus usuários finais?

Servidores de borda de uma rede de fornecimento de conteúdo (CDN).
O servidor de origem do seu site.

A seguir: como entender o caminho crítico

Agora que você já conhece algumas das considerações de performance envolvidas no HTML do seu site, está em uma posição melhor para garantir que ele carregue o mais rápido possível. Mas esse é apenas o começo do aprendizado sobre performance na Web. Em seguida, vamos abordar a teoria por trás do caminho de renderização crítica. Este módulo descreve conceitos importantes, como recursos de bloqueio de renderização e de análise, e o papel que eles desempenham para que a renderização inicial de uma página no navegador seja feita o mais rápido possível.