Guia de WPO para Otimizar a Velocidade do Seu Site

O que é WPO?

Web Performance Optimization, que chamamos de WPO, é simplesmente a otimização dos diferentes processos que afetam como um site carrega.

Como medir a velocidade de carregamento de um site?

Existem muitas ferramentas para medir a velocidade de carregamento. As mais populares são:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

Antes de começar uma auditoria, é importante ter em mente que a velocidade de carregamento varia para cada usuário. Diferentes variáveis podem afetar como a velocidade é percebida por um usuário em Cuenca em comparação com um em Ottawa.

Por isso, em vez de trabalhar com tempos de carregamento em segundos, recomendamos focar em otimizar:

• ›

  Peso do site (MB)

• ›

  Requisições

• ›

  Tempo de resposta do servidor

Se melhorarmos essas 3 áreas, a velocidade de carregamento melhorará independentemente de onde o usuário esteja localizado.

Vamos mergulhar em cada área e, por meio das diferentes ferramentas, veremos como trabalhá-las para melhorar o desempenho de cada URL. Por que digo cada URL? Porque, embora pareça óbvio, encontrei muitos casos em que apenas os dados da home foram avaliados, e claro, cada página de um site não carrega os mesmos recursos.

Google Developer Tools

Antes de começar, quero explicar algumas opções que o Google oferece por meio de suas ferramentas para desenvolvedores. Essa ferramenta é uma das mais importantes para analisar como um site funciona. Clique com o botão direito na página que o navegador tem aberta e aparecerá um painel com diferentes opções. Vamos em Inspecionar (Ctrl + Shift + I).

Uma vez aberta essa ferramenta, vamos para a opção NETWORK que você encontrará no topo. Se pressionarmos ENTER novamente no navegador, a ferramenta mostrará o carregamento dos diferentes recursos.

Na parte de baixo da imagem, podemos ver os dados que nos interessam para uma visão geral de como o site carrega.

Aprofundando mais nesse painel a partir do topo e olhando para a estrutura de colunas, temos:

• ›

  Name: o nome do recurso.

• ›

  Status: o código de resposta do recurso (200, 301, 404...)

• ›

  Type: o tipo de recurso (script, font, png, jpg, stylesheet...)

• ›

  Initiator: qual recurso dispara a requisição.

• ›

  Time: quanto tempo a requisição levou.

• ›

  Waterfall: uma representação gráfica dos tempos de carregamento de um recurso.

Se clicarmos com o botão direito no topo, podemos adicionar e remover colunas com essas informações.

Habilitar elementos informativos adicionais como Domain, Scheme ou Cookies pode ajudar em casos específicos a localizar recursos que possam estar nos causando algum tipo de problema, mas neste momento vamos ficar com os que vêm pré-definidos.

Há um aspecto que, embora muito interessante, vou tocar apenas levemente para que tenhamos em mente. A velocidade de conexão, especialmente no mobile, é uma peça-chave de como um site carrega. A partir desta ferramenta podemos simular velocidades mais lentas como 3G no mobile.

Como saber o peso de uma URL e como reduzi-lo?

O peso, seja em Megabytes ou Kilobytes, é uma das principais razões pelas quais uma URL leva tempo para carregar. Por isso começamos mergulhando neste aspecto, já que ele vai definir o caminho para alcançar uma boa otimização do nosso site.

Os dados a seguir vêm da ferramenta mencionada acima, GTMETRIX, e correspondem a um site que estou prestes a começar a otimizar.

Vamos focar nos dados da coluna direita, a que se refere a (Page Details), especificamente o Total Page Size.

À primeira vista, o peso deste site está bem acima da média, mas tenha em mente que o que importa não é o peso total do site, mas quanto tempo esse peso leva para carregar, porque há algo chamado Lazy Load, um recurso que adia o carregamento até que o usuário precise do recurso. Falaremos disso mais adiante.

Também podemos encontrar essa informação nas ferramentas de desenvolvedor, no painel que vimos acima, que vou lembrar você novamente.

