Existe uma boa razão pela qual algumas aplicações ou linguagens de programação são tão usadas, e é algo que existe em comum entre o PHP, o Wordpress e o jQuery. Todos eles possuem boa documentação que torna a curva de aprendizagem mais curta.

É certo que não basta boa documentação para garantir o sucesso de uma aplicação, mas vejam quantas pessoas trabalham com o PHP, o Wordpress e o jQuery em detrimento dos seus concorrentes quando fazem todos a mesma coisa.

A diferença é que com uma simples pesquisa no site do PHP, Wordpress ou jQuery obtemos uma lista de funções ou métodos com uma explicação sobre o que cada função faz e um ou mais exemplos. Se tenho um exemplo posso começar a partir daí, efectuar alguns testes e chegar rapidamente ao resultado que pretendo. Com outras aplicações é virtualmente impossível.

Isto faz com que a curva de aprendizagem seja curta e que com o site da aplicação aberto e uma página de código se obtenham bons resultados que rapidamente podem ser aplicados num ambiente de produção com segurança.

Vejam o exemplo do Bing (antes Live) que alterou o SDK do serviço de mapas e está agora finalmente a retirar algum mercado os utilizadores do Google Maps API, como uso no Mais Gasolina.

Esta é também a razão pela qual muitos webmasters iniciados no HTML procuram tags e o que faz cada uma delas no site W3Schools e não no site do consórcio W3C.

Tornar um site rápido e leve é simples, e deve ser sempre feito e todos os sites. Já aqui partilhei várias dicas sobre como o fazer, algumas são tão simples como adicionar meia dúzia de linhas ao ficheiro .htaccess usando alguns módulos do Apache.

Usar o mod_expires do Apache é mais uma dessas dicas.

O mod_expires indica ao browser do cliente qual a validade de determinado ficheiro, permitindo mantê-lo em cache sem fazer um novo pedido ao nosso servidor. Se pensarmos que uma imagem nunca muda, e que um ícone (favicon) ou um ficheiro css e js raramente são alterados podemos reduzir vários pedidos do browser ao servidor tornando o acesso mais rápido e reduzindo o tráfego no servidor e na ligação do cliente.

O mod_expires permite indicar um tempo de cache igual para todos os documentos usando o ExpiresDefault, o que não recomendo. O ideal é usar o ExpiresByType que permite definir uma data de expiração consoante o tipo de ficheiro.

É ainda possível definir se queremos que a validade (em segundos) do ficheiro seja a contar a partir da data de acesso com o operador A ou se a validade é após a última data de modificação com o operador M.

A diferença é que com o primeiro operador, a cache de um utilizador que acedeu ao site na semana passada irá expirar primeiro que a cache de um utilizador de acabou de aceder ao site. Com o segundo operador todos os caches irão expirar ao mesmo tempo, pois será a data de criação do ficheiro que irá contar. Este operador poderá ser útil para colocar em cache imagens que mudam semanalmente mas não mudam de nome ou páginas HTML que são alteradas diariamente.

1. ExpiresActive On
2. ExpiresByType text/html M86400
3. ExpiresByType text/css A2592000
4. ExpiresByType text/javascript A2592000
5. ExpiresByType image/png A31104000
6. ExpiresByType image/jpeg A31104000
7. ExpiresByType image/x-icon A31104000

No exemplo em cima activamos o mod_expires na primeira linha e indicamos que os ficheiros html devem manter a sua validade até 24 horas depois de serem criados com o operador M. Isso quer dizer que um ficheiro criado a 1 de Dezembro às 14:00 se for acedido a 2 de Dezembro às 13:00 apenas ficará guardado durante 1 hora na cache do cliente.

No entanto o mesmo acesso irá manter os ficheiros css e js em cache até dia 1 de Janeiro às 14:00, independentemente da data de última modificação graças ao operador A.

Os ficheiros png, jpg e ico irão expirar um ano após o acesso pelo cliente, como indica o tempo em segundos. Para referência, 3600 segundos equivalem a 1 hora.

Existem várias possibilidades que podem ser adaptadas ao site em questão e melhorar o seu desempenho. Podem confirmar se o mod_expires está a funcionar correctamente com a ferramenta HTTP Headers.

Ontem escrevi sobre reduzir o tamanho dos ficheiros CSS, Javascript e HTML, mas ainda existem mais dicas que vou partilhar convosco para reduzir ainda mais o tamanho dos ficheiros CSS.

E é algo tão simples como combinar vários atributos num só utilizando os shorthands.

No post anterior já expliquei os benefícios de reduzir o tamanho de um ficheiro CSS, portanto vou directo ao assunto.

Margin e Padding
Porquê indicar o atributo margin e padding para cada um dos lados se podemos usar apenas um atributo para tudo? Fica aqui um exemplo para verificarem qual acham que é mais eficaz.

1. .class {margin-top:1px; margin-right:1px; margin-bottom:1px; margin-left:1px}

O exemplo em cima é comum em muitos sites e temas para gestores de conteúdos. Aquela linha de código ocupa 77 bytes. No seguinte exemplo usamos o shorthand, temos o mesmo efeito visual e usamos apenas 19 bytes. Aliás, bastam dois atributos de margin ou padding para compensar usar o shorthand, se for apenas um atributo não vale a pena usar o shorthand.

1. .class {margin:1px}

Parece que já vos estou a ouvir perguntar “Então e se quiser um valor diferente para cada lado?”. Vamos supor que queremos dar um padding de 10px no topo, 20px no fundo e 5px para cada lado.

1. .class {padding:10px 5px 20px 5px}

Simples, não? Os valores são indicados seguindo o movimento dos ponteiros do relógio, cima, direita, baixo, esquerda. Para aqueles que não se dão bem com ponteiros podem pensar na palavra TRouBLe e associar as consoantes aos respectivos valores. Top, Right, Bottom e Left.

Outra dica, se quisermos indicar um valor nulo não é necessário escrever 0px. Certo que em CSS temos sempre que indicar as unidades, mas 0 é 0, seja px, pt, em ou percentagem.

Border
O border também funciona tal como o margin e o padding se todos os lados tiverem a mesma dimensão. O shorthand indica primeiro as dimensões, o estilo e a cor.

