Os sites ainda estão carregando muito lentamente. No momento mais crítico do processo de download, o canal geralmente fica quase completamente ocioso. A nova tecnologia da Fastly, proposta pelo engenheiro Kazuho Oku, ajudará a fazer melhor uso desse primeiro par crítico de segundos.

Você já baixou um site no seu telefone - e procurou por 10 segundos em uma página sem texto? Ninguém gosta de sentar e olhar para uma tela em branco enquanto alguma fonte incomum está sendo carregada. Portanto, faz sentido transferir o carregamento de coisas importantes para o mais rápido possível. O link rel = preload de pré-carga deveria resolver parcialmente o problema. Primeiro, o navegador analisa cabeçalhos HTTP, portanto, este é o lugar perfeito para apontar para o pré-carregamento de um recurso que você definitivamente precisará mais tarde.

Por padrão, a Internet está lenta

Vamos ver o que acontece se você não usar a pré-carga. O navegador só pode começar a carregar recursos depois de descobrir que precisa deles. É mais provável que isso ocorra para recursos que estão em HTML durante a análise inicial do documento (por exemplo, <script> , <link rel=stylesheet> e <img> ).

Os recursos detectados após a construção da árvore de renderização são baixados mais lentamente (este é o local em que a página fica mais lenta devido ao carregamento da fonte, porque para entender isso, primeiro você precisa carregar a folha de estilo, analisá-la, criar o modelo de objeto CSS e, em seguida, a árvore de renderização).

Ainda mais devagar estão carregando recursos que são adicionados ao documento usando carregadores JavaScript acionados por eventos como DOMContentLoaded . Se você juntar tudo, obteremos uma cascata não otimizada e sem sentido. Na maioria das vezes, o canal está ocioso e os recursos são carregados antes do necessário ou tarde demais:

O link rel = preload ajuda muito

Nos últimos anos, a situação melhorou graças ao Link rel = preload . Por exemplo:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

Graças a essas diretivas, o navegador pode começar a carregar recursos imediatamente após receber os cabeçalhos e antes de iniciar a análise do corpo HTML:



Essa é uma melhoria significativa, especialmente para páginas grandes e recursos críticos que, de outra forma, seriam descobertos tarde. Especialmente para fontes, mas qualquer coisa pode se tornar um recurso crítico, como o arquivo de dados necessário para carregar um aplicativo JavaScript.

No entanto, podemos fazer mais. Afinal, o navegador não faz nada entre o momento em que termina o envio da solicitação e quando recebe os primeiros bytes da resposta (o grande fragmento verde na solicitação inicial é maior).

Usamos o tempo do "pensamento do servidor" com a ajuda de "dicas iniciais"

Por outro lado, o servidor está realmente ocupado. Ele gera uma resposta e determina se é bem-sucedido ou não. Depois de acessar o banco de dados, chamadas de API, autenticação etc. o servidor pode decidir que o erro 404 é a resposta correta.

Às vezes, o tempo de meditação do servidor é menor que a latência da rede. Às vezes substancialmente mais. Mas é importante entender que eles não se sobrepõem. Enquanto o servidor está pensando, não estamos enviando dados para o cliente.

Mas é interessante que, mesmo antes de gerar a resposta, você já conheça alguns estilos e fontes que precisam ser baixados para exibir a página. Afinal, as páginas de erro geralmente usam a mesma identidade corporativa e design que as páginas comuns. Seria ótimo enviar esses Link: rel=preload antes que o servidor funcione . É por isso que o padrão Early Hints , concebido no RFC8297 pelo HTTP Working Group, foi cunhado por Fastly, meu colega Kazuho Oku. Avalie a mágica de várias barras de status em uma resposta :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

O servidor pode gravar o primeiro código de resposta "informativo" assim que receber uma solicitação e enviá-lo para a rede. Então ele lidará com a definição de uma reação real e sua geração. Enquanto isso, no navegador, você pode começar a pré-carregar muito mais cedo:



Obviamente, isso exigirá certas alterações na operação de navegadores, servidores e CDNs, e os desenvolvedores de alguns navegadores expressaram reservas sobre as dificuldades de implementação. Portanto, ainda não está claro quando esses cabeçalhos podem ser colocados em operação. Você pode acompanhar o progresso em rastreadores públicos para Chrome e Firefox .

Esperamos que, no final, você consiga emitir cabeçalhos do Early Hints diretamente do Fastly, ainda enviando solicitações de maneira padrão. Ainda não decidimos como definir a interface via VCL, então, deixe-me saber se você tem algum desejo sobre este assunto!

