Considerações gerais de desempenho de HTML

A primeira etapa para criar um site que carrega rapidamente é receber uma resposta do servidor para o HTML da página em tempo hábil. Quando você digita um URL na barra de endereço do navegador, ele envia uma solicitação GET ao servidor para recuperá-lo. A primeira solicitação de uma página da Web é para um recurso HTML. Uma meta importante de desempenho é garantir que o HTML chegue rapidamente com atrasos mínimos.

Essa solicitação inicial de HTML passa por várias etapas, e cada uma leva algum tempo. Reduzir o tempo gasto em cada etapa proporciona um Tempo para primeiro byte (TTFB, na sigla em inglês) mais rápido. Embora o TTFB não seja a única métrica a que você precisa se concentrar no tempo de carregamento das páginas, um TTFB alto dificulta o alcance dos limites "bom" designados para métricas como Maior exibição de conteúdo (LCP) e Primeira exibição de conteúdo (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 está totalmente no seu servidor da Web.
2. Redirecionamentos de origem cruzada iniciados por outra origem. Esses tipos de redirecionamentos normalmente estão fora do seu controle.

Os redirecionamentos de origem cruzada costumam ser usados 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, é recomendável evitar vários.

Armazenar respostas HTML em cache

Armazenar respostas HTML em cache é difícil, porque a resposta pode incluir links para outros recursos essenciais, 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 com base no conteúdo do arquivo. Isso significa que o documento HTML armazenado em cache pode ficar obsoleto após uma implantação, já que conteria referências a sub-recursos desatualizados.

No entanto, uma vida útil de cache curta, em vez de nenhum armazenamento em cache, pode ter benefícios, como permitir que um recurso seja armazenado em cache em uma CDN, reduzindo o número de solicitações exibidas do 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. É possível definir um momento adequado para armazenar os recursos em cache com um número de minutos que você considere 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 (por exemplo, para um usuário autenticado), é provável que você não queira armazenar conteúdo em cache 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 armazenamento em cache do HTML completamente nesses casos.

Uma abordagem cautelosa ao 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 de forma exclusiva o recurso solicitado, geralmente usando um hash do conteúdo do recurso:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Sempre que o recurso muda, um novo valor ETag precisa ser gerado. Nas 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 que um recurso HTML inteiro.

No entanto, a latência de rede envolvida na revalidação da atualização de um recurso ainda é o próprio tipo de desvantagem. Tal como acontece com muitos outros aspectos do desenvolvimento da Web, as compensações e concessões são inevitáveis. Cabe a você descobrir se o esforço extra para armazenar HTML em cache dessa maneira vale a pena ou se é melhor manter a segurança e não se preocupar em armazenar o conteúdo HTML em cache.

Medir os tempos de resposta do servidor

Se uma resposta não for armazenada em cache, o tempo de resposta do servidor dependerá muito do provedor de hospedagem e da pilha de aplicativos de back-end. Uma página da Web que exibe uma resposta gerada dinamicamente (como a busca de dados de um banco de dados, por exemplo) pode muito bem 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. Exibir um ícone de carregamento e, em seguida, buscar todos os dados no lado do cliente move o esforço de um ambiente do lado do servidor mais previsível para um potencialmente imprevisível no lado do cliente. Minimizar o esforço do lado do cliente geralmente resulta em melhores métricas centradas no usuário.

Se os usuários encontrarem 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 e a duração de cada uma delas. Esses dados podem ser coletados dos usuários no campo usando a API Navigation Timing e analisados para saber se eles estão enfrentando atrasos. No snippet de código anterior, o cabeçalho da resposta inclui dois tempos:

• 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.

Também convém analisar sua infraestrutura de hospedagem e confirmar se você tem recursos adequados para lidar com o tráfego que seu site está recebendo. Provedores de hospedagem compartilhados geralmente são suscetíveis a um TTFB alto, e soluções dedicadas que fornecem 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 na rede e fazer com que o download seja mais rápido. Os algoritmos de compactação mais usados são o gzip e o Brotli. O Brotli resulta em uma melhoria de cerca de 15% a 20% em relação ao gzip.

Em geral, a compactação é configurada automaticamente pela maioria dos provedores de hospedagem na Web, mas há alguns aspectos importantes a serem considerados caso você consiga definir 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 o Brotli tem suporte em todos os principais navegadores. Use o Brotli quando possível. No entanto, se o site for usado por um grande número de usuários em navegadores legados, use o gzip como substituto, porque qualquer compactação é melhor do que nenhuma compactação.
2. O tamanho do arquivo é importante. Recursos muito pequenos (menos de 1 KiB) não compactam muito bem ou, às vezes, nem mesmo compactam. A eficácia de qualquer tipo de compactação de dados depende de uma grande quantidade de dados com os quais um algoritmo de compactação pode trabalhar para encontrar partes mais compactáveis. Quanto maior é um arquivo, melhor a compactação funciona. No entanto, não envie recursos muito grandes só pelo fato de que eles podem ser compactados de maneira mais eficaz. Recursos grandes, como JavaScript e CSS, por exemplo, levam muito mais tempo para analisar e avaliar depois que o navegador os descompacta e podem mudar com mais frequência, mesmo que tenham mudado apenas ligeiramente, já que qualquer mudança resulta em um hash de arquivo diferente.
3. Entenda a compactação dinâmica e a estática. A compactação dinâmica e a estática são abordagens diferentes para quando um recurso precisa ser compactado. A compactação dinâmica compacta um recurso no momento em que é solicitado e, às vezes, sempre que é solicitado. Por outro lado, a compactação estática compacta os arquivos com antecedência, exigindo que nenhuma compactação seja realizada no momento da solicitação. A compactação estática remove a latência envolvida na própria 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 estaticamente. Já os recursos HTML, especialmente gerados dinamicamente para usuários autenticados, precisam ser compactados de maneira dinâmica.

Conseguir a compactação por conta própria é um desafio, e geralmente é melhor deixar que uma rede de fornecimento de conteúdo (CDN), que será discutida na próxima seção, lide com isso para você. No entanto, conhecer esses conceitos pode ajudar você a saber se o provedor de hospedagem está usando a compactação corretamente. Esse conhecimento pode ajudar você a encontrar oportunidades de melhorar suas configurações de compactação para que proporcionem 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 em cache os recursos do servidor de origem e, por sua vez, os disponibiliza por servidores de borda que estão fisicamente mais próximos dos usuários. A proximidade física com os usuários reduz o tempo de retorno (RTT), enquanto otimizações como HTTP/2 ou HTTP/3, armazenamento em cache e compactação permitem que o CDN exiba conteúdo mais rapidamente do que se ele fosse buscado no servidor de origem. O uso de uma CDN pode melhorar significativamente o TTFB do seu site em alguns casos.

teste seus conhecimentos

A seguir: compreensão do caminho crítico

Agora que você já conhece algumas das considerações de desempenho envolvidas no HTML do seu site, é possível garantir que ele seja carregado o mais rápido possível, mas esse é apenas o começo do aprendizado do desempenho na Web. Em seguida, abordamos a teoria por trás do caminho crítico de renderização. Este módulo descreve os principais conceitos, como recursos de bloqueio de renderização e de análise, e o papel que eles desempenham em fazer a renderização inicial de uma página no navegador o mais rápido possível.