1. Identifique páginas com RTRs excessivos.
Identificar RTRs leva à sua minimização. Muitos sites apresentam mais de 100 RTRs por página, mas deveriam ter no máximo 50. Em geral, é comum desenvolvedores ou profissionais de SEO que cuidam das solicitações de uma página encontrarem itens ausentes (404) que ninguém havia percebido. Mesmo ausentes, ainda demandam tempo do navegador, que os solicita e volta de mãos vazias. Então, essas páginas devem ser removidas ou corrigidas imediatamente.
Também deve-se corrigir ativos que foram movidos e retornam respostas 301 ou 302. Essas respostas significam que o navegador teve que ir para um lugar e depois seguir outro conjunto de instruções para ir para outro lugar para obter o ativo, mas cada novo local demanda mais tempo. É como ir a um mercado apenas para lhe dizerem que ali não tem o que você precisa e que você deve procurar em outra loja mais à frente. Pior ainda: se houver uma cadeia de redirecionamentos, é como ir à segunda loja e descobrir que ali também não tem mais o item, e agora você deve tentar em um terceiro lugar.
2. Combine arquivos sempre que possível.
A próxima etapa para um site otimizado é combinar arquivos (como JavaScript e CSS) sempre que possível. Por exemplo, se uma página usa dez folhas de estilo (arquivos CSS) que poderiam ser combinadas em uma, assim deve ser. Da mesma forma, se você estiver usando uma porção de arquivos JavaScript que poderiam ser combinados em um só, por que não fazer isso? Tente pensar nas coisas de forma geral para o site e também especificamente para cada modelo. Você deve ter um arquivo JavaScript geral que engloba todas as páginas do site, e um arquivo JavaScript específico para cada modelo de página no site. O mesmo pode ser feito com CSS. Também é aconselhável garantir que esses arquivos sejam sempre referenciados com o mesmo nome e no mesmo local se armazenados em cache corretamente.
3. Otimize a ordem de renderização.
Depois de eliminar e consolidar para diminuir o número total de RTRs, a próxima etapa é ajustar a ordem na qual as coisas são solicitadas para ganhar rapidez. Da mesma forma que certas etapas devem vir umas antes das outras em uma receita, um navegador móvel também segue uma determinada ordem, a qual deve ser mantida ao se criar uma página. Assim como no exemplo do mercado, se a sua receita indica que algo deve ser marinado por dois dias, é importante que você obtenha os itens necessários para isso primeiro, para começar a marinar antes de incluir o resto dos ingredientes, não depois.
Traduzindo essa analogia para o mundo da internet, marinar o alimento é como um bloqueador de renderização, porque nada mais pode acontecer no processo até que isso seja feito. A única coisa que você pode fazer para se preparar para as próximas etapas do processo de cozimento é obter os outros ingredientes enquanto o alimento marina. É como a renderização de caminho crítico: você prioriza os itens mais relevantes, como a etiqueta de cabeçalho, o conteúdo e o layout básico da página, e coloca em espera os itens menos fundamentais, especialmente se eles atrasarem o carregamento de itens mais críticos. Isso pode melhorar drasticamente a experiência de carregamento para usuários e lhes garantir que o resto da página será carregado rapidamente. Isso também permite que iniciem sua experiência enquanto o processo de carregamento acontece.
4. Crie uma estratégia de carregamento de página.
Como os mecanismos de pesquisa emulam usuários humanos, a experiência para eles é praticamente a mesma que para você. A melhor coisa a se fazer em relação a solicitações de velocidade é identificar o que é mais relevante nos primeiros segundos da experiência do usuário, logo ao entrarem na página. Isso geralmente diz respeito à informação na etiqueta de cabeçalho e ao texto e às imagens na página. Em geral, as pessoas levam alguns segundos para se envolverem com qualquer coisa que seja interativa no site, então, a maior parte do JavaScript não precisa ser carregada logo de início. Em vez disso, representações visuais do JavaScript, como menus suspensos ou conteúdo expansível, podem ser carregadas como espaços reservados antes que o JavaScript em si seja requisitado. O JavaScript é especialmente lento e difícil de carregar. Para garantir que o carregamento do JavaScript não seja um empecilho para a experiência dos usuários e bots a ponto de a página ficar em branco por um longo tempo, o ideal é carregar algo que possam olhar e, em seguida, carregar o JavaScript em segundo plano.
Depois do JavaScript, vídeos e imagens são os itens que carregam mais lentamente. Vídeos e imagens que estão na parte inferior da página não devem prejudicar a experiência na parte superior da página, por onde os usuários e bots geralmente começam. Esse conceito é chamado de "carregamento lento", quando há o atraso de carregamento do conteúdo que não está visível. O carregamento lento pode ser realizado de várias maneiras (com adiamento, assincronismo e marcas META de carregamento lento do Google).
A melhor ferramenta para a identificação de oportunidades em imagens com carregamento lento é o Google PageSpeed Insights. Para otimizar imagens, você também pode usar a marca de imagem de carregamento lento do Google que, por ora, é compatível apenas com navegadores móveis e de desktop do Chrome (mas isso pode mudar no futuro). Com qualquer um dos métodos, você deve usar a Ferramenta de inspeção de URL no Google Search Console para verificar se os itens de carregamento lento estão visíveis na renderização da página na ferramenta e no HTML renderizado.
5. Faça a compactação de tudo o que puder.
Depois de minimizar e priorizar RTRs para cada modelo de página, você deve compactar tudo o que puder. A compactação ajuda a aumentar a velocidade da página ao economizar largura de banda. O formato Gzip é uma possibilidade para a compactação de arquivos, e é compatível com a maioria dos servidores, mas também há outras opções disponíveis. Você pode executar a maioria dos códigos por meio de um processo de minimização, o que reduz o tamanho do arquivo de transferência final. No entanto, é difícil compactar imagens por meio desses métodos. Você pode usar a página Performance Review (Análise de desempenho) no WebPageTest.org para encontrar a Lista de verificação de otimização completa, que mostra todos os ativos na página, mesmo que estejam em Gzip, e seu nível de compactação.
Para a compactação de imagens, em vez de utilizar o formato Gzip ou minimizar, é importante que o designer as encaminhe ao desenvolvedor no formato mais compactado possível, reduzindo os arquivos de imagem. Basicamente, eles precisam tornar o tamanho final do arquivo o menor possível sem comprometer sua aparência. As fotos geralmente devem ser salvas como arquivos JPG, e ícones e ilustrações como arquivos GIF. Para que as imagens grandes fiquem boas na tela cheia do computador, e não sejam prejudicadas quando em telas móveis pequenas, considere usar o protocolo de imagens responsivas ou usar um servidor de imagens, como o do Fastly, para enviar dinamicamente uma versão pré-dimensionada da imagem para telas menores.
6. Armazene em cache as páginas certas no momento certo.
O próximo passo é ajudar navegadores e bots a identificarem o que pode ser reutilizado e o que precisa ser buscado novamente todas as vezes no cache do navegador, uma funcionalidade que pode ser definida de diferentes maneiras, como por meio de CDNs (redes de entrega de conteúdo). A maioria dos elementos, especialmente em um site que não muda mais de uma vez por semana nem compartilha informações em tempo real, como notícias, previsão do tempo ou placares esportivos, podem ser armazenados em cache em suas páginas por até um ano. O armazenamento em cache significa que, quando os usuários visitam uma página, os navegadores procuram localmente na memória os arquivos necessários para criar aquela página. Isso economiza tempo nas RTRs e melhora o carregamento. Os bots do mecanismo de pesquisa sempre visualizam uma página como se fosse pela primeira vez, assim não usam o cache ativo, mas podem perceber quando o armazenamento em cache está em execução, o que podem usar para estimar o tempo de carregamento de uma página.
O importante a entender sobre o armazenamento em cache é que ele é baseado nos nomes dos arquivos e em sua localização no servidor. Então, para usar o mesmo arquivo em muitas páginas, como um logotipo, sempre use como referência o mesmo nome de arquivo e URL, mesmo que ele exista em vários locais no seu servidor. Isso pode ser usado a seu favor porque significa que você simplesmente precisa atualizar o nome do arquivo de um item e sua referência no HTML para obter uma nova versão em cache. Então, por exemplo, se você fizer um ajuste no seu logotipo, basta alterar o nome do arquivo de "logotipo" para "logov2" para que a nova versão seja armazenada em cache e a versão antiga seja desconsiderada. Dessa forma, ao permitir que algo seja armazenado em cache por um ano, você não está dizendo que não alterará o item durante esse período, mas que, se o fizer, usará um nome de arquivo novo para uma referência atualizada.
As configurações de cache podem ser um pouco complicadas, então a melhor coisa é pensar nelas como alimentos que têm validade. A vida útil de alguns alimentos é menor que de outros, então você precisa informar ao navegador quais coisas estragam e devem ser dispensadas em um curto prazo e quais podem ficar com segurança na prateleira por mais tempo, sem que você precise substituí-las. Você pode usar uma ferramenta como WebPageTest.org para ajudá-lo a identificar oportunidades. O importante aqui é entender que não há um prazo de validade definido, nem um tempo máximo para a existência do item no cache. Portanto, o navegador apenas presume que precisa buscar tudo desde o início todas as vezes: o armazenamento no cache do navegador não acontece a menos que esses detalhes estejam especificados.
As configurações de cache informam a um navegador quando o item é muito antigo para ser usado, e isso às vezes é chamado de "vida útil do cache" ou de "vida útil da atualização". Se a vida útil do cache ou da atualização for ultrapassada, o servidor deve ser acionado para que se obtenha uma nova versão. Se os itens estiverem listados como "expirados", isso significa que ultrapassaram a vida útil da atualização e, tanto na analogia do mercado quanto na do navegador, devem ser substituídos na próxima vez em que forem necessários.
Da mesma forma que ter prateleiras cheias de mantimentos com a validade vencida não é algo interessante, também não é útil ter um cache cheio de conteúdo da web expirado. Por outro lado, também não adianta jogar fora mantimentos (arquivos) que ainda estão em perfeito estado. Ao atribuir um tempo de vida útil do cache aos seus arquivos, analise-o e considere as consequências de ser muito generoso. Se você, por exemplo, fizer pequenas alterações no seu logotipo, não é o fim do mundo continuar exibindo o antigo por um tempo. Assim, não há problemas em estabelecer um tempo longo de vida útil do cache, contanto que você se comprometa a atualizar os nomes dos arquivos sempre que fizer alterações. Ao usar nomes de arquivo diferentes, você não precisa se preocupar com a exibição do logotipo antigo.
7. Crie páginas móveis aceleradas (AMPs).
Tudo isso pode parecer complicado, e é por isso que o Google criou uma solução mais simples para a otimização da velocidade da página. Páginas móveis aceleradas, ou AMPs, são um subconjunto de HTMLs que seguem diretrizes muito mais rigorosas sobre o que pode ser incluído. O objetivo é fazer com que a maioria das páginas leve no máximo um segundo para carregar no celular, e geralmente dá certo. As AMPs permitem que o Google assuma o controle daquilo que é mais complexo ao armazenar em cache e configurar o processo de carregamento e a maioria dos elementos descritos acima para possibilizar a maior otimização possível.
Em alguns casos, as empresas criam novas AMPs e links dedicados a partir de páginas existentes no site, por meio das etiquetas de cabeçalho. Isso informa ao Google que a AMP deve ser fornecida quando a pessoa que solicita a página estiver em um dispositivo móvel ou em uma conexão lenta. Em outros casos, você pode substituir as páginas existentes (ou as páginas móveis existentes, se estiverem em sites separados) por AMPs. Isso é chamado de "AMP canônica" ou "Canonical AMP", em inglês. O Google dá preferência a esse método, porque as AMPs são extremamente fáceis de rastrear, renderizar, indexar e classificar. Porém, essa pode não ser a primeira escolha das empresas, porque as limitações e os requisitos das AMPs podem tornar as páginas um pouco mais austeras. As AMPs também podem atrapalhar ou limitar alguns dos rastreamentos e testes de páginas de desktop, outro motivo pelo qual algumas pessoas evitam usá-las.
Os sites compatíveis com AMPs seguem todas as regras e diretrizes das AMPs e, como consequência, o Google exibe um pequeno raio cinza para eles nos resultados móveis. É mais provável que o Google os inclua em carrosséis especiais de resultados que costumam aparecer na parte superior das páginas. O que é ótimo, mas se a compatibilidade com AMP trouxer muitos problemas ao seu site, é melhor você usar o código AMP em vez disso. Você deve usar a HTML para AMP sempre que puder, assim não precisa se preocupar em respeitar cada regra. E você ainda terá como benefício a velocidade da HTML e do JavaScript para AMP, o que não é mau negócio, já que é gratuito. Lembre-se, a velocidade impacta diretamente o envolvimento do público e a conversão, e ainda provavelmente ajuda com a profundidade e outros aspectos da eficiência do rastreamento.
Os navegadores móveis funcionam de forma diferente dos navegadores de desktop. Além de tudo, eles têm processadores mais lentos e conexões menos confiáveis. Esses fatores tornam importante analisar o pior caso de tempo de carregamento das páginas do seu site a partir de uma perspectiva móvel para identificar oportunidades reais de melhoria.