Se você olhar embaixo, tanto os 7,5 MB quanto as 215 requisições chegam muito perto dos números reportados pelo GTMETRIX. É importante que você saiba de onde o GTMETRIX tira suas informações caso um dia queira usar uma ferramenta diferente.

Agora vamos ver o que está pesando tanto e como podemos consertar isso.

A opção Waterfall oferece uma visão visual de como os recursos carregam, mostrando a URL do recurso, status, domínio e a coluna Size. Se clicarmos nessa última coluna, ela ordena os pesos do maior para o menor e do menor para o maior.

Olhando para os pesos, podemos ver, como acontece na maioria dos casos, que as imagens são em grande parte responsáveis pelo peso excessivo da URL.

Não há especificação formal para o peso máximo que uma imagem deve ter, mas recomendamos no máximo 100 KB e, se você tiver a opção (se usa Photoshop, tem), configure as imagens para carregar progressivamente como JPG e evite PNG sempre que não precisar de um canal Alpha (transparência).

Reduzindo o peso das imagens vamos melhorar significativamente o carregamento do site, e há várias ferramentas que você pode usar. Eu pessoalmente otimizo com Photoshop, mas há opções online interessantes:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

Tanto o GTMetrix quanto a ferramenta do Google nos permitem ver os recursos por tipo, ou seja, apenas imagens, scripts, CSS...

Isso é útil para uma perspectiva mais ampla de onde trabalhar. Nesta URL, as imagens representam 4 MB de 7,2 MB, então grande parte do problema de peso está aí. Mesmo assim, há outros recursos que se destacam como extremamente pesados para seu tipo, como um arquivo CSS de mais de 700 KB e um Script de mais de 300 KB.

Neste ponto, gostaria de esclarecer que, quando realizamos uma otimização de velocidade de carregamento (WPO), temos que enfrentar certos problemas que, embora tenham soluções, não estão ao nosso alcance para agir.

Neste caso vemos um arquivo CSS muito grande. Se o designer criou um CSS de mais de 700 KB, otimizar esse arquivo específico será difícil.

O que podemos fazer para reduzir o peso desses arquivos?

Minificar (CSS, JS e HTML)

A minificação é um processo que busca reduzir o peso do arquivo removendo dados desnecessários como comentários, espaços, código repetido e código não utilizado. Há muitas ferramentas para realizar esse processo, exceto a parte do código não utilizado, que é mais difícil de otimizar e exigiria entrar manualmente no arquivo (algo que não recomendo).

Ferramentas para minificar arquivos

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

Felizmente estamos falando de WordPress, e como todos sabemos, no WordPress é muito raro não encontrar um plugin que cuide dessa operação.

Pessoalmente gosto de usar um totalmente gratuito, Autoptimize, e um pago, WP Rocket.

Neste artigo não quero explicar tanto como esses plugins funcionam, mas como realizar as tarefas de otimização. Porque se usarmos outros plugins, eles também têm essas opções, e o melhor é entender o que estamos fazendo.

Minificando com WP Rocket

Esta parte não é complexa. Basta ir à aba de otimização de arquivos e marcar a caixa minificar HTML. No WP Rocket essa opção se repete embaixo para arquivos CSS e JS. Ainda assim, recomendo habilitar essa caixa e testar. Repita essa opção uma de cada vez, já que se algo falhar será mais fácil identificar o problema.

Antes de verificar o efeito da minificação temos que limpar o cache, caso contrário não veremos o resultado do HTML atualizado.

Como limpar o cache do navegador?

Esses tipos de plugins vêm com opções para limpar o cache, que podemos ver no topo.

Outra forma é pelo navegador, uma vez que as Google Developer Tools estejam habilitadas (Ctrl + Shift + I).

Clique com o botão direito na seta de "recarregar página" e selecione "esvaziar cache e fazer recarga forçada".

Minificando com Autoptimize

Com o Autoptimize, a ação optimize é o que executa a minificação, com a particularidade de oferecer uma opção para manter os comentários HTML. Esses comentários geralmente são adicionados pelos desenvolvedores para guardar informações que podem ser úteis no futuro.

