Quando fazíamos sites com tabelas, o grande problema era a
quantidade de código que escrevíamos. Naquele tempo – 1996, 97, 98 –
tínhamos outros pontos que precisavam de uma atenção maior. A conexão
era lerda para todo mundo e isso dificultava um bocado as coisas. Por
isso, fazer um site pesado era fora de cogitação. Ficávamos
“mendigando” cada byte para que o site ficasse milésimos de segundo
mais rápido.
O código era o grande problema. A quantidade de código interferia
diretamente na performance do site. E isso fez com que os
desenvolvedores encontrassem saídas não muito agradáveis.
Era comum fazer códigos como o de baixo:
<table><br /> <tr><br /> <th>Produto</th><br /> <th>Preço</th><br /> </tr><br /> <tr><br /> <td>Tênis</td><br /> <td>R$230</td><br /> </tr><br /></table>Se transformarem em verdadeiros monstros:
<table><tr><th>Produto</th><th>Preço</th></tr><tr><td>Tênis</td><td>R$230</td></tr></table>Isso tudo para economizar alguns bytes, que dependendo do site,
significavam teras e teras de banda por mês. Naquele tempo, fazer isso
era totalmente justificável. Precisávamos de alguma forma diminuir esse
código para que o site ficasse mais rápido para o usuário e as
requisições não sobrecarregassem o servidor. Hoje isso é totalmente dispensável.
Aprendemos a utilizar o CSS e sabemos escrever HTML semântico.
A utilização dos Padrões traz uma série de vantagens, e uma grande
parte dessas vantagens é por causa da diminuição do código. Com o
desenvolvimento de camadas e, principalmente, por causa do uso do CSS,
não precisamos mais “otimizar” o código.
Mas parece que os desenvolvedores gostam de coisas complicadas. Esse
mal costume de otimização de código ainda existe, e hoje querem
otimizar o CSS. Eu acho totalmente inútil. O CSS foi feito para
controlar o visual do site inteiro. Ele tirou a responsabilidade de
formatação que colocávamos no HTML. Seu trabalho é exclusivamente esse:
controlar o visual e a diagramação do site.
É normal ele ficar grande, enorme, bizarro! Sim, haverá alguns casos
em que o tamanho vai superar mais de mil, 2 mil, 3 mil, 4mil linhas. Dá para evitar? Claro que dá! Pense simples. Module os arquivos. Faça um planejamento. Mas NUNCA faça com que um CSS escrito assim:
div {<br /> padding: 10px;<br /> border: 1px solid #CCC;<br /> width: 485px;<br /> height: 37px;<br /> background: #EEE;<br />}Fique assim:
div{padding:10px;border:1px solid #CCC;width:485px;height:37px;background:#EEE}Tenha dó do seu próximo e tenha dó de você mesmo.
Se você escreve o código de acordo com os Padrões, já economizou
código suficiente. Não prejudique a manutenção do site por conta dessa
neura. Escreva código legível!
Há outro ponto que devemos levar em consideração: imagine que o site
pese 40Kb. Estes 40Kb são compostos por 20Kb de CSS e 20Kb de HTML. O
CSS tem uma característica interessante: ele é cacheado pelo browser
quando o visitante entra no site.
Na primeira visita do usuário ele baixará 40Kb de uma vez. Já na
segunda visita ele baixará apenas 20Kb relativos ao HTML. Ele não
precisará baixar os 20Kb de CSS porque o arquivo já está cacheado pelo
browser.
Não “otimize” seu código CSS, nem seu código HTML. Faça apenas com
Padrões Web e siga categoricamente a semântica. É a melhor otimização
que você pode conseguir.
A única situação em que acho aceitável a otimização do código é em sites com porte muito grande. Apenas nessa hipótese.
Quando treinei a primeira equipe do Terra – da época do site
laranjão, lembra-se? – a primeira coisa que eles fizeram foi converter
a home, e eles ainda assim queriam colocar todo o CSS em apenas uma
linha.
Realmente 1Kb multiplicado por milhões é coisa para caramba e não há
banda que agüente. Por isso, é totalmente aceitável que sites de grandes empresas, com um
porte muito grande, “otimizem” seu código.







