Imagem post: Performance do seu CSS
Artigos

Performance do seu CSS

Entenda o que pode melhorar ou piorar a performance de carregamento do seu CSS.

Por
19

Modular seu código CSS é uma boa prática para que o website carregue apenas o código necessário para montar a pagina que o visitante está. Por isso não precisamos carregar o código CSS que monta a página de contato uma vez que o usuário está na home, possibilitando um ganho de performance.
Podemos ainda melhorar um pouco mais nossa performance tendo atenção com a forma que escrevemos os seletores do CSS. Há algumas dicas que podemos seguir para que isso seja possível.

O seletor é a alma do CSS. É com ele que o browser procura e captura o elemento que você deseja formatar. Existem diversos seletores que possibilitam a captura de elementos em diversos cenários e necessidades. Com a atualizações dos browsers em relação a padronização do CSS 2.1 e do CSS 3, os desenvolvedores ganharam novos ferramentas e formas de capturar elementos.

Quero que você entenda que essas dicas são sugestões. Não seja um purista cabeça dura. Seja flexível e tolerante com alguns cenários que podem surgir durante o projeto. É bom sempre procurar o meio termo entre performance e velocidade de produção.

Outro ponto para pensar é que a má performance do CSS pode significar muito pouco perto de outros fatores como servidor, performance server-side, peso de imagens e outros fatores. Por isso é importante que você tenha em mente que fazendo as sugestões abaixo não é garantia de que seu site ficará super ultra rápido. =^)

Processo de leitura

O browser segue um processo de leitura muito fácil de ser entendido.
Todo o seletorer (se voce não sabe o que é um seletor de CSS, recomendo que leia isto e isto antes de continuar).

O sistema de leitura consiste em encontrar o elemento da extrema direita do seletor. Logo a leitura do seletor começa da direita para a esquerda. A medida que o browser lê o seletor, ele vai encontrando os elementos e só pára quando há um erro no seletor ou não encontra o elemento.

Tenha como exemplo este seletor:
[cc lang="CSS"]
ul li a {…}
[/cc]

Nesse primeiro momento, ao ler o elemento da direita, o browser seleciona TODOS os elementos A da página, independente se ele está ou não dentro de um LI.

“The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.” – David Hyatt

Não use IDs ou Classes ligados a tags

EVITE:
[cc lang="CSS"]
div.content {…}
div#geral {…}
[/cc]

RECOMENDADO:
[cc lang="CSS"]
.content {…}
#geral {…}
[/cc]

Tente especificar os elementos

Sempre que puder tente especificar os elementos com IDs ou Classes em vez de escrever seletores longos.

EVITE:
[cc lang="CSS"]
nav#menu ul li a {…}
[/cc]

RECOMENDADO:
[cc lang="CSS"]
.menuitem {…}
[/cc]

Eu não gosto muito desta sugestão porque teríamos de colocar uma classe “menuitem” em cada um dos ítens do menu. O HTML ficaria horrível. Prefiro fazer como abaixo. Não é a melhor forma (como eu cito no próximo tópico), mas é um meio termo entre performance, flexibilidade e produção de código:

[cc lang="CSS"]
#menu a {…}
[/cc]

Não misture IDs com nomes de tags e classes

EVITE:
[cc lang="CSS"]
button#botaoverde {…}
.menu#menuPrincipal {…}
[/cc]

RECOMENDADO
[cc lang="CSS"]
#botaoverde {…}
#menuPrincipal {…}
[/cc]

Não coloque nomes de tags nos nomes de classes

Muita gente relaciona o nome da tag ao nome da class ou id do CSS. Essa prática pode confundir posteriormente tanto na manutenção quanto no processo de produção por pelo menos dois motivos: 1. Você pode atribuir essa classe a elementos diferentes e não somente aquele que você relacionou no nome. 2. A classe pode fazer muito mais do que estava descrito inicialmente.
Por isso é interessante que cada nome de Classe seja ÚNICA e não seja relacionada a nenhum elemento em específico.

EVITE:
[cc lang="CSS"]
li.selected {…}
[/cc]

Bom, mas não muito:
[cc lang="CSS"]
.liselected {…}
[/cc]

RECOMENDADO:
[cc lang="CSS"]
.selected {…}
[/cc]

Evite seletores filhos

Sempre tente evitar declarar hierarquia nos seletores. Sempre que puder, coloque o nome do elemento diretamente por meio de class ou id. Mesmo assim tenha em mente a limpeza do seu HTML. Se você já aplicou boa parte dessas sugestões no resto do site, você pode abrir mão em alguns lugares que poderão ser úteis como na criação de um menu.

