A visualizar apenas posts com a tag javascript

Tenho partilhado várias dicas aqui no blog sobre como tornar um site mais rápido. Algumas incluem a compressão de ficheiros quer através de redução como de compressão gzip.

Mas nem todos os compressores fazem um bom trabalho, e o conhecido /packer/ é um deles.

Carruagem de metro cheia

O /packer/ anuncia maravilhas, afinal de contas com um algoritmo complexo que consegue codificar o código JavaScript com Base62, reduzir o nome das variáveis e consegue resultados em tamanho de ficheiro muito parecidos ao de um ficheiro Gzip.

O problema é que um ficheiro Gzip é descarregado uma vez, descomprimido uma vez e fica em cache no browser. O utilizador poupa largura de banda e deixa de fazer pedidos ao servidor.

“Mas Eduardo, com um ficheiro .js do /packer/ acontece o mesmo”, devem pensar vocês. Certo, o ficheiro fica em cache mas comprimido com o algoritmo usado, e cada vez que se acede a uma página com este JavaScript existe um trabalho desnecessário de descodificação do ficheiro e posterior colocação dos dados em memória no browser.

Se em computadores com boa capacidade de processamento isto equivale a alguns milissegundos, num computador mais fraco como um Netbook ou num telemóvel estamos a falar de o uso de recursos para processamento e memória que se poderiam evitar.

Para mim o /packer/ é uma alternativa para os preguiçosos. O meu conselho é não usar o seu Base62 encode e optar antes pela compressão dos ficheiros no servidor.

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.

Interior de um relógio

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.

Este artigo foi criado em Outubro de 2009 e encontra-se desactualizado.
Clique aqui para ler uma versão actualizada do mesmo.

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.

Tunel

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<FilesMatch .*\.js.gz$>
  ForceType text/javascript
  Header set Content-Encoding: gzip
  Header set Vary: Accept-Encoding
</FilesMatch>
<FilesMatch .*\.css.gz$>
  ForceType text/css
Header set Content-Encoding: gzip
Header set Vary: Accept-Encoding
</FilesMatch>

RewriteOptions Inherit
ReWriteCond %{HTTP:accept-encoding} (gzip.*)
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
RewriteCond %{REQUEST_FILENAME}.gz -f
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
2
3
<IfModule mod_deflate.c>
  AddOutPutFilterByType DEFLATE text/html text/xml
</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.

Bibliotecas de Javascript

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.

 
Copyright © 1985 - 2017 Eduardo Maio. Alguns direitos reservados.
eduardomaio.net - Às vezes mais valia ser Agricultor do que Programador
Ao navegar no blog eduardomaio.net está a concordar com os termos legais e de privacidade.