Considerações gerais de desempenho de HTML

A primeira etapa para criar um site com carregamento rápido é receber resposta do servidor para o HTML de uma página. Quando você insere um URL no barra de endereço do navegador, o navegador envia uma solicitação GET ao servidor para recuperá-la. A primeira solicitação por uma página da web é para um recurso HTML, e garantir que o HTML chegue rapidamente com atrasos mínimos é um dos principais do seu objetivo.

Essa solicitação inicial de HTML passa por várias etapas, e cada uma delas leva algum tempo. Reduzir o tempo gasto em cada etapa oferece um Tempo para First Byte (TTFB). Embora o TTFB não seja a única métrica em que você deve se concentrar quando se as páginas carregam rápido, um TTFB alto faz com que seja difícil alcançar a classificação de "boa" limites 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, com um redirecionamento permanente (uma resposta 301 Moved Permanently) ou um um (uma resposta 302 Found).

Os redirecionamentos reduzem 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. Existem dois tipos de redirecionamentos:

1. Redirecionamentos de mesma origem que ocorrem inteiramente dentro da sua origem. Esses tipos dos redirecionamentos estão sob seu controle, já que a lógica para gerenciar eles residem inteiramente no seu servidor da Web.
2. Redirecionamentos entre origens iniciados por outra origem. Esses tipos de os redirecionamentos costumam estar fora de seu controle.

Os redirecionamentos de origem cruzada são frequentemente usados por anúncios, serviços de encurtamento de URL e outros e serviços terceirizados. Embora os redirecionamentos de origem cruzada estejam fora do seu controle, convém evitar vários redirecionamentos, por exemplo, ter um anúncio vinculado a uma página HTTP que, por sua vez, redireciona para HTTPS equivalente ou um redirecionamento de origem cruzada que chega à sua origem, mas aciona um redirecionamento de mesma origem.

Armazenar respostas HTML em cache

Armazenar respostas HTML em cache é difícil, pois a resposta pode incluir links para outros recursos críticos, como CSS, JavaScript, imagens e outros tipos Esses recursos podem incluir uma impressão digital exclusiva nos respectivos nomes de arquivo, que mudam com base no conteúdo de um arquivo. Isso significa que o armazenamento em cache O documento HTML pode ficar obsoleto após a implantação, porque ele conteria referências a sub-recursos desatualizados.

No entanto, um tempo de vida curto em cache, 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 que são veiculadas do servidor de origem e no navegador, permitindo recursos sejam revalidados, em vez de baixados novamente. Essa abordagem funciona melhor para conteúdo estático que não se altera em nenhum contexto, e uma implementação para armazenar em cache, os recursos podem ser definidos para um determinado número de minutos apropriados. Cinco minutos para recursos HTML estáticos é uma aposta segura e garante para que as atualizações periódicas não passem despercebidas.