1. .class {border:1px solid #000}

A diferença para o margin e o padding é que se quisermos por exemplo o border apenas no topo e no fundo temos que indicar explicitamente esses lados, como no exemplo que se segue.

1. .class {border:1px solid #000; border-left:0; border-right:0}

É verdade que neste último exemplo apenas reduzimos o tamanho do código em 3 bytes, mas cada byte conta para um site mais rápido.

Cores
Os códigos hexadecimais das cores também podem ser reduzidos para ocupar menos espaço. Aliás, já devem ter reparado que nos exemplos acima apenas usei o código #000 para indicar preto.

Vamos então ver um exemplo de um border a branco e a cor de texto laranja.

1. .class {border:1px solid #ffffff; color:#ff9900}

Podemos reduzir este código facilmente, uma vez que os valores para cada canal do RGB são iguais. Por exemplo, na cor #575757 não podemos usar um valor hexadecimal mais curto, já na cor #557700 podemos usar o código #570.

Assim o código de cima poderia ser optimizado da seguinte forma.

1. .class {border:1px solid #fff; color:#f90}

A cor vai ser exactamente igual, mas cada código hexadecimal vai usar metade do espaço.

Fontes
Indicar a fonte que um site usa ocupa bastante espaço num ficheiro CSS. Mas podemos combinar todos os elementos (ou apenas alguns) num só atributo: font. Segue o exemplo.

1. .class {font-style:italic; font-variant:small-caps; font-weight:bold; font-size:12px; line-height:14px; font-family:Verdana, Arial, Helvetica, sans-serif}

Usando o shorthand podemos reduzir o código de 155 bytes para 85 bytes.

1. .class {font:italic small-caps bold 12px/48px Verdana, Arial, Helvetica, sans-serif}

Os vários atributos devem ser indicados por ordem, como no primeiro exemplo. Começamos com font-style e seguimos para font-variant, font-weight, font-size, line-height e finalmente font-family. Reparem que, para indicar o line-height é obrigatório indicar o font-size e estes valores devem ser separados por uma barra (/) entre eles. Tal como no exemplo, 12px/48px indica um tamanho de texto de 12px e um tamanho de linha de 48px.

Não é no entanto obrigatório indicar todos os valores. Vamos supor que queremos apenas o tamanho do texto a 12px com o tipo de letra Verdana.

1. .class {font:12px Verdana, Arial, Helvetica, sans-serif}

Os restantes valores serão usados por defeito ou serão aplicados valores de classes superiores.

Background
Tal como no font, o shorthand background permite poupar bastante espaço no ficheiro CSS. Vamos observar o seguinte exemplo:

1. .class {background-color:#fff; background-image:url(imagem.png); background-repeat:no-repeat; background-position:top; background-attachment:scroll}

Usando o shorthand podemos reduzir o código de 148 bytes para apenas 61 bytes.

1. .class {background:#fff url(imagem.png) no-repeat top scroll}

Tal como nas fontes, os vários atributos devem ser indicados por ordem. Primeiro o background-color e depois background-image, background-repeat background-position e background-attachment.

Espero que estes exemplos vos possam ser úteis e que os possam aplicar nos vossos projectos para reduzir o tamanho dos ficheiros CSS. Usar os shorthands no desenvolvimento de um projecto são uma boa prática para reduzir o tamanho do código CSS e tornar o seu carregamento mais rápido.

Tenho partilhado várias dicas aqui no blog para tornar um site mais rápido. Algumas das dicas são relacionadas apenas com o Wordpress, outras podem ser aplicadas a todos os sites em geral.

Hoje partilho com vocês a “arte” de reduzir o tamanho do código CSS, Javascript e HTML. E como já foi explicado anteriormente, um site de tamanho reduzido não só é mais rápido como poupa tráfego e recursos do servidor.

Existem developers obcecados com “código bonito”, todo indentado e com comentários úteis a demarcar cada secção, algo que apenas é útil ao próprio developer ou àqueles webmasters de vão de escada que andam a copiar o código dos outros. Um utilizador comum (ou um developer com mais que fazer) não vai ligar ao código fonte, se é bonito ou feio.

Ora, eu sempre fui obcecado com código eficaz e não bonito. Se um carácter ocupa 1 byte posso começar a juntar o código todo numa só linha e a reduzir o tamanho do site. Como auto-didacta que sou comecei a fazer isto e a ver o tamanho de uma página a reduzir consideravelmente e apliquei este método na Sprint Total, pois na altura não tinha mais nenhum site.

Se acham que isto é má prática ou se acham que não resulta, então consultem o código fonte do Google, pode ser que mudem de ideias.

Existem ferramentas que fazem este trabalho por nós nos ficheiros CSS e Javascript, e assim podemos facilmente ter um ficheiro com “código bonito” para trabalhar e outro ficheiro em produção com código eficaz e reduzido.

Reduzir tamanho dos ficheiros CSS
O site CSS Drive tem uma óptima ferramenta para minimizar o código dos ficheiros CSS, é o CSS Compressor. Remove espaços, indentação, quebras de linha e comentários. No modo avançado ainda permite reduzir o tamanho dos códigos de cores, por exemplo passando #ffffff para #fff.

Eu habituei-me de tal forma a desenvolver os meus ficheiros CSS para poupar o máximo de espaço que, após correr o código no CSS Compressor passei a reduzir apenas 1% a 2% do tamanho final do ficheiro, quando tinha valores perto dos 8% a 9%. Pode-se dizer que o CSS Compressor me ajudou a desenvolver de uma forma mais eficaz.

Reduzir tamanho dos ficheiros Javascript
Existe um site dedicado apenas à compressão online de ficheiros Javascript usando o YUI Compressor desenvolvido pela Yahoo! Developer Network. O Online YUI Compressor permite utilizar o YUI online para reduzir o tamanho dos nossos scripts de uma forma segura.

Aqui podemos não só minimizar o código removendo espaços, indentação e quebras de linha como reduzir o nome de algumas variáveis que utilizamos nos scripts. No entanto aconselho a utilizar esta última função com código e a ter sempre um backup antes de aplicar o código minimizado.

Reduzir tamanho dos ficheiros HTML
Para reduzir os ficheiros HTML não conheço nenhuma aplicação, mas podem aplicar manualmente as dicas que indiquei anteriormente (é o que eu faço). Remover espaços, tabulações, usar CSS em vez de estilos no HTML e juntar tudo na mesma linha.

Com estas reduções, basta agora aplicar a compressão Gzip a estes ficheiros e certamente que ficam com um nível de optimização de código muito acima da média.

A velocidade com que um site carrega é crucial para a satisfação do utilizador. Os acessos à Internet estão cada vez mais rápidos e se temos que esperar mais do que 3 segundos para aceder, o mais provável é voltarmos atrás e escolher outro site para visitar.

Mas, se o nosso público alvo não usa o Netscape 1.0 no Windows 95, podemos usar a compressão para tornar o carregamento de um site mais rápido.

Hoje em dia todos os browsers aceitam compressão Gzip, e não é de admirar, com a compressão podemos reduzir o tamanho de um site em 70%! E o melhor de tudo é que podemos obter estes resultados com apenas algumas linhas de código, desde que o servidor HTTP seja o Apache.

Compressão de ficheiros CSS e JS
Os primeiros ficheiros a serem carregados por um browser são os CSS e JS. Estes são provavelmente os ficheiros que menos alteramos e podem ser facilmente comprimidos para Gzip com um programa como o 7-Zip e obter uma redução de tamanho considerável.

Vamos então usar o 7-Zip para comprimir um ficheiro CSS para Gzip, passamos assim a ter dois ficheiros para colocar no servidor, por exemplo um style.css e um style.css.gz.

Para que este ficheiro comprimido seja enviado caso um browser o peça devemos adicionar as seguintes linhas de código a um ficheiro .htaccess.

1. <FilesMatch .*\.js.gz$>
2. ForceType text/javascript
3. Header set Content-Encoding: gzip
4. </FilesMatch>
5. <FilesMatch .*\.css.gz$>
6. ForceType text/css
7. Header set Content-Encoding: gzip
8. </FilesMatch>
9.  
10. RewriteOptions Inherit
11. ReWriteCond %{HTTP:accept-encoding} (gzip.*)
12. ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
13. RewriteCond %{REQUEST_FILENAME}.gz -f
14. RewriteRule ^(.+) $1.gz [L]

Com este código vamos verificar se existe um ficheiro .css.gz ou .js.gz, e caso o browser peça o conteúdo comprimido o servidor envia esse ficheiro. Uma alteração simples que permite reduzir o tráfego utilizado pelo nosso servidor e pelo utilizador, resultando num site ligeiramente mais rápido. É uma situação onde ambas as partes ganham.

Compressão de ficheiros de texto
Se não tivermos um sistema de caching mas quisermos enviar as páginas dinâmicas do nosso site comprimidas podemos usar o mod_deflate do Apache. O que este módulo faz é comprimir em Gzip as nossas páginas no servidor, em tempo real, antes de as enviar para o utilizador.

Claro que isto vai consumir recursos a nível de processador e aqui já é necessário verificar se o servidor onde estamos tem capacidade para tal, principalmente se estivermos numa conta de alojamento partilhado. Pessoalmente acho que faz todo o sentido sacrificar alguns ciclos de processamento para comprimir o conteúdo e tornar o carregamento do site mais rápido.

Tal como anteriormente, para comprimir todo o conteúdo html no nosso site devemos adicionar as seguintes linhas de código a um ficheiro .htaccess.

1. <IfModule mod_deflate.c>
2. AddOutPutFilterByType DEFLATE text/html text/xml
3. </IfModule>

Isto irá comprimir todo o conteúdo em HTML e XML no site em tempo real. Não irá no entanto comprimir os ficheiros CSS e Javascript, é aconselhável usar o método anterior para poupar recursos usar o método anterior.

No entanto se quisermos comprimir também os ficheiros CSS e JS em tempo real, no caso de serem criados dinamicamente, devemos adicionar text/css text/javascript a seguir a text/xml.

Para verificar se o conteúdo está a ser enviado comprimido em Gzip podemos usar a ferramenta de Compressão HTTP.

Anda o mundo inteiro a delirar com o hype da web 2.0. Site que se preze tem que fazer requests em Ajax, de preferência desenvolvido com Ruby on Rails, nem que se trate de um simples site institucional. Para completar em beleza, tudo feito com 3 ou 4 bibliotecas de Javascript da moda para ter aqueles efeitos todos giros.

Isto a mim faz-me lembrar o Flash. Em 2004 ainda existiam empresas nacionais que, se não queriam o site totalmente em Flash, pelo menos tinham que ter uma introdução. Estas empresas, que são as mesmas de hoje em dia, apenas querem ter um site com “tecnologia de ponta” e esquecem-se do essencial, os seus clientes.

Os comerciais e gestores de projectos adoram estes termos porque é giro dizer que a empresa onde trabalham já faz sites para a “web 2.0″ mesmo que não percebam nada do que estão a dizer. Os developers também são culpados porque começam a espetar 1001 bibliotecas de Javascript sem qualquer tipo de redução de código ou compressão GZip.

No final, um site que poderia ocupar apenas 50Kb a carregar, vai ocupar 200Kb para mostrar a mesma informação esperando que o cliente use o formulário de contacto para ver os efeitos “super-avançados” que o site tem.

E é assim que a web tem andado para a frente (ou não). Tenho acedido a alguns sites que, só para aceder à primeira página, obrigam-me a descarregar 1MB de código.

A web está a ficar demasiado pesada sem necessidade, andamos a aumentar a carga nos servidores com mais pedidos de ficheiros (e cada vez maiores), e a queimar tráfego tanto no servidor como na ligação do cliente. É que não temos todos ligações de 100Mbps com tráfego ilimitado.