Apesar da disponibilidade de banda larga ter aberto as porteiras para sites cada vez mais pesados que são verdadeiras aplicações na web, ainda é importante prestar atenção na performance de sua página. Não apenas uma página pesada demora para carregar em dispositivos móveis, que compõem uma fatia considerável do público moderno, como também consome uma quantidade significativa de banda cujo consumo é cobrado byte a byte.
Vamos então partir do pressuposto que você já otimizou suas imagens, compactou seus arquivos, removeu os elementos desnecessários de seu código, fez um ajuste fino nos servidores e está confiando no mínimo possível de componentes e bibliotecas externos. Enfim, você fez o seu dever de casa e o site está tinindo, voando como bala em qualquer ambiente.
Mas o seu site está “prevendo o futuro”?
Antecipando as necessidades do seu usuário
Existe uma série de tags HTML que permitem informar ao navegador sobre como acelerar a performance de sua página usando “premonição”. São instruções que o navegador do usuário pode seguir ou não, dependendo da plataforma, da banda disponível e outras variáveis, mas que você pode adicionar ao seu código como uma forma de agilizar o carregamento da página e que seu visitante se encontra ou até mesmo a próxima!
Um desses recursos é a tag LINK, utilizada no cabeçalho do HTML de sua página. Embora o parâmetro rel=”stylesheet” seja o uso mais conhecido dessa tag, ela pode conter outros parâmetros, de acordo com as especificações da W3C:
No exemplo acima, estamos especificando para o navegador onde fica a página principal do site (que pode não ter sido o ponto de entrada do visitante, principalmente se ele utilizou um mecanismo de busca), onde seria o próximo passo lógico em sua navegação, onde seria o passo anterior na sequência e onde ele pode obter ajuda sobre o site.
Nem todos esses elementos fazem sentido em todos os sites e, atualmente, navegações lineares não são tão comuns, mas a orientação para o navegador serve como uma indicação de quais páginas podem ser carregadas previamente enquanto o usuário está na página atual. Esse é o chamado prefetch das páginas. Com essas páginas já baixadas, a transição para elas, caso o usuário realmente resolva seguir a trilha, será praticamente instantânea.
É possível fazer também o prefetch direto de recursos, como uma imagem muito grande que o usuário provavelmente irá solicitar. Por exemplo, usando:
Perceba que:
- É praticamente impossível prever com exatidão o próximo passo do usuário;
- O navegador pode não obedecer às instruções;
- Na verdade, você está aumentando o consumo de banda com o prefetch, com recursos que podem acabar não sendo solicitados pelo usuário.
Portanto, o ideal é usar a ferramenta do LINK com parcimônia e respeito ao usuário. Um webmaster completo precisa analisar os relatórios de visitação de seu site para ter um entendimento correto dos fluxos de navegação de seus usuários e, assim “prever” de forma científica o recurso com maior probabilidade de ser necessário em dado ponto do ciclo de uso do visitante. Existem métricas apropriadas para isso. Criar um prefetch para todas as páginas é um desperdício de tempo e banda que pode e deveria ser ignorado pelos navegadores.
Se você tem certeza absoluta de que o usuário irá acessar uma determinada página, é possível ir além do simples prefetch, usando o chamado prerender. Com esse parâmetro, é possível instruir o navegador não apenas para baixar a próxima página como também renderizá-la na íntegra e armazenar em memória.
O resultado é uma página que carrega instantaneamente, tão logo seja solicitada. Essa é uma ferramenta que pode ser aplicada corretamente quando estamos falando, por exemplo, de uma splash page, uma propaganda, um interstitial, qualquer coisa que carregue antes da página principal. Nessa página anterior nós introduzimos o “prerender” e, tão logo o usuário veja a mensagem desejada, a página final já estará disponível. Exemplo:
Outro caso de uso seriam páginas de exemplos que você quer demonstrar, ou seja, enquanto o usuário lê o artigo principal, os exemplos já estão carregando na memória, basta clicar para visualizar. Muitos webmasters utilizam scripts para fazer o pre-carregamento do que desejam, mas isso pode ser atingindo com uma única tag, um único parâmetro.
Adiantando o serviço
Entretanto, nem todas as ferramentas de “premonição” precisam ser tão radicais ou consumidoras de banda quanto esses parâmetros apresentados para LINK. Existem outras que antecipam as necessidades, mas apenas deixam o navegador de sobreaviso, economizando frações de segundos, que, juntas, podem impactar positivamente na performance do seu site.
Um desses mecanismos mais sutis é o dns-prefetch. Para entendê-lo, precisamos recapitular como funciona um DNS: ele é basicamente uma solicitação do seu navegador para reconhecer um domínio de internet. Nos primórdios da web, o navegador precisava baixar recursos apenas do próprio domínio onde a página se encontrava: imagens, scripts e folhas de estilo ficavam todas hospedadas no mesmo servidor. Porém, hoje em dia, é comum que uma página precise acessar diferentes domínios para carregar, seja puxando um código de rastreio do Google Analytics, uma fonte do Google Fonts, uma imagem hospedada em um CDN, uma biblioteca JavaScript hospedada em outro lugar, a lista é grande.
Para cada domínio, o navegador irá fazer uma solicitação ao DNS e aguardar a resposta, antes de baixar o recurso e seguir renderizando a página. São processos que rodam fora da visão do usuário, mas que duram frações de segundos que podem acabar atrasando o carregamento daquilo que ele vê. Com dns-prefetch, você adianta o serviço: o navegador identifica o domínio já no HEAD, antes do recurso ser solicitado:
No caso acima, perceba que não é necessário especificar o protocolo, apenas o domínio. Como isso, o domínio já é identificado de antemão e, quando o código do Google Analytics for solicitado, a conexão já está feita.
“Mas não dá no mesmo, se ele irá reconhecer o domínio antes ou durante o uso do código do Analytics? Estamos falando aqui de frações de segundo. Com a instrução no HEAD, ela é processada na fase em que o navegador está gerenciando justamente esse tipo de recurso, antes de começar a renderizar a página. Deixando a conexão com o domínio para depois, durante o processo de renderização, a renderização é interrompida, o que pode interferir na percepção de carregamento do usuário. É uma diferença sutil, avalie de acordo com suas necessidades.
Se dns-prefetch checa o domínio, preconnect vai além e navega até o diretório onde estará o recurso solicitado:
Desta forma, estamos abrindo caminho antecipadamente até uma pasta onde estarão nossos recursos, sejam imagens, scripts ou folhas de estilo.
A terceira forma desse mesmo conceito é o preload. Como você deve imaginar, o preload checa o domínio, navega até o diretório e efetivamente faz o carregamento do recurso, armazenando em memória. Um ótimo exemplo de uso seria fazer a carga antecipada de uma fonte, antes mesmo de ela ser solicitada pelo CSS (evitando assim a “piscada” no conteúdo, quando a fonte real é finalmente carregada).
Da mesma forma que os parâmetros anteriores, é preciso estar atento para não sobrecarregar a navegação do usuário e utilizar as ferramentas oferecidas de forma consciente, sem exageros.