Mas e quanto ao HTTP / 2 Server Push?

Com o HTTP / 2, existe uma nova tecnologia chamada Server Push que parece resolver o mesmo problema que Link rel = preload na resposta das Dicas iniciais. Embora realmente funcione (e você possa gerar rapidamente envio personalizado a partir de servidores de borda no Fastly), existem diferenças significativas em vários pontos:

• O servidor não sabe sobre a disponibilidade de um recurso no cliente; portanto, ele geralmente o envia desnecessariamente. Devido ao buffer e à latência da rede, o cliente geralmente não pode cancelar o envio antes de receber todo o conteúdo. (Embora exista uma possível solução para esse problema, na forma do cabeçalho do Cache Digest proposto, no qual Kazuho está trabalhando com Joam Weiss, da Akamai).
• Os recursos transmitidos estão vinculados à conexão, portanto, é fácil iniciar um recurso que o cliente não usa, pois está tentando obtê-lo por outra conexão. Os clientes podem precisar usar uma conexão diferente porque o recurso está em uma fonte diferente com um certificado TLS diferente ou porque é recuperado em um modo de credencial diferente.
• O H2 Push não é implementado de maneira muito consistente em diferentes navegadores. Portanto, é difícil prever se funcionará ou não no seu caso específico.

De uma maneira ou de outra, o Early Hints e o Server Push oferecem vantagens e desvantagens. As dicas iniciais fornecem um uso mais eficiente da rede em troca de trocas de pacotes adicionais. Se você espera uma pequena latência de rede e muito tempo para pensar no servidor, o Early Hints é a solução certa.

No entanto, esse nem sempre é o caso. Vamos ser otimistas e imaginar que as pessoas em breve se estabelecerão em Marte. Eles navegam na web com um atraso de 20 a 45 minutos para cada troca de pacotes; portanto, a troca adicional é extremamente dolorosa e o tempo do servidor é insignificante em comparação a ela. O Server Push vence facilmente aqui. Mas se olharmos para as páginas da Web em Marte, é mais provável que baixemos algum tipo de pacote de dados, algo como pacotes da Web agora oferecidos e trocas assinadas .

Bônus Extra: Solicitação Mais Rápida

Embora o Early Hints deva ser usado principalmente no navegador, há um benefício potencial interessante para a CDN. Quando Fastly recebe muitas solicitações para o mesmo recurso, geralmente enviamos apenas uma delas para a fonte e colocamos o restante na fila de espera. Esse processo é conhecido como recolhimento de solicitação . Se a resposta da origem incluir Cache-Control: private , você deverá remover todas as solicitações da fila e enviá-las separadamente para a fonte, porque não podemos usar uma resposta para atender a várias solicitações.

Não podemos tomar uma decisão até que uma resposta seja recebida para a primeira solicitação, mas, no caso do suporte ao Early Hints, se o servidor retornou uma resposta do Early Hints com o cabeçalho Cache-Control, saberemos muito mais cedo que a fila não pode ser recolhida em uma única solicitação, mas, em vez disso, encaminhe imediatamente todas as solicitações da fila para a origem.

Solicite conteúdo menos crítico com dicas de prioridade

As dicas iniciais são uma ótima maneira de acessar alguns dos objetos mais valiosos da fila (cascata): quando a rede está ociosa, o usuário espera, há apenas uma solicitação no caminho e não há nada na tela. Mas assim que o HTML é carregado e a página é analisada, o número de recursos que precisam ser carregados aumenta drasticamente. Agora é importante não carregar recursos o mais rápido possível, mas carregá-los na ordem correta. Os navegadores usam uma variedade surpreendentemente complexa de heurísticas para determinar independentemente a prioridade do download, mas se você quiser redefini-las, no futuro isso poderá ser feito com a ajuda de dicas de prioridade:

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

Com esse novo atributo de importância, os desenvolvedores podem controlar a ordem de carregamento de recursos em caso de concorrência pela rede. Talvez os recursos de baixa prioridade possam ser adiados até que o processador e a rede estejam livres, ou dependendo do tipo de dispositivo.

Isso pode ser usado?

Nem pistas iniciais nem pistas prioritárias se tornaram o padrão ainda. Recentemente, o H2O, o servidor HTTP / 2 usado e suportado pela Fastly, começou a usar as Dicas Antigas (consulte PR 1727 e 1767 ), e existe a intenção de implementar Dicas de Prioridade no Chrome , além de rastrear ativamente as respostas 1xx. Ao mesmo tempo, não há mal nenhum em começar a enviar dicas precoces agora - e se você quiser se antecipar à tendência, vá em frente!