Porque designers precisam se preocupar com a performance de websites?
Faz algum tempo que não deixo aqui a minha contribuição para a comunidade. Fiquei um bom tempo estudando sobre otimização para websites, especialmente na GOL, onde eu pude aprender muito sobre este trabalho que não se limita apenas aos desenvolvedores web.
Parece um pouco óbvio mas designers precisam trabalhar com otimização e performance para ajudar na conversão do site, na experiência do usuário e na escalabilidade do produto. Afinal, sempre temos que melhorar os nossos produtos mas não apenas em entendimento do negócio e do público, mas como eles também usam o que criamos e como percebem a experiência como um todo.
Você já parou pra pensar o que deixa um site lento? Existem vários motivos:
- Número de requisições que o servidor faz;
- CSS não otimizado;
- HTML não identado;
- Muitas bibliotecas de javascript;
- Muitos serviços de terceiros no site (API Google Maps, Pixel do Facebook, Pesquisa Foresee, etc…)
- Imagens avulsas e sem otimização ou unificação em um mesmo arquivo (sprites);
- Servidor sem CDN (Content Delivery Network);
- Arquivos sem cache;
Estes são alguns deles…
Tá bom! Mas estas coisas de servidor e desenvolvimento não é papel do designer…
Já ouvi e vi muito sobre até onde vai o papel do designer e onde começa o do desenvolvedor na hora de construir um site. O designer entrega o PSD ou Sketch para que o desenvolvedor extraia os assets e construa o layout bonitão que foi criado.
Erro achar que é apenas este entregável deixará o produto no mínimo aceitável para ir para o ar e que rode tudo certo por parte do designer. Desenvolvedores não precisam ou não deveriam precisar extrair assets dos arquivos que entregamos só porque eles vão desenvolver o layout que construímos. Também não adianta entregar o layout apenas no Zeplin ou Figma. Precisamos otimizar todas as imagens que estão nele.
Algumas perguntas para refletirmos:
Como o servidor que o site está hospedado processará as imagens?
Como o usuário receberá as imagens no navegador?
Será que a imagem que está no arquivo final está otimizada?
Como o site carregará no mobile?
A ideia aqui não é dizer que o designer tem que aprender tudo que envolve a parte de desenvolvimento, mas quanto mais ele souber, melhor. Isso ajuda a evitar erros e ganhar tempo na hora de construir o produto. Também, quanto mais o designer estiver próximo dos desenvolvedores e estratégia do produto como decidir qual plataforma usar, por exemplo, mais efetiva vai ser a construção. Lembre-se que designers e desenvolvedores não são inimigos, mas sim um time.
Tá bom, falou sobre otimização mas não mostrou como isso acontece…
Uma das coisas que dependem do designer para começar a trabalhar com otimização e performance são as imagens que ele cria. Sendo assim entender como otimizar as imagens do produto final é o ponto inicial aqui. Quando me refiro a imagens engloba gráficos, ícones, ou qualquer arquivo com base em bitmap.
#1 — Entender a diferença de Baseline x Progressive JPG
Na web o mais comum de se trabalhar com metadados de imagens em JPG que são conhecidos como baseline e progressive. Entre eles não tem nenhuma diferença visual, porém na hora que o navegador carrega a imagem é que vemos como eles se comportam de forma diferente.
Os navegadores web carregam a imagem dependendo do metadado que está incorporado no arquivo. O tipo baseline carrega parte por parte da imagem em sua resolução original enquanto o tipo progressive carrega a imagem de uma só vez, em baixa resolução e vai carregando gradualmente os pixels.
Isso permite que o usuário tenha a primeira visualização da imagem mesmo que em baixa resolução ao invés de esperar que a imagem carregue por completo.
Dependendo do tamanho do arquivo, as imagens JPG progressive podem ser melhor otimizadas resultando em um tamanho de saída menor. Isso leva a carregar em menos tempo a imagem, impactando na experiência positiva. Os navegadores mais modernos exibem as imagens com este método mais rapidamente que no tipo baseline.
Note que o Instagram usa este método de otimização para deixar o feed do usuário mais rápido para ser carregado. Como o modelo de negócio do Instagram é em cima de imagens, faz todo o sentido eles trabalharem com esta otimização. Isto impacta positivamente na experiência do usuário.
Também acontece com o Whatsapp onde é possível ter um preview da imagem antes de baixá-la.
#2 — Criando imagens em formato progressive JPG
Se você usa o Photoshop, ele permite que você exporte as imagens em progressive na janela de saída de arquivo. Apenas selecione a opção Progressive e exporte o asset.
O Sketch permite exportar as imagens em Progressive JPG.
Também é possível usar ferramentas disponíveis como o site Jpeg.io para converter para o tipo progressive. https://www.jpeg.io/
Se você quiser conferir se a imagem está ou não no formato progressive, você também pode usar o Detector for progressive JPEGs, criado por Sergej Müller no site CodePen. https://codepen.io/sergejmueller/full/GJKwv.
#3 — E se as imagens estiverem em PNG?
Você pode trabalhar usando as ferramentas disponíveis para otimização como http://optipng.sourceforge.net/ ou https://tinypng.com/. O processo de compressão de imagens em PNG de forma manual é bem mais complexa que em JPG e deixarei este assunto para um outo artigo. Eu uso sempre a TinyPNG como ferramenta preferencial para otimizar os arquivos. É possível ter uma redução considerável nos arquivos usando esta ferramenta. Ela funciona também para arquivos em JPG.
Usando a WebPageTest como ferramenta de suporte para otimização e performance
WebPageTest é uma ferramenta de análise de performance criada inicialmente pela AOL em 2008 para uso interno e que depois foi disponibilizada como open-source para a comunidade e hoje ela é suportada pela comunidade do GitHub. Apesar da interface ainda ser da época que ela foi aberta, pouco se trabalhou em melhorar a interface. Porém, sua efetividade é considerável e suportada pelo Google em Hackathons e eventos de performance.
O objetivo de trazer esta ferramenta para este artigo…
É possível usá-la para identificar o que causa lentidão no site. Eu vou explicar como funciona a análise e como tirar proveito dela. Usei como exemplo o site do PayPal que tem a sua página inicial estática. Assim, é fácil dar manutenção e propor melhorias por não existir a necessidade de uma troca constante de arquivos.
1 — Rodando o teste
#1 — URL: Informe a URL do site;
#2 — Test Location: Escolha a Região que você está. Isto testará o CDN do servidor (explicarei com detalhes)
#3 — Number of Tests to Run: Defina o número de testes. Quantos mais testes você informar, mais assertivo será o teste. Porém, levará mais tempo para ser executado. Esta ferramenta trabalha com lista de testes simultâneos gerando como se fosse uma "fila de espera" para mostrar o resultado.
#4 —Repeat View: First View and Repeat View permite que o teste execute o site ser carregado 2x. A primeira vez sem cache e a segunda vez com cache. Isso permite ver a efetividade do armazenamento em cache do site;
#5 —Capture Video: Permite gravar um vídeo de como o site é carregado mas é exibido em formato filmstrip (1 segundo por frame em formato JPG);
#6 — Label: Defina o nome do teste para consultas de comparação;
2 — Analisando os dados
Aqui pode parecer muito complicado mas não precisa entender tudo para se tirar alguns insights para a melhoria da performance. O site do PayPal é muito bem otimizado e isso garante o que a ferramente define, como notas que vai de F ao A. Quanto mais próximo do A, melhor otimizado.
Link do resultado do teste: https://www.webpagetest.org/result/181228_2M_cd667d213961ece3e9b05c04b59dcd12/
#7 — Critério de notas: A ferramenta usa alguns critérios para informar o quanto os site está otimizado. Sendo assim temos a definição para cada nota:
First Byte Time
É quando o usuário começa a navegar e o primeiro byte do servidor chega até o navegador. É o montante de bytes que o navegador gasta construindo a página para o usuário.
Keep-alive Enabled
É uma configuração padrão do servidor como parte do protocolo HTTP 1.1 e serve para cada nova requisição de conexão que o site realiza, para que possa ser re-utilizada para diminuir o tempo de download.
Compress Transfer
Recursos que podem ser otimizados usando o GZIP.
Compress Images
É a compressão das imagens que são transferidas do servidor para o site, reduzindo o tempo de download e otimizando a conexão.
Cache Static Content
São elementos que não mudam com frequência e podem ser armazenados em cache. Algumas imagens como ex: logo, js e css.
Effective use of CDN
É a configuração do mesmo site em diversos servidores ao redor do mundo. O usuário recebe as informações de acordo com o servidor mais perto dele. Conhecido como Content Delivery Network.
#8 — Performance Results (median run):
First View
É o teste no cenário que o navegador não possui cache ou cookies e representa a primeira experiência que o usuário tem com a página.
Repeat View
É o teste no cenário que o First View é executado sem limpar nenhum cache ou cookie no servidor. É quando o usuário re-visita a página pela segunda vez em diante.
Document Complete
É o agrupamento de métricas que são coletadas até o nevagdor considerar que a página foi carregada. Normalmente acontece quando todas as imagens e conteúdo foram carregados mas não inclui aqueles que são ativados por execução do JS.
Fully Loaded
É o agrupamento de métricas que são coletadas até que houvesse 2 segundos da atividade de rede após o término do documento. Isso geralmente inclui qualquer atividade que é acionada pelo javascript depois que a página principal é carregada.
Load Time
É o tempo que o usuário começa a navegar na página até o cenário de Document Complete. Normalmente quando todo o conteúdo é carregado.
First Byte
É o tempo quando o usuário começa a navegar até o primeiro bit enviado pelo servidor chega na página. É referido ao tempo que o servidor gasta para construir a página ou conhecido como “Back-End Time”
Start Render
É o tempo que o primeiro elemento acontece na página. Até esse momento, é exibido uma página em branco para o usuário. Pode ser um background-color, um texto ou qualquer outro elemento.
DOM Elements
A métrica de elementos DOM é a contagem deste tipo de elementos testados na página, conforme medido no final do teste.
Requests
É o número de requisições que o servidor faz como pedaços para construir a página. Eles são geralmente conteúdo, imagens, CSS, JS, etc…
Bytes In
É a quantidade de dados que o navegador tem que fazer em ordem para carregar a página. Também é conhecido como “Page Size”
#9 —Tests Result: É o resultado do teste de forma gráfica. É possível ver como as requisições se comportam, o que é carregado e como é carregado.
Se houver algum problema como erro 404 ou lentidão, a barra aumenta de acordo com o tempo de carregamento. No exemplo abaixo, as barras amarelas representam o redirecionamento das URLs (código 302).
#10 — Content Breakdown: Aqui é possível ver qual tipo de requisição de servidor o site faz. No caso na home do site do PayPal, quase metade das requisições do servidor 46,8% e de bytes 61,9% do site são imagens. Geralmente as imagens são as que mais impactam no carregamento de uma página.
3 — Extraindo dados
Na aba de Performance Review podemos ver quais imagens são baixadas no site. Assim conseguimos prever quantas requisições o servidor faz:
Análise
Desta lista de 63 itens, 29 são imagens que estão sendo carregadas individualmente. É possível ter uma redução na quantidade de requisições transformando as imagens em uma só (sprite).
Cenário atual: 63 requisições | 29 são imagens
Cenário de melhoria: 63–28 = 35 requisições (56% de redução)
Note também que apenas uma imagem está em JPG e não está no tipo progressive, marcado com um X. Aqui já teríamos uma ação para ajudar melhorar o tempo de carregamento da página. No caso é o banner principal.
Usando Sprites
Esta técnica permite que as imagens estejam agrupadas todas dentro de um único arquivo. A exibição de cada item separado acontece via CSS funcionando como uma máscara. Usamos esta técnica para reduzir a quantidade de requisições no servidor.
Otimizando as imagens
Se caso o trabalho de otimização apenas permitir que você atue em cima de algum produto existente, é possível ter ganhos consideráveis usando as ferramentas disponíveis para compressão de imagens.
Eu extraí as 29 imagens do site do PayPal com tamanho de 732kb em disco e usei na ferramenta TinyPNG para fazer a compressão:
O resultado é 58,2% de redução no peso das imagens. É notável ver o ganho em performance quando temos um cenário que o site tem 732kb e vai para 306kb.
De acordo com o relatório de performance da WebPageTest, o tempo de carregamento das imagens do site é de 1.3s com imagens de 732kb em uma velocidade de 1mb/s. Se otimizarmos as imagens, temos uma redução de 58,2% de velocidade também, o que resultaria em 757ms de download. Este cenário em uma conexão 3G seria muito melhor para o usuário que iria gastar menos dados do pacote, influenciando na experiência positiva dele.
Considere também…
Se estiver usando alguma imagem que será aplicada em fundo branco, evite usar PNG como imagem transparente. Além de não fazer diferença visualmente falando, o PNG transparente costuma ser mais pesado que JPG.
Conclusão
Se você está criando um site do zero, considere o uso de sprites. O grande ponto aqui é a manutenção das imagens ao longo da vida do produto. Se for um e-commerce, apenas as imagens fixas valeriam a pena ser em sprite. Isso pode gerar um grande esforço para ajustar sempre as imagens que estejam neste formato.
Se você está atuando em um projeto existente, considere realizar a compressão das imagens com as ferramentas disponíveis.
É possível ter um aumento de conversão apenas atuando nestas frentes.
A Google disponibiliza uma ferramenta muito útil que serve de base para calcular o quanto a conversão é afetada com o tempo de carregamento no mobile. A conta é com base nos dados do Analytics e funciona com o cálculo de 3 dados:
Visitantes /mês x Ticket médio x Taxa de conversão
Faça um teste com o seu produto ou serviço e veja como a velocidade do site faz toda a diferença. É um trabalho em conjunto e os designers tem um papel importante neste processo.
Espero ter ajudado a entender um pouco mais sobre a importância deste trabalho. Se você gostou, demonstre seu amor por nós ❤
Até a próxima!
