Na maioria dos websites o que mais salta à vista é a fonte utilizada para o seu conteúdo. Uma boa fonte pode ser a diferença entre cativar um leitor ou perder uma visita porque torna o nosso conteúdo desinteressante.

Mas será que utilizamos as nossas fontes correctamente?

Existe um conjunto de fontes ou tipos de letra que são considerados seguros para utilizar na Web. Fontes como o Verdana, Tahoma e Arial podem ser usados com confiança pelos developers.

No entanto vamos desenvolver o nosso website e vamos usar aquela fonte bem gira que temos no nosso PC mas quando visualizamos o site noutro computador nada aparece de forma correcta. Temos duas opções, ou embebemos a fonte ou fornecemos uma alternativa.

Fontes embebidas – @font-face

Com o CSS3 finalmente vai passar a ser possível embeber fontes de uma forma funcional a todos os browsers. O Internet Explorer 5 já permitia isto, mas com código especifico da Microsoft como é hábito.

Desde que a fonte permita ser embebida podemos usar a mesma no nosso site. Um bom local para obter este tipo de fontes é o Google Web Fonts.

Esta é uma forma de garantir que o nosso design em termos tipográficos é semelhante em todas as máquinas, tenham o tipo de letra ou não. O problema é que em certas fontes isto implica descarregar até 200KB de informação e isto não faz sentido para um site generalista, talvez para um portfolio ou mesmo um blog pessoal como este.

Fontes alternativas – CSS Font Stacks

Um font stack é uma lista de fontes que são utilizadas caso o computador de quem nos visita não tenha a fonte inicial que definimos. Um exemplo definido pelo Dreamweaver:

1. div { font-family: Verdana, Geneva, sans-serif }

Se o utilizador não tiver a fonte Verdana instalada irá visualizar o site com a fonte Geneva. Se também não tiver esta fonte o conteúdo é apresentado pela fonte padrão do sistema operativo do tipo sans-serif.

Mas para definirmos fontes alternativas temos que saber que outro tipo de fontes semelhantes existem. O site Typetester é uma óptima ferramenta para esta função, colocando 3 blocos de texto lado a lado permitindo assim escolher várias fontes e comparar o tamanho e aspecto ocupado por cada uma.

Já sabemos as fontes semelhantes, mas será que elas estão disponíveis em todos os sistemas? Mais de 92% dos utilizadores na web usam Windows, o que facilita o trabalho, mas não nos podemos esquecer dos restantes 8%. E é necessário ter em conta que diferentes sites têm diferentes públicos e um site dedicado a Mac ou Linux certamente terá mais visitas destes sistemas operativos.

E aqui entra outra ferramenta, ou melhor um conjunto delas fornecido pelo site Code Style. Aqui podem submeter as fontes que têm instaladas para estatística, visualizar a disponibilidade das fontes em vários sistemas operativos e até criar font stacks com a indicação da percentagem de utilizadores com aquela fonte disponível.

Com estas duas ferramentas podemos por exemplo criar a alternativa ao código anterior fornecido pelo Dreamweaver com o seguinte:

1. div { font-family: Verdana, Geneva, "Lucida Sans", "DejaVu Sans", sans-serif }

O Verdana será visualizado por 99% dos utilizadores com Windows e Mac e por 70% dos utilizadores com Linux. O Geneva será visualizado por uma minoria com Mac e as fontes Lucida Sans e DejaVu Sans serão utilizadas pelos restantes 30% dos utilizadores em Linux.

Fontes e dispositivos móveis

Para dispositivos móveis a história é outra. No caso do Android navega-se com Droid Sans e mesmo o Opera Mini limita o tipo de fontes utilizado. Aqui as fontes são optimizadas para pequenos ecrãs e embora o resultado a nível estético não seja o melhor o texto fica legível de uma forma agradável.

O HTML5 e o CSS3 são a next big thing da Internet e os developers espumam-se da boca com certos efeitos que podem ser produzidos com código que estavam reservados a imagens ou Javascript complexo.

As novidades do CSS3 são fantásticas, mas é necessária alguma precaução.

Tenho andado a fazer várias experiências com HTML5 e CSS3 e já desenvolvi alguns projectos a utilizar estas novas especificações, embora ainda não sejam suportadas a 100%. No entanto são casos muito específicos onde a utilização é feita com browsers que suportam estas funcionalidades.

Com toda esta experiência que obtive verifiquei que alguns browsers fazem transições lentas ou arrastam-se quando fazemos scroll na página. Isto é especialmente notado quando usamos as propriedades box-shadow e border-radius em conjunto, especialmente no Safari.

E em computadores mais fracos em termos de processamento até o Opera e o Chrome se engasgam.

Eu sou a favor que se use o CSS3 com toda a força, mas sempre com progressive enhancement em mente. Devemos criar uma boa experiência em todos os browsers (esqueçam o IE6 e 7) e garantir uma experiência superior ou um carregamento mais rápido com recurso a CSS3 caso o browser o suporte. Existem vários artigos interessantes na Net sobre como o fazer.

Verifiquem no entanto, dependendo do público alvo de um website, se o processamento de um efeito em CSS3 não se torna mais penoso em termos de processamento do que o carregamento de uma imagem para fazer um background e tenham em mente que uma poupança de 900 bytes é negativa se tivermos um site que é lento a fazer efeitos de fade e se o scroll faz com que o browser se arraste.

Para o utilizador final a culpa é do developer por ter criado um site lento, e não do utilizador por ter um computador lento. E eles até têm muita razão

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. Header set Vary: Accept-Encoding
5. </FilesMatch>
6. <FilesMatch .*\.css.gz$>
7. ForceType text/css
8. Header set Content-Encoding: gzip
9. Header set Vary: Accept-Encoding
10. </FilesMatch>
11.  
12. RewriteOptions Inherit
13. ReWriteCond %{HTTP:accept-encoding} (gzip.*)
14. ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
15. RewriteCond %{REQUEST_FILENAME}.gz -f
16. 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.