O Google considera esta questão da performance tão importante que desenvolveu uma ferramenta para ajudar os webmasters e proprietários de websites na sua otimização. O Google PageSpeed Insights é uma ferramenta web que analisa o seu website e retorna uma pontuação relativamente á sua interpretação da otimização, em termos de performance, que o site apresenta. Esta análise pode ser página a página, ou para um website completo como vamos ver mais para a frente.
Para demonstração, vou utilizar a homepage do meu website. Para isso criei um ambiente de testes e uma réplica da homepage (relativamente com a mesma dimensão, mas com conteúdo dummy).
A importância da performance de um website
Ninguém gosta de sites lentos, nem mesmo o Google. É sabido que um site lento apresenta desafios a nível de usabilidade, sobretudo nos dispositivos móveis quando utilizam a rede de dados. Quantas vezes tentou aceder a um website no seu telemóvel e a velocidade do seu carregamento era tão lenta que lhe fez perder a paciência e navegar para outras paragens? As pessoas querem consumir conteúdos e encontrar o que precisam de uma forma fácil e rápida e os webmasters tem de ter todo o cuidado em produzir sites que sejam rápidos e fluídos.
O Google, para além de se preocupar com retornar os melhores resultados de pesquisa possíveis, uma das coisas que se preocupa é com a usabilidade dos websites que retorna nos resultados da pesquisa. Tanto se preocupa que a performance de um website faz parte dos fatores SEO que influenciam o posicionamento nos resultados da pesquisa.
Quem se preocupa com a visibilidade do seu website, tem agora uma motivação extra para tornar o seu website performante, para assim melhorar a sua usabilidade e também potenciar uma melhor visibilidade. Este ponto torna-se ainda mais relevante tendo em conta a migração dos websites pelo Google para o índice mobile-first.
Guia passo-a-passo para melhorar a performance do seu website
Recentemente lancei-me na aventura de aumentar a performance do meu próprio website. Sendo eu um consultor SEO, não poderia deixar de aproveitar o impulso que este fator de ranking pode oferecer e, claro, também aplicar esta melhoria nos websites de todos os nossos clientes. A análise da performance dos websites merece também um capítulo extenso na auditoria seo que executamos para os nossos clientes.
Estes são os resultados para a homepage do meu website à data da escrita deste artigo:
Posso desde já adiantar que é relativamente fácil aumentar a performance de um website – com algumas alterações, consegui chegar muito perto dos 90% - mas para chegar aos 100% a coisa complica um pouco. Não creio haver muitos benefícios em chegar aos 100%. Um valor entre 85%-90% deverá ser suficiente para a maioria dos casos, mas como cheguei aos 90% facilmente, não podia recusar o desafio de atingir 100%.
Nota: As técnicas que vou explicar neste artigo foram as necessárias para atingir o máximo de pontuação para o meu website. Deve ser relativamente simples replicá-las para qualquer outro website, mesmo para websites construídos em Wordpress, Joomla etc, embora cada caso é um caso. Estou a assumir também que o website também se encontra alojado num servidor Linux com Apache. Não sendo o caso, alguns dos passos que executei podem não ser aplicáveis.
Performance baseline
Como disse acima, a homepage do meu website foi duplicada e apresenta a mesma estrutura e dimensão. A página não otimizada encontra-se neste endereço:
https://test.seofreelancer.pt/step1.html
É uma simples página HTML/CSS, com algum texto e imagens. Para obter um baseline de performance, executei uma análise no PageSpeed Insights, que mostrou os seguintes resultados (Telemóveis e computadores):
Nada mau, mas também nada de especial. Bem melhor do que já vi em websites de alguns clientes (antes de serem otimizados, é claro!)
O site acima tem muito trabalhinho pela frente :)
Análise dos resultados do Google PageSpeed Insights
A ferramenta Google PageSpeed Insights retorna muita informação útil para nos ajudar a otimizar a performance do nosso site. Vejamos o que retornou para o baseline da minha homepage dummy:
Interpretando as estatísticas da página, podemos decifrar o seguinte:
- O PSI estima que a página requer 5 ciclos de bloqueio de conversão, a média é 4. Não está mau, tendo em conta que a média é 4, mas vamos tentar melhorar este indicador.
- A página requer cerca de 24 recursos (0,6 MB) para ser carregada, média é 75 recursos e 1 MB. Bastante razoável, mas também a página é relativamente leve. Neste ponto estamos bem abaixo da média, mas vamos tentar melhorar o nrº de recursos a serem carregados (quanto menos melhor, menos chamadas ao servidor) e também reduzir, se fizer sentido, a dimensão em KB da homepage.
- Sugestões de otimização. Aqui está o suminho todo. Estas sugestões vão nos permitir atingir o nosso objetivo, chegar aos 100%.
Eliminar o Javascript e CSS de bloqueio
O que a ferramenta nos está a tentar explicar é que os recursos que estamos a carregar na homepage, neste caso Javascript e CSS, estão a provocar um bloqueio da conversão do conteúdo “above-the-fold” (acho que em Português se diz “acima da dobra”). Isto significa que o browser não é capaz de mostrar o conteúdo visível na área de visualização disponível, sem que os recursos acima sejam completamente carregados. Como esses recursos são ficheiros JavaScript e CSS com alguma dimensão, Jquery e Bootrstrap por exemplo, isto pode fazer com o a apresentação do conteúdo inicial do website sofra um atraso considerável.
Munidos desta informação, podemos olhar para o código fonte da nossa homepage e verificar quais as melhorias que podem ser implementadas. Abrindo o ficheiro html da homepage e localizando os ficheiros acima referidos o que vemos? Olhemos para a imagem abaixo:
Uma coisa que salta à vista é a inclusão destes ficheiros diretamente no segmento <head> da página. Uma das recomendações normalmente aplicadas ao JavaScript é por exemplo transferir a chamada dos scripts do segmento <head> para o <body>, imediatamente antes do fecho desta tag, isto é, copiar todo o código:
<script src="assets/js/jquery-2.1.4.min.js"></script>
<script src="assets/js/bootstrap.min.js"></script>
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/cookie-bar/cookiebar-latest.min.js?tracking=1&thirdparty=1&always=1&scrolling=1"></script>
e coloca-lo no fim da página, antes da tag </body>, o que ficaria mais ou menos assim:
Será que isto vai melhorar a nossa performance? vamos verificar com o Google PageSpeed Insights. Para isso criei um novo ficheiro html com estas alterações, acessível em:
https://test.seofreelancer.pt/step2.html
Já estamos a verificar melhorias. Para otimizar o Javascript o Google sugere colocá-lo “inline” (incorporar diretamente no código ao invés de um ficheiro externo) ou utilizar o atributo html “async”. Incorporar no html está fora de questão, estamos a falar de uma framework Jquery, mas vejamos se o atributo “async” ajuda em alguma coisa:
Piora, não ajuda! Um outro problema que detetei foi o menu mobile do bootstrap também deixou de funcionar, logo a solução, pelo menos para a minha homepage não passa pelo carregamento assíncrono dos recursos JavaScript.
Voltando ás estatísticas, podemos verificar que o JavaScript já não é problema, apenas nos resta resolver o problema do carregamento do CSS.
Para o CSS, a recomendação que vos deixo passa por colocar o código CSS que bloqueia o conteúdo “inline”, isto é, diretamente no código fonte da página.
Mas como é que eu sei qual é o código que está a provocar o bloqueio, perguntam vocês? Bem, isso é relativamente fácil, basta utilizar uma ferramenta como a que vou mostrar a seguir. A minha preferida pode ser encontrada aqui:
https://www.sitelocity.com/critical-path-css-generator
Esta ferramenta consegue isolar o código CSS que bloqueia a geração de conteúdo e tem o benefício adicional de gerar um único ficheiro CSS comprimido com todos os recursos CSS da sua página, reduzindo assim também as chamadas ao servidor.
Nota: Recomendo vivamente a leitura do conteúdo deste site, que explica em pormenor o que é executado. Por questões de brevidade, neste artigo vamos nos cingir ao básico.
Para sabermos qual o código CSS que provoca bloqueio basta colocar o URL da página que queremos analisar e clicar “Generate Critical Path CSS”. Abaixo o exemplo:
Aguardamos alguns momentos e obtemos o seguinte:
O que fazer a seguir? É simples:
- Copiar todo o código CSS contido na caixa "Critical Path CSS" e colá-lo diretamente na secção <head> do vosso website. Devem também remover
todas as chamadas a ficheiros CSS que la estejam presentes. No caso do meu website, fica algo parecido com a imagem abaixo:
- Copiar o código JavaScript da 2ª caixa “Load combined CSS file after page load” e colocá-lo no fim da página, imediatamente antes do fecho da tag <body>
- Descarregue o ficheiro CSS minimizado. Este ficheiro combina todos os recursos CSS num só ficheiro, o que nos vai permitir também reduzir
o nº de chamadas ao servidor. Coloque o ficheiro no local que definiu para o CSS e ajuste o caminho do ficheiro CSS minimizado. Encontre o
segmento de texto "PATH_TO_COMBINED_CSS_FILE" no código e substitua-o com o caminho e ficheiro CSS minimizado (destacado a amarelo na imagem).
De seguida, gravar tudo, upload e novo teste:
UAU! 98% nos telemóveis e 76% nos computadores! Estamos quase lá, mas falta o quase. Curiosamente a secção “computadores” mostra um nível de otimização inferior, mas vamos tentar obter 100% a tudo.
Ativar a Compressão
Voltando a analisar a estatística, o Google PageSpeed Insights diz-nos que devemos ativar a compressão. A compressão reduz o tamanho dos ficheiros o que por sua vez aumenta a sua velocidade de download.
Se clicarmos no link “Ative a compressão”, chegamos à página sobre compressão do Google Developers. Esta página (leitura recomendada) explica-nos que temos tudo a ganhar em ativar a compressão gzip do lado do servidor, porque todos os browsers são compatíveis com este formato, e ao estar ativa, a velocidade de transmissão de dados pode aumentar até 90%. Parece-me bem, agora vamos ver como ativar a compressão do lado do servidor.
Ponto importante! O que vai ser explicado abaixo funciona com servidores Linux com Apache. Caso utilizem outro tipo de servidores para alojarem o vosso website, devem procurar a melhor forma de fazer algo parecido. Para isto funcionar, o vosso alojamento deve permitir a ativação do módulo de compressão respetivo. Se utilizarem um prestado de serviços de alojamento, partilhado ou não, falem com o vosso suporte técnico caso as instruções abaixo não funcionem ou encontrem algum tipo de dificuldade ou problema.
No meu caso, utilizo um alojamento partilhado normal e não tive qualquer problema, funcionou á primeira.
PS. Para quem tem curiosidade é a dominios.pt (Claranet) que recomendo - preços acessíveis, boa performance e suporte.
PS2. Não sou afiliado :)
Para ativar a compressão temos de instruir o apache a servir ficheiros comprimidos com o gzip. A forma mais simples que encontrei passa por introduzir no vosso ficheiro .htaccess (ou criar um se não existir) e colocar o seguinte código:
#Gzip
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript
</ifmodule>
#End Gzip
O que isto faz é ativar a compressão para todos os ficheiros html, texto, CSS e JavaScript. Foi criado um ficheiro .htaccess co o código acima e colocado na raiz do site. Vamos testar para ver quais foram as melhorias:
Espetacular! 99% nos telemóveis e 95% nos computadores. Já não falta muito para chegarmos aos 100%. Honestamente, provavelmente não haverá mais benefício em passar dos valores já atingidos, mas como ambicionamos chegar cada vez mais longe (verdade?), vamos arrumar com isto…
Tirar partido da cache do navegador
Voltando ás estatísticas, só nos falta endereçar as questões relacionadas com a cache do navegador.
A cache é uma forma utilizada para evitar chamadas desnecessárias ao servidor e deve ser aplicada a recursos que têm a característica de não sofrerem alterações frequentes. Os browsers, através da definição de uma validade ou idade máxima de um recurso, podem escolher carregá-lo diretamente do disco local, muito mais rápido, ao invés de iniciar uma nova chamada ao servidor remoto.
Uma forma relativamente simples de ativar a cache passa também por colocar instruções específicas no ficheiro .htaccess, que permitem alterar os headers do servidor no que diz respeito ao controlo da cache. Vejamos quais foram essas instruções no caso da minha homepage:
# One year for image files
<filesMatch ".(jpg|jpeg|png|gif|ico)$">
Header set Cache-Control "max-age=31536000, public"
</filesMatch>
# One month for css and js
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=2628000, public"
</filesMatch>
O ficheiro .htaccess foi alterado e de novo foi feito o upload para a raiz do site. Vamos ver como estamos agora em temos de recomendações. Será que chegamos aos 100%? O que acham?
100/100! Não foi assim tão difícil, pois não? Se voltarmos ás estatísticas podemos observar agora que o PSI estima que esta página requer 0 ciclos (5 anteriormente) de bloqueio de conversão e cerca de 24 recursos (0,4 MB) para ser carregada (0.6 MB anteriormente).
Resumo
Com algumas ações, conseguimos atingir os 100% a nível de recomendações da ferramenta PageSpeed Insight. Ao melhorarmos a performance dos nossos websites, ganham os utilizadores em termos de usabilidade e tempo de download, ganhamos nós com visitantes mais contentes e até podemos melhorar o nosso ranking a nível de SEO. Resumindo os passos que foram dados:
- Passar os recursos JavaScript para o fim da página, imediatamente antes do fecho da tag <body>
- Eliminar o CSS de bloqueio, incorporando o CSS que está no caminho crítico na secção <head> da página, e carregando apenas um ficheiro comprimido com todos o CSS necessário
- Ativar a compressão gzip no servidor
- Tirar partido da cache do navegador através da inclusão de tempo de validade nos recursos estáticos
É importante terem a noção que todos estes passos foram suficientes para este caso, e cada caso é um caso. Poderão haver sites e configurações de alojamento em que sejam necessárias configurações distintas ou adicionais. Se no vosso caso encontrarem dificuldades, soluções alternativas ou diferentes, não hesitem em partilhá-las. Todos temos a ganhar quando partilhamos conhecimento.