Para verificar que essa otimização teve efeito, iríamos para o código-fonte da URL e deveríamos ver algo assim:

O código fica ilegível, mas sua funcionalidade é a mesma.

Essas opções se repetem da mesma forma no WP Rocket e no Autoptimize para arquivos CSS e JS. Como mencionei antes, não recomendo otimizar tudo de uma vez, mas 1 por 1. Esses plugins guardam cópias dos arquivos minificados, então reverter ao original é possível desmarcando a caixa correspondente.

Para continuar reduzindo o peso da página temos mais 2 opções:

• ›

  Remover ou reduzir plugins que adicionam CSS ou JS ao carregamento.

• ›

  Remover ou cortar código não utilizado do arquivo CSS.

Essas 2 opções são mais complexas e exigem mais conhecimento, já que você precisa ter cuidado e garantir que não haja chamadas de outras páginas para a parte que você está removendo.

Embora remover plugins nem sempre seja possível por causa do recurso que eles fornecem, há plugins que são mais bem otimizados que outros, ou seja, menos requisições e JS mais leve. Então, no maravilhoso ecossistema do WordPress, quase sempre há uma alternativa.

Tempo de carregamento vs tempo de resposta

Agora é hora de falar sobre requisições, tempo de resposta e tempo de carregamento. Neste ponto temos que mencionar uma parte fundamental do processo: o servidor. A otimização do servidor geralmente está fora do nosso alcance, então é importante escolher uma solução eficiente.

Mas vamos por partes.

O que é uma requisição?

Uma requisição, ou HTTP Request, é uma chamada feita do cliente para o servidor para pedir um determinado recurso. As requisições podem atingir diferentes servidores.

As requisições podem ser HTTP ou HTTPS. Se olharmos a estrutura de uma requisição, podemos analisar onde acontece o atraso no tempo.

Análise do tempo de uma requisição HTTP

Vamos detalhar o que vemos neste gráfico de tempo.

• ›

  A requisição é iniciada mas bloqueada ou enfileirada: Se o bloqueio durar muito tempo pode ser por várias razões: requisições de prioridade mais alta ou muitas requisições para essa origem.

• ›

  DNS Lookup: o navegador está resolvendo o endereço IP da requisição.

• ›

  Connecting: o tempo que leva para conectar ao servidor para resolver a requisição. Se esse tempo for alto, pode indicar problemas de rede, erros de conexão ou um servidor sobrecarregado.

• ›

  Sending: a requisição do recurso é enviada.

• ›

  Waiting: este é o tempo que o servidor leva para resolver uma requisição e enviar uma resposta; se for longo, há um problema no servidor.

• ›

  Receiving: receber o recurso.

Uma requisição HTTPS adiciona mais uma etapa, mostrada aqui.

Estes dois screenshots pertencem a dois sites diferentes, um não otimizado (HTTP Request) e outro otimizado (HTTPS Request).

Se você olhar com atenção e comparar, a maior diferença está no tempo de espera. Nesses casos, você precisaria analisar o servidor com mais detalhe.

Requisições ao servidor: como podemos reduzi-las?

Como vimos, o número de requisições está intimamente ligado ao tempo de carregamento, então reduzir o número de requisições melhoraria os tempos de carregamento de uma URL. O bom senso desempenha um papel no processo de otimização e em saber se um recurso é realmente útil para o usuário ou para o nosso negócio. Este é o momento de dizer adeus a certos recursos que não acrescentam nada, mas não sou eu quem decide isso.

Ainda assim, temos opções para melhorar as requisições, mesmo que essas ações não tragam uma grande mudança no carregamento do site. Vou me repetir: o melhor é remover recursos que não acrescentam nada.

Combinar CSS e JS

Outra ação popular ao otimizar uma página web é combinar recursos CSS e JS, mas o que isso significa?

O objetivo de combinar é reduzir as requisições ao custo de aumentar o peso do arquivo. Combinar significa unificar os diferentes recursos CSS ou JS em um único.

Se os tempos de resposta forem longos, combinar pode ser benéfico. Se os tempos de envio forem muito lentos, talvez outra técnica seja melhor.

O ideal é combinar tendo um bom servidor, assim ganhamos dos dois lados.

Combinando recursos com WP Rocket e Autoptimize

A operação de combinar com esses plugins é tão simples quanto antes. Apenas marcamos a caixa correspondente.

No WP Rocket as opções para combinar CSS e JS são as mesmas; os painéis são praticamente idênticos. Como vemos na imagem, há uma caixa para adicionar o caminho dos arquivos que não queremos combinar.

Abaixo do checkbox, também vemos uma nota sobre não usar a opção de combinar se estivermos usando HTTP/2. Este artigo explica mais sobre HTTP/2.

O Autoptimize oferece mais opções para trabalhar com CSS e reduzir requisições. Na opção que marco, ele combina e te dá um aviso sobre o efeito que pode ter, mas no final isso é sempre relativo.

Nesta primeira parte do artigo, quis explicar em que consistem certas ações básicas, as que costumamos ver praticamente em todos os plugins de otimização WPO, mas ainda há muito que podemos fazer para melhorar tanto requisições quanto tempos de carregamento.

Configuração de cache

Sem dúvida, a otimização de cache é uma das ações em que perceberemos as maiores melhorias em como um site carrega. Neste artigo sobre SEO para WordPress expliquei como o cache funciona. Encorajo você a dar uma olhada para entender como funciona.

Autoptimize e WP Rocket realizam ações de cache, mas o WP Rocket te dá algumas opções a mais. Vale notar que os plugins transformaram essa otimização em algo mais simples: você mal tem algumas opções e o processo é rápido e indolor.

Como você vê, o WP Rocket permite trabalhar em 4 coisas:

• ›

  Habilitar cache para dispositivos móveis.

• ›

  Salvar arquivos separadamente para dispositivos móveis.

• ›

  Habilitar cache para usuários logados.

• ›

  Especificar o tempo para limpar o cache.

Depende de cada projeto qual opção selecionar, mas com tudo isso em mente meu conselho é:

• ›

  Cache para mobile sempre, porque embora a maioria dos sites seja responsiva, há conteúdo que você pode ter no mobile mas não no desktop.

• ›

  Arquivos separados.

• ›

  Sem cache para usuários logados, sobretudo porque se eu estou fazendo edições, não quero cache.

• ›

  Tempo de cache, que depende de quantas mudanças você faz no seu site. Se for um site de notícias diárias, curto; se for conteúdo que não atualiza com frequência, mais longo.

Lazyload

O recurso lazyload ajuda a exibir recursos (Imagens e Iframes) quando o usuário precisa deles; ou seja, o navegador não carrega esses recursos até que o usuário role até eles. Esse recurso é implementado em muitos plugins e até vem pré-configurado em alguns temas WordPress. A partir da versão 76 do Chrome, ele inclusive vem nativamente no navegador.

Isso significa que ao adicionar o atributo loading="lazy", o navegador já interpreta o carregamento lazy da imagem, mas claro que nem todo navegador vai interpretar isso, então recomendo continuar usando o plugin. Aqui está um vídeo retirado do web.dev mostrando um exemplo do que é o carregamento lazy de imagens.

Otimização de Iframe

Se usamos iframes para incorporar conteúdo de outros sites, temos duas ações que podemos usar para melhorar nosso carregamento.

• ›

  Carregamento lazy via a função lazyload

• ›

  Ou substituir o iframe por uma imagem até que o usuário clique nele.

Tanto a primeira quanto a segunda opção podem ser habilitadas por meio, mais uma vez, do nosso plugin de referência, WP Rocket.

O Autoptimize não tem essa parte, mas oferece a instalação de um plugin complementar para fazer isso https://wordpress.org/plugins/wp-youtube-lyte/

Carregamento adiado de arquivos JS com Defer ou Async

Os arquivos JS são um dos culpados pelo que as auditorias de velocidade chamam de bloqueio de renderização de uma página. Isso acontece quando, durante a renderização, o navegador para para baixar um arquivo JS e executá-lo. O objetivo da otimização WPO é entregar informação ao usuário o mais rápido possível, e é por isso que isso é considerado bloqueio, porque nada é renderizado até que o JS baixado execute.

É por isso que esse tipo de ação tende a ser sinalizado na auditoria. Ao usar plugins de terceiros ou temas que não estão bem otimizados, podemos ter JS que bloqueia a renderização porque está, por exemplo, no header.

Nesses casos devemos usar dois atributos que são adicionados no código de chamada do JS, Defer e Async. Para que esses atributos funcionem, os scripts precisam ser externos.

Na SEO Alive usamos o plugin Pre Party Resource Hints, que permite selecionar quais arquivos e qual método de carregamento você quer aplicar. Uma maravilha!

Qual é a diferença entre Defer e Async?

Embora ambos os atributos tenham um objetivo semelhante, evitar que a interpretação do DOM HTML seja interrompida pelo JS, há uma diferença notável entre os dois.

Com o atributo Async o recurso é baixado sem parar o carregamento do HTML, mas uma vez baixado, o carregamento do HTML é pausado para executar o JS; com o atributo defer o recurso também é baixado em paralelo com o carregamento do HTML, mas ele roda quando o carregamento termina, então não há bloqueio pelo script.

Nesse sentido há diferenças entre WP Rocket e Autoptimize. O WP Rocket toma decisões muito mais fáceis para você e age de forma semi-automática para evitar que o JS bloqueie a renderização; no Autoptimize, por outro lado, você só pode ativar a opção Async.

No Autoptimize, na aba extra temos essa opção para adicionar os arquivos JS que queremos carregar com Async, mas para maior flexibilidade eles recomendam outro plugin complementar, "Async Javascript".

Com esse plugin podemos trabalhar tanto com Defer quanto com Async, e ele inclusive oferece opções de um clique para facilitar as coisas. O bom desse plugin é que podemos trabalhar com scripts e excluir os que considerarmos necessários. No WP Rocket, por outro lado, temos que confiar no que o plugin faz, embora ele faça bem.

Essa opção está na mesma aba de otimização de arquivos.

O que é uma CDN e como ela pode nos ajudar?

Uma CDN é o que se conhece como rede de distribuição de conteúdo. A CDN é encarregada de salvar parte da informação e dos recursos para aliviar a carga do servidor por esses recursos e responder melhor à carga. As CDNs também têm uma função de cópia geográfica, para manter o recurso disponível em diferentes pontos e servi-lo ao usuário independentemente de onde ele se conecte. Geralmente esse tipo de serviço é usado para arquivos pesados como Imagens e Vídeos.

Contratar esse serviço é importante quando temos sites com muito tráfego, embora não deva ser descartado para sites com pouco tráfego.

Outras ações que vão nos render um pouco mais de melhoria

Para encerrar o artigo temos mais 3 melhorias que, embora não produzam grandes mudanças nos tempos de carregamento, vão nos ajudar a reduzir requisições, e no final é isso que queremos.

Otimização de fontes

A otimização de fontes pode ser feita por meio de plugins ou manualmente editando e otimizando o CSS. O ideal seria chamar apenas a fonte que você vai usar e não, como acontece em muitos casos, baixar um arquivo com todas as Google Fonts.

O Autoptimize tem uma opção para trabalhar com fontes.

É difícil dizer qual opção escolher sem ver o projeto, porque eu não sei qual fonte seu template usa e quando ela carrega, então o melhor é testar e ver o resultado.

Como você vê, logo depois das opções do Google Fonts temos "Remove Emoji", que vai nos poupar uma requisição ao servidor. Sua função é simplesmente converter os símbolos que representam emojis no ícone.

O WP Rocket também nos permite desabilitar esses emojis e também oferece a opção de impedir que o conteúdo seja incorporado em sites de terceiros.

No final há muitas ações para melhorar a velocidade de carregamento de um site. Nem sempre é possível trabalhar a fundo para otimizar cada recurso, porque depende do tipo de negócio e do que ele precisa.

Espero que este guia de otimização WPO seja útil e que você possa aplicá-lo em seus projetos ou para seus clientes.