Conhecendo o novo Painel de Auditorias (Audits Panel) do Chrome 60

Entre as principais novidades lançadas com o Chrome em sua versão 60 está o novo Painel de Auditorias, que chega com testes para:

  • progressive web apps
  • performance
  • accessibility
  • best practices

Vamos direto ao ponto, entender para que serve cada um dos 4 testes listados acima!

Ah, a trilha sonora pra ler isso aqui será clássicos do rock irlandês, e claro, não tô nem aí se você não curte 😹

PWA

Progressive Web Apps aproveitam o melhor da web e dos apps offline. O teste de Progressive Web Apps ou simplesmente PWA verifica se uma página segue os padrões de uma aplicação PWA, que diz respeito a experiencia do usuário numa aplicação web desse tipo, os pontos a serem observadores serão:

  • Confiabilidade – A aplicação terá que carregar rápido e nunca mostrar o “dinosaurinho do mau” (downasaur) mesmo em codições não previstas na rede.
  • Velocidade – Para atender este quesito, o app deve ser carregado rápido, as interações do usuário com a interface respondidadas rapidamente e as animações devem ser suaves (sem lag). 😻
  • Envolvimento – Diz respeito a como o usuário interage de forna natural com o app, ou seja a experiencia do usuário em relação a interface é a questão-chave aqui.

Vale ressaltar que geralmente sites não são pensados para funcionar como aplicativos, porém como vimos acima, desenvolve-los pensando em atender as especificações do teste de PWA só trará vantagens ao produto final, principalente no que diz respeito a experiencia do usário.

Performance

O “X da questão” aqui é desempenho, e esse deve ser melhorado observando-se os seguintes pontos:

  • Eficiência do conteúdo – Isso se alcaça otimizando ou reduzindo os dados (quantidade de bytes) que usuários baixam ao acessar a aplicação web. É verdade que o número de usuários com banda larga está aumentando, mas com velocidades diferentes em realidades diferentes, lembre-se a banda larga no Brasil é bem “menos larga” que do EUA por exemplo, além disso alguns usuários estão sujeitos a limites de dados e planos limitados em dispositivos móveis e em breve talvez até na banda larga fixa, isso deixa uma mensagem bem clara para nós, economizar dados é necessário.
  • Desempenho da renderização – A ideia aqui é você saber como o HTML, JavaScript e CSS são tratados pelo navegador e se certificar que o código criado (incluindo código de terceiros) funciona de forma eficiente. Se quiser saber mais sobre isso veja esses artigos: Caminho crítico de renderização, Desempenho da renderização.
  • Largura de banda e latência – Como sua aplicação se comporta quando a conexão do cliente é de baixa velocidade ou com alta latência até sua aplicação? É importante estar atento a estes pontos, e há algumas ferramentos como o Chrome DevTools ou mesmo os conhecidos Ping e Traceroute que podem te ajudar nisso. Aliás você sabe o que é latência? Se quiser saber mais aqui está um artigo meu com dicas valiosas sobre redes para programdores web.
  • Padrão PRPL – PRPL (sigla para push, render, pre-cache e lazy-load) é um padrão de estruturação e fornecimento de PWAs, com foco no desempenho de fornecimento do aplicativo. Mais sobre PRPL aqui.
Acessibilidade

O que é acessibilidade? Primeiramente não confunda acessibilidade com responsividade, são coisas diferentes. De forma geral um app ou site acessível tem seu conteúdo disponível para qualquer pessoa, enquando um responsivo está pronto para qualquer dispositivo. Hoje muitos programadores se preocupam com a parte do “qualquer dispositivo” e deixam de lado o “qualquer pessoa”.

Quando digo atender qualquer pessoa não estou me refindo apenas a pessoas com alguma deficiencia mas também a usuários atípicos, aqueles que podem interagir com sua aplicação de maneira inesperada (seu avô talvez?). Certo, nós vamos falar um pouco sobre pessoas.

Para começar pense em pessoas cegas ou com baixa visão, seu app / site não precisam ser desenvolvido especialmente para eles, mas se por exemplo você faz um site com fundo preto e letras verde escuro, algo difícil de ler para quem tem visão perfeita, imagina para um deficiente visual? Colocar contraste adequado entre cores e meta tags para os leitores de tela é um excelente começo.

Victor Tsaran é Gerente de Programa Técnico do Google, e totalmente cego, ele classificou deficientes em quatro grandes categorias: visual, motora, auditiva e cognitiva. Os exemplos abaixo em preto foram descritos por ele, e os em azul acrescentados por mim.

Situacional Temporária Permanente
Visual iluminação inadequada concussão cegueira
Motora segurando um bebê braço quebrado, LER* LER*
Auditiva escritório barulhento surdez
Cognitiva concussão parkinson, alzheimer

*Lesões por Esforços Repetitivos

Como podemos ver na tabela acima há situações que geralmente não prevemos quando desenvolvemos uma aplicação web, mas que agora que você as conhece não devem mais ser ignoradas. Aqui um link se você quiser saber mais sobre o assunto.

Melhores Práticas

O teste de Melhores Praticas como o nome já diz irá verificar se uma página segue foi desenvolvida segundos as práticas mais modernas, ou pelo menos se não foram utilizadas práticas obsoletas. Alguns dos pontos que mais me chamaram a atenção são:

Se quiser descobrir quais boas e más práticas estão praticando em sua aplicação rode o Audits Panel!

Teste você mesmo o Novo Audits Panel!

Claro para isso você precisa do Chrome 60, para verificar a versão do sua Chrome digite o seguinte na barra de endereços: Chrome://version

Se você tem uma versão a partir da 60, no Windows precione as teclas Ctrl + Shift + I ou F12, no Mac use Cmd + Opt + I, se abrirá as Develper Tools, navegue até a aba Audits, lá você encontrará Audits Panel. Clique em Perform an autid… e boa diversão! 😼

Gostou do artigo? Discorda ou tem algo a acrescentar? Deixe seu comentário aí! 😺