Se o conteúdo HTML de uma página estiver personalizado de alguma forma (por exemplo, para um usuário autenticado, e é provável que você não queira armazenar em cache conteúdos diversas questões, incluindo segurança e da atualização. Se uma resposta HTML for em cache pelo navegador do usuário, não será possível invalidar o cache. Está portanto, é melhor evitar o armazenamento em cache de HTML completamente nesses casos.

Uma abordagem cautelosa ao armazenar HTML em cache pode ser usar o ETag ou Last-Modified. Uma ETag, também conhecida como uma entidade tag: o cabeçalho é um identificador que representa exclusivamente o recurso solicitado; geralmente usando um hash do conteúdo do recurso:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Sempre que o recurso for alterado, um novo valor ETag precisará ser gerado. Ativado solicitações subsequentes, o navegador enviará o valor ETag por meio da cabeçalho de solicitação If-None-Match. Se o ETag no servidor corresponder enviado pelo navegador, o servidor responde com 304 Not Modified, e o navegador usará o recurso do cache. Embora isso ainda incorra latência de rede, uma resposta 304 Not Modified é muito menor do que uma recurso HTML.

No entanto, a latência da rede envolvida na revalidação da atualização de um recurso é ainda o próprio tipo de desvantagem. Assim como em muitos outros aspectos do desenvolvimento Web, compensações e concessões são inevitáveis. Cabe a você descobrir um esforço adicional para armazenar o HTML dessa forma vale a pena ou se for melhor manter em segurança e não se preocupar em armazenar em cache o 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 dependerá muito seu provedor de hospedagem e a 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, exemplo, podem ter um TTFB maior do que uma página da Web estática que pode ser exibida imediatamente sem tempo de computação significativo no back-end. A exibição de um ícone de carregamento e, em seguida, buscar todos os dados do lado do cliente move o esforço de um ambiente do lado do servidor mais previsível para um a do lado do cliente. Minimizar o esforço do lado do cliente geralmente resulta em melhor centradas no usuário.

Se os usuários estiverem com um TTFB lento no campo, exponha as informações. sobre onde o tempo foi gasto no servidor por meio do uso do Server-Timing cabeçalho de resposta:

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

O valor de um cabeçalho Server-Timing pode incluir várias métricas, bem como uma e a duração de cada um. Esses dados podem ser coletados de usuários no campo usando a Navigation Timing API e analisados para ver se os usuários estão tendo atrasos. No snippet de código anterior, o cabeçalho de resposta inclui dois tempos:

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

Talvez você também queira analisar sua infraestrutura de hospedagem e confirmar que tenha recursos adequados para lidar com o tráfego que seu site recebe. Compartilhado os provedores de hospedagem são suscetíveis a um TTFB alto, e soluções dedicadas que oferecem tempos de resposta mais rápidos podem sair mais caro.

Compactação

Respostas baseadas em texto, como imagens HTML, JavaScript, CSS e SVG, devem ser comprimidos para reduzir o tamanho de transferência pela rede fazer o download mais rapidamente. Os algoritmos de compactação mais utilizados são 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 serem consideradas se você puder configurar ou ajuste as configurações de compactação manualmente:

1. Use o Brotli sempre que possível. Como já mencionamos, a Brotli oferece uma abordagem uma melhoria notável em relação ao gzip, e o Brotli é compatível com todas as principais navegadores padrão. Use o Brotli quando possível, mas se o site for usado por número de usuários em navegadores legados, use gzip como substituto, pois qualquer compressão é melhor do que nenhuma compressão.
2. O tamanho do arquivo é importante. Recursos muito pequenos (menos de 1 KiB) não são compactados muito bem ou às vezes nem mesmo são comprimidas. Eficácia de qualquer tipo da compactação de dados depende de uma grande quantidade de dados com o qual o algoritmo de compressão pode trabalhar a fim de encontrar bits mais compactáveis de dados. Quanto maior o arquivo, melhor funciona a compactação. No entanto, não enviam recursos muito grandes pelo simples fato de que podem ser comprimidos mais com eficiência. Grandes recursos (como JavaScript e CSS, por exemplo) usam muito mais tempo para analisar e avaliar depois que o navegador descompactados deles e podem mudar com mais frequência, mesmo que tenham apenas mudou ligeiramente, já que qualquer mudança resulta em um hash de arquivo diferente.
3. Entenda a compressão dinâmica e a estática. Dinâmico e estático compactação são abordagens diferentes em relação a quando um recurso deve 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, sem necessidade de compactação que será executada no momento da solicitação. A compactação estática remove a latência envolvida na própria compactação, o que pode aumentar a resposta do servidor vezes no caso de compactação dinâmica. Recursos estáticos, como JavaScript, CSS e imagens SVG – devem ser compactadas estaticamente, enquanto HTML recursos, especialmente se eles forem gerados dinamicamente para aplicativos usuários, precisam ser compactados dinamicamente.

Fazer a compactação do jeito certo é um desafio, e muitas vezes o melhor é deixar uma rede de fornecimento de conteúdo (CDN), que será discutida na próxima seção, cuidar disso para 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 produzir o máximo de benefícios para seu site.

Redes de fornecimento de conteúdo (CDNs)

A rede de fornecimento de conteúdo (CDN) é uma rede distribuída de servidores que armazenar em cache os recursos do servidor de origem e, por sua vez, os disponibilizar da borda os servidores que estão fisicamente mais próximos dos usuários. A proximidade física com seu usuários reduz o tempo de retorno (RTT), e otimizações como HTTP/2 ou HTTP/3, armazenamento em cache e compactação permitem que o CDN disponibilize 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: como entender o caminho crítico

Agora que você conhece algumas das considerações de desempenho envolvidas com o HTML do seu site, você garante que ele carregue o mais rápido possível, mas isso é só o começo do aprendizado na Web desempenho. A seguir, a teoria por trás do caminho crítico de renderização é abrangidos. Este módulo descreve conceitos importantes, como bloqueio de renderização e recursos de bloqueio de análise e o papel que desempenham na obtenção do valor no navegador o mais rápido possível.