EVITE:
[cc lang="CSS"]
section form#cadastro fieldset label input.Text {…}
[/cc]

RECOMENDADO:
[cc lang="CSS"]
input[type="text"] {…}
[/cc]

Evite seletores descendentes

Os seletores descendentes são os seletores tem menos performance no CSS.

EVITE:
[cc lang="CSS"]
section article h1 {…}
[/cc]

É bom, mas nem tanto:
[cc lang="CSS"]
section > article > h1 {…}
[/cc]

RECOMENDADO:
[cc lang="CSS"]
.tituloh1 {…}
[/cc]

Claro que é muito complexo colocar uma classe nos títulos do site, ainda mais se os títulos são gerados por outras pessoas. Por isso prefiro, dependendo do site, dependendo do cliente, dependendo de como eu acordar de manhã, utilizar a primeira sugestão, que está marcada para EVITAR. Lembre-se ache o meio termo.

Referências:

19

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://about.me/diegoeis/

Mais posts do autor

  • Igor Escobar

    Muito bom o post, Diego! Nada como combater a tecnica com o argumento.

  • Ariê Perini

    Diego,

    Sempre gosto muito das suas matérias, mas honestamente nesta você não foi feliz, essa teoria não se aplica para uma boa organização sendo que em elementos como o menu principal do site você consegue achar facil mas o restante do site ficaria muito ruim de achar fora a confusão no css.

    E o ganho em performace é mínimo.

    Concordo com alguns pontos que a galera exagera como

    section form#cadastro fieldset label input.Text {…}

    por

    input[type="text"] {…}

    Mas vale a polêmica do assunto.

  • http://www.nerdhead.com.br/ Rafael Cirolini

    Concordo 100% com a questão dos seletores e uso dos ID e Classes, e com certeza depois deste artigo vou me policiar mais. Mas quanto a modularização do css, vc não acha que dependendo do tamanho do codigo, se for pequeno, pode ter perda de performance por causa do aumento de GETs na pagina?

    []‘s

  • http://www.twitter.com/rhamses Rhamses Soares

    Muito interessante esse artigo Diego!

    Estava justamente pesquisando metodos de otimização quando ví o link na minha timeline.

    Eu acho que tudo depende do tamanho da página e da estrutura do seu arquivo CSS.

    Estou lidando com um caso desse atualmente. Tenho que otimizar uma página, aonde o HTML não pode ser alterado, então a primeira coisa que veio na minha cabeça é otimizar os estilos da mesma, isolando-os o máximo possível e agora distribuindo um pouco mais de classes e IDs ao invés de construir seletores filhos/adjascentes complexos pela folha.

    Vamos ver o resultado. Espero que ajude um pouco que seja.

  • http://twitter.com/rafelcavalcante rafael cavalcante

    Muito bom. Tudo bem que existem casos e casos, eu costumo utilizar uma classe .alternativo em diferentes coisas, então às vezes tenho que colocar o seletor como tag+classe/ID.

    Ótimo post ;-)

  • http://paulok.me Paulo

    Por favor, publique também o comparativo comprovando a diferença significativa de desempenho atingida com a modificação apresentada no post.
    Seria importante para fundamentarmos as afirmações com uma demonstração quantitativa.

  • http://www.klebersantos.net Kleber Santos

    Se é só por isso, então não vou deixar de usar o li.nome :)

    Por enquanto.

  • http://www.renie.com.br Renie

    Pequenos detalhes fazem a diferença…

  • Gui Premonsa

    Otimizar o CSS é essencial no desenvolvimento de Mobile – economiza a bateria do aparelho, poupa banda (onde as vezes cada bit faz diferença).

    Pra sites desktop, fica mais organizado.

  • http://luizz.com.br Luizz

    Valeu a informação Diego.
    Vivendo e aprendendo.

  • http://www.igorikeda.com Igor Ikeda

    Costumo sempre observar a maneira que alguns projetos são feitos. Via o pessoal utilizando seletores descendentes e ficava me perguntando se realmente aquilo era necessário sendo que poderia ser resolvido com uma simples class.

    Com esse post fico até mais tranquilo que outras pessoas que tb tem essa opinião.

    Enfim… ótimo post.

    abs

  • http://www.twitter.com/pedromagalhaes Pedro Magalhães

    Excelentes dicas! Utilizo todas nos meus projectos.
    Só deixo uma nota sobre o exemplo input[type="text"] {...}:
    o selector só deve ser utilizado com propriedades genéricas nos campos de texto dos formulários. Caso contrário precisa mesmo de especificar qual o formulário onde se aplica este estilo. Continuem! ;)

  • http://www.ortense.com.br Marcus Ortense

    Muito bom o artigo, a parte que achei mais interessante é sobre os seletores longos. . .
    Para evitar a criação de muitas classes e ids costumo usar varios seletores longos, depois vou fazer uns testes pra ver como fica . . .

    []‘s

  • http://barraponto.blog.br Capi Etheriel

    Uma coisa que me preocupa nesse encurtamento dos seletores é o escopo. Quando estamos lidando com sites maiores ou cms, é comum a mesma classe aparecer em elementos distintos de mesmo signficado (lembre-se, classes são html e portanto devem ter sentido semântico).

    Um exemplo é o menu. A classe menu quase sempre está associada a um ul, e menu-item a um li. Mas eu posso ter mais de um menu no meu site, cada um com um estilo diferente. Escrever um seletor .menu-item sem colocar a hierarquia devida (#primary .menu-item) significa que meu seletor não tem escopo: vai se aplicar ao menu que eu estou trabalhando (e estou atento) mas também aos menus que eu não estava pensando em atingir (e por isso posso modificá-los sem perceber).

    Escopo é importante. O aninhamento que pre-compiladores como SASS e LessCss permitem crescem o tamanho do seu seletor, mas não o suficiente pra ser uma encrenca. Eu sempre recomendo pros meus alunos e estagiários que fiquem atentos ao escopo de um seletor.

  • Felipe

    Ótimo post para gerar novas idéias e pensamentos, abaixo está a minha:

    Existem várias ferramentas que comprimem e geram um css mais leve assim como os js (bibliotecas) portanto prefiro manter a organização utilizando todo o poder da hierarquia das cascatas. Em vez de otimizarmos os css dos sites poderia apenas mudar os bgs e otimizar ao máximo as imagens e flash, com certeza o ganho real será melhor.

    Abraços Diego.

  • http://www.vintedois.com.br Shankar Cabus

    Concordo com Ariê e Paulo e faço mais algumas observações.

    Quando se fala em melhora de desempenho, a primeira coisa a fazer é provar o feito (resultados!).
    Quantos milissegundos um browser demora para ler uma folha de estilo? Essa “otimização” é relevante? Vale apena desorganizar a página pra ganhar x ms? Essas perguntas ficaram sem resposta.

    Outro ponto importante é a organização. O CSS ainda é uma linguagem carente de padronizações (oficiais) e totalmente “promíscuo”, pois aceita quase tudo sem reclamar. Então, em grandes projetos, utilizar seletores com apenas um nível, deixaria o código incompreensível até para quem o criou.

    Se, para suprir a desorganização gerada por essa pseudo otmização, for sugerido utilizar comentários, troca-se seis por meia dúzia. Pois comentário também é caracter, logo, aumenta o tamanho do arquivo, além do compilador perder alguns milissegundos passando para o próximo token (o que vier depois do comentário).

    Em alguns pontos concordo, não há menor necessidade de se utilizar #id junto com class ou tag (ex. li#menu ou #menu.item), pois #id já é único, ele só já seria suficiente para selecionar o elemento.

    Por isso, utilizo um padrão próprio, onde cada seletor só pode ter no maximo 3 níveis (salve, claro, raras exceções) e são organizados da seguintes forma:

    #parceiros *{line-height: 1.5em;}
    #parceiros .itensContent{margin-top: 30px;}
    #parceiros h2{margin-top: 5px;}
    #parceiros h2 a{font-size: 16px; line-height: 1em; }
    #parceiros .defaultText *{font-size: 12px; color: #888;}

    Bem Diego, acho que ninguém sabe tudo e saber ouvir crítica é o primeiro passo para buscar a “perfeição”. Dá uma lida nos comentários do post que você escreveu e responde aos seus leitores, isso mostraria humildade.

    A propósito, usabilidade também é importante, bota esse form abaixo dos comentários, pois, depois de lê-los, ter que subir tudo pra comentar é muito chato. #ficadica

    Abraço

  • http://tutsmais.com.br/blog/ Ofelquis

    Eu sempre prefiro deixar meu html o mais limpo o possível por isso em vez de
    #menuTopo
    eu prefiro sempre
    #header ul

    em vez de #itemMenu

    prefiro #header ul li a{

    isso só para que o html não fique cheio de class e ids

    mas já que o artigo esta falando sobre a performance do css isso não vem ao caso.
    performance é performance.

  • Pingback: OOCSS ou CSS do jeito certo | SWX Softwares - Desenvolvimento e Design Web

  • Pingback: OOCSS - CSS orientado a objeto

Mais artigos