Saltar para os conteúdos

Regras de Usabilidade para Performance

A velocidade com que as páginas de um website carregam são um dos pontos mais críticos de uma boa experiência de utilização.

Há uns anos atrás, dizia-se que os utilizadores esperariam no máximo 10 segundos para que os conteúdos carregassem. Hoje em dia, com ligações de banda larga cada vez mais rápidas (mesmo em redes móveis), esse número tem vindo a diminuir.

As expectativas dos utilizadores têm vindo a aumentar. Cerca de 47% dos utilizadores espera que a página carregue em 2 segundos ou menos e 40% dos utilizadores começam a ficar impacientes se a página demorar mais do que 3 segundos a carregar.

Um website lento pode acarretar perdas no seu volume de vendas. Estima-se que por cada segundo de espera no carregamento das páginas haja uma descida de 7% na conversão de vendas. Isto significa que um website de e-commerce que tenha um volume de vendas de 10 mil euros por dia pode esperar uma quebra de 255 mil euros ao final do ano por causa daquele 1 segundo a mais que as páginas demoram a carregar.

Por tudo isto, a performance de um website é um factor muito importante na esperiência de utilização, e quanto mais rápido for o carregamento das páginas, melhor será essa experiência.

Aqui está uma lista de ferramentas úteis para medir o desempenho de websites:

Aqui está uma lista completa de recursos para medição de performance em sites web em constante atualização.

Nota: Estas ferramentas medem o desempenho página a página. Não basta testar o carregamento apenas da homepage, pois as páginas interiores são igualmente importantes porque é nelas que está o conteúdo principal do website.

Comprimir e minificar todos os ficheiros estáticos

Todos os ficheiros estáticos (ex: CSS, JS e HTML) devem ser minificados. Isto permite poupar bastantes KB sempre que as páginas são carregadas.

A maior parte das frameworks já têm uma versão minificada dos seus ficheiros estáticos, normalmente com a terminação "*.min.css" ou "*.min.js". Por exemplo, usando a framework InK, o tamanho do ficheiro ink-all.js (que inclui todo o JavaScript que adiciona interatividade às páginas) é cerca de 70% maior do que a versão minificada ink-all.min.js. Ou seja, ao usar a versão minificada, estamos a poupar bastantes KB no carregamento inicial da página.

Existem ainda várias ferramentas que permitem a compressão de ficheiros de modo a que possamos ter todos os nossos ficheiros comprimidos (caso queiramos incluir uma folha de estilos ou um script que não esteja minificado). Basicamente, o que a minifação faz é limpar todos os espaços desnecessários e comentários no código para que este passe a ocupar muito menos espaço em disco.

GZIP

A parte de minificação pode ser feita por quem está a desenvolver o website (designer ou developer). Já a parte de servir os ficheiros comprimidos (normalmente com GZIP) tem de ser feita ao nível do servidor.

O GZIP funciona da mesma forma que o ZIP nos ficheiros que temos no nosso computador. Assim, além de termos já os ficheiros minificados, podemos ainda comprimi-los, tornando-os ainda mais pequenos e assim aumentar a rapidez com que as páginas são carregadas.

No entanto, é preciso ter acesso à configuração do servidor para ativar a compressão dos ficheiros, por isso, devem pedi-lo às equipas de operações ou aos administradores das máquinas onde têm os websites alojados. A não ser que tenham um servidor Apache e tenham permissões para adicionar um pequeno ficheiro .htaccess.

Os ficheiros .htaccess devem ser colocados na pasta principal do website (root) e podem conter uma série de configurações que o servidor vai interpretar. Neste caso, queremos comprimir todos os ficheiros estáticos, e como tal, basta adicionar o seguinte ao ficheiro:

# comprimir ficheiros de texto, html, javascript, css, xml e webfonts:
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
    AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml
    AddOutputFilterByType DEFLATE image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf application/x-font-woff font/opentype
</Ifmodule>

Condensar os ficheiros externos num só (ou no menor número possível)

Quantos menos ficheiros externos (CSS, JS) forem carregados, mais rápido será também o tempo de carregamento da página, pois por cada ficheiro que incluímos, estamos a fazer um pedido diferente ao servidor. Assim, devemos tentar juntar o máximo de ficheiros CSS num só (ou no menor número possível) e fazer o mesmo para os ficheiros JavaScript. Desta forma reduzimos o número de pedidos, acelerando o carregamento da página.

<!-- Em vez de carregar vários ficheiros externos -->
<link rel="stylesheet" type="text/css" href="/css/fonts.css">
<link rel="stylesheet" type="text/css" href="/css/styles.css">
<link rel="stylesheet" type="text/css" href="/css/layout.css">
<link rel="stylesheet" type="text/css" href="/css/helpers.css">

<!-- Concatená-los apenas num único ficheiro, minificado -->
<link rel="stylesheet" type="text/css" href="/css/all-styles.min.css">

Nota: Alguns browsers têm um limite no número de regras que cada ficheiro de CSS pode ter. Por isso, pode ser necessário ter de partir o CSS em mais do que um ficheiro, para que todas as regras de CSS sejam corretamente aplicadas. O ideal é sempre ter o menor número possível de pedidos, mas não precisa de estar obrigatoriamente tudo num único ficheiro.

Para os ficheiros JavaScript deve ser feito o mesmo. Sendo que, se se estiver a usar uma framework, provavelmente será melhor deixar o script principal da framework intocado.

<!-- Em vez de carregar vários ficheiros externos -->
<script type="text/javascript" src="/js/framework.min.js"></script>
<script type="text/javascript" src="/js/script-1.js"></script>
<script type="text/javascript" src="/js/script-2.js"></script>
<script type="text/javascript" src="/js/script-3.js"></script>

<!-- Juntar o máximo de ficheiros num só -->
<script type="text/javascript" src="/js/framework.min.js"></script>
<script type="text/javascript" src="/js/all-scripts.min.js"></script>

Evitar o uso de estilos e scripts inline

Todos os estilos e scripts devem ser incluídos através de ficheiros externos. Isto permite que o browser faça cache desses ficheiros e apenas precise de os carregar da primeira vez que o website é acedido.

A inclusão de estilos e scripts inline pode ser usada em casos pontuais, mas se todos os estilos e scripts forem concatenados num único ficheiro, o ganho de performance será maior.

Colocar o CSS no topo e JS no final

A chamada dos ficheiros CSS deve ser colocada no topo do documento, dentro da tag <head>. Isto permite que os estilos do site sejam carregados à cabeça e que a página possa carregar já com todos os elementos estilizados.

Já os ficheiros JavaScript devem, sempre que possível, ser colocados no final do documento, imediatamente antes do final da tag </body>. O problema de carregar os ficheiros JS no topo é que o resto da página vai demorar muito mais tempo a carregar completamente enquanto todas as interações em JavaScript não forem carregadas. Ao colocar estes ficheiros no final, podemos carregar imediatamente os conteúdos da página (ex: textos, imagens, etc) e no final carregar a interatividade. isto permite dar uma perceção ao utilizador de que a página está totalmente carregada (pois fica imediatamente visível), mesmo quando ainda estão a ser carregados os scripts no final.

Os websites que dependem do carregamento do JavaScript para mostrar os conteúdos estão a piorar a experiência de utilização, pois obrigam a esperar que todo o HTML e todo o JavaScript seja carregado para que a página seja depois finalmente renderizada no browser.

Evitar que a página seja demasiado pesada

Apesar de termos hoje em dia larguras de banda bastante elevadas no acesso à Internet (mesmo em redes móveis), quanto menos peso a página tiver, mais rápido será o seu carregamento. E não nos podemos esquecer que cada vez mais os acessos são feitos através de dispositivos móveis, muitas vezes com planos de dados limitados. Não queremos que o carregamento de uma única página do nosso website gaste 10% do tráfego mensal de um utilizador com um plano de dados limitado.

Não existe propriamente um valor máximo em MB para o peso de uma página, mas podemos usar o senso comum e exemplos reais de utilização para calcular se temos ou não uma página demasiado excessiva.

Por exemplo, para um utilizador com um plano de dados de 200MB mensais (o plano mais comum oferecido pelos operadores nacionais), uma página com 2MB consome 1% do seu tráfego mensal.

Podemos considerar que 2MB é um valor aceitável para um website com muito conteúdo interativo, mas inaceitável para um website com conteúdo principalmente textual (ex: artigo num site noticioso). Tudo depende do contexto da informação que vamos disponibilizar, mas devemos fazer todos os esforços para reduzir a quantidade de dados transferidos pelo utilizador.

Umas das formas mais eficazes de reduzir o peso das páginas é otimizar as imagens que estão a ser carregadas.

Fazer lazyloading dos conteúdos mais pesados fora da área visível do ecrã

O "lazyloading" é o conceito de carregar os conteúdos mais pesados (normalmente as imagens) apenas quando as mesmas estão na área visível da janela do browser. Ou seja, num website com muitas imagens, as que estão mais abaixo na página (fora da área visível), não são carregadas a não ser que o utilizador faça scroll para baixo e passe por elas.

Isto permite que o carregamento das páginas seja bastante mais rápido e leve, pois apenas se carrega uma parte da página que o utilizador está a ver. Para os casos em que o utilizador apenas carrega a página para poder usar o menu para navegar para outro conteúdo, os ganhos são bastantes, pois não foi necessário carregar uma página inteira de conteúdos só para que o utilizador pudesse clicar num link no topo para mudar de página.

No entanto, o uso de "lazyloading" não faz com que seja aceitável ter páginas demasiado pesadas, pois se o utilizador fizer scroll, ele vai carregar na mesma todos os MB da página.

Exemplo do uso da framework InK para fazer lazyloading de imagens.

Comprimir as imagens usando serviços de otimização

As imagens carregadas nas páginas web devem estar preparadas para serem o mais leves possível, pois as imagens são normalmente o elemento mais pesado numa página web.

Na maior parte dos casos, uma imagem que é exportada do PhotoShop, FireWorks ou outro qualquer processador de imagem não está devidamente otimizada para a web, pois pode conter ainda informação sobre layers ou estar a usar uma palete de cores inteira em que apenas são necessárias 4 ou 5 dessas cores, entre outros fatores.

Existem algumas ferramentas que permitem otimizar as imagens sem que estas percam qualidade ou trasparência (caso exista), nomeadamente:

O Google fornece uma lista de recomendações específicas para otimização de imagens para a web.

Pontos de verificação

Estes são exemplos de alguns dos pontos principais de avaliação que equipa de usabilidade vai verificar e qual a sua classificação.

Tipo de Problema Classificação (saber mais) Observações
Uso de ficheiros externos não minificados Crítico
Ficheiros externos não estão a ser servidos comprimidos com GZIP Crítico
Estão a ser chamados vários ficheiros externos de estilos e scripts em vez de concatenar no menor número de ficheiros possível Problema Grave
Estão a ser usados vários estilos e scripts inline Problema
As páginas são demasiado pesadas (vários MB) Crítico
Em páginas com muitas imagens, não está a ser usado o lazyloading Problema
O website tem uma classificação inferior a 85 pontos em todas as categorias do PageSpeed Index Problema Grave

Nota: Esta não é uma lista exaustiva, apenas um exemplo. Podem existir mais problemas identificados na avaliação de usabilidade ao website que não estão listados aqui. Cada website tem as suas particularidades e contextos de utilização diferentes.

Referências

  1. Uma lista de todos os recursos disponíveis para medição de performance web
  2. Jakob Nielsen: Website response times
  3. Kissmetrics: Loading time
  4. 14 Rules for Faster-Loading Web Sites