O modo de projetar o CSS, bem como técnicas podem salvar o matar a performance do seu widget. Esse artigo tem como principal propósito apresesentar princípios e técnicas para o ganho de performance no widget.

Os aparelho tem processamento e memória limitadas, o que demanda do desenvolvedor uma atenção especial em como ele projeta o HTML e CSS, além do JavaScript. É necessário que a estrutura seja a mais enxuta possível para que não haja estouros de memória, falta de processamento e até gasto excessívo de bateria.

O grande herói: CSS Orientado a Objeto

Não é uma versão nova do CSS; não é um recurso proprietário do WRT; não é um framework. É um modo mais eficiente de projetar o CSS que foca o uso eficiente dos seletores.

Esse coiceito foi apresentado por Nicole Sullivan (@stubbornella), especialista em performance de front-end, durante o Web Directions South 2009. De lá para cá ela amadureceu o conceito e desenvolveu um framework para exemplificar os princípios tratados. A apresentação dela é clara o sufuciente para dispensar explicações:

View more presentations from Nicole Sullivan.

Seguir estes princípios evita que ocorram uma série de problemas de performance decorrentes da falta de eficiência do aparelho em processar a estrutura HTML e CSS utilizadas. Dos pontos tratados por Sullivan, vale resaltar:

  • Defina valores padrões: as interfaces para dispositivos móveis tem um número reduzido de componentes quando comparado com websites. Não é difícil ter componentes que mantenham o mesmo visual e até o mesmo tamanho em todaas as views, como é o caso de títulos (cabeçalhos) e grids.
  • Defina estruturas de layout em classes separadas: as interface para dispositivos móveis tem etruturas simplificadas, que podem ser controladas e estruturadas facilmente numa classe a parte.
  • Evite estilos depentendes de localização: manter estilos “mutantes”, que são readequados para cada view cria um código sujo e nada reaproveitável. Usar componentes com valores padrões permite que seu comportamento seja previsível em qualquer módulo.
  • Usar grids para controlar larguras, deixar que o conteúdo defina as alturas: a largura estreita dos dispositivos móveis faz com que textos tenham quebras de linhas onde não prevemos. Definir alturas fixas é criar possibilidades de bugs visuais no futuro, com textos sobrepondo a borda inferior ou “puxando” o elemento para cima de outro.

É comum estruturar o CSS orientado aos módulos (ou views) do aplicativo, fazendo um por vez sequencialmente. Isso pode gerar códigos parecidos com esse:

#login h2 { margin-top: 10px; color: blue; }
#dashboard h2 { margin-top: 10px; color: green; }
#help h2 { margin-top: 10px; color: yellow }

Definir os mesmos elementos (h2) com diferentes formatações dificulta o reuso e cria a necessidade de aumentar o código do CSS (e possivelmente a bagunça). Seguindo as orientações de Sullivan, a melhor abordagem nesse caso seria:

  • Atribuir classes aos elementos <h2> para se trabalhar com as formatações diferentes;
  • Preservar as atribuições diretas para definição de padrões;
  • Manter o código html consistente ao visual, semântico. Se os títulos são de níveis hierárquicos diferentes, procure usar outras tags de título.

Otimizando o código seria:

h2, .h2 { margin-top: 10px; }
#login .h2 { color: blue; }
#dashboard .h2 { color: green; }
#help .h2 { color: yellow; }

Os (outros) heróis de performance

As limitações do dispositivo móvel tornam as técnicas de otimização de performance de interfaces elementos essenciais para que o widget atinjam uma boa qualidade de uso.

Imagens em sprites
Problema: por embarcar a grande maioria dos elemento de interface no aparelho, não há necessidade de se preocupar com o número de requisições http utilizadas com imagens. Contudo o carregamento de diversos arquivos na memória compromete a performance do widget.
Solução: Agrupar as imagens que compões a interface em sprites. Veja artigo no Smashing Magazine de como aplicar esta técnica. Essa técnica é amplamente utilizada hoje, incluindo Amazon.com, Apple.com e Facebook.

Gradientes simulados
Problema: Quando há a necessidade de várias aplicações de fundos em gradiente, o uso de sprites não resolve a queda de performance.
Solução: Usar a técnica de gradiente simulado desenvolvido por Douglas Bowman (@stop) para os botões das interfaces dos aplicativos Google.

Os assassinos de performace

As limitações do dispositivo móvel tornam sofrível o uso de algumas técnicas CSS, principalmente quando há rolagem de tela:

Imagens de fundo em repetição
Problema: A renderização da repetição de imagens de fundo exige grande esforço de processamento e quando acontece uma rolagem é necessário renderizar novamente todas as repetições de fundo existentes naquele módulo. A performance da rolagem de tela fica péssima.
Solução: Usar imagens de fundo sem repetição. A largura máxima do aparelho chega a 640px nos aparelhos touch e 320px nos aparelhos keypad. Como não há requisições http, basta pré-carregar imagens no início do widget que a performance não será prejudicada.

Multiplos posicionamentos: fixed, absolute, relative
Problema: a performance da rolagem de tela quando há elementos encadeados com posicionamentos fixed dentro de absolute ou elementos em absolute que passem num nível infeior à outro fixed. A renderização da rolagem de tela com esses elementos fica comprometida.
Solução: manter esses métodos de posionamento somente quando não houver outra abordagem (como o fixed para barras de títulos e ferramentas). Quando for para compor layout é possível trabalhar com as propriedades display (block, inline-block, inline) e float. Essas propriedades tem renderização mais rápida que as propriedades de posicionamento.

Seletores de atributos
Problema: apesar da grande versatilidade, os seletores de atributos – seletor[atributo=x] e similares – pesam na renderização e prejudicam a performance de exibição inicial da tela e na rolagem de tela.
Solução: um planejamento mais minucioso dos componentes e comportamentos dos elementos pode eliminar ou contornar a necessiadade dos seletores de atributo.

Quer mais?