A visualizar apenas posts colocados no ano de 2017

Está na hora de actualizar um dos artigos mais lidos do blog sobre compressão, com novas ferramentas que se encontram agora disponíveis.

Quer tornar o seu site ainda mais rápido em Desktop e Mobile e melhorar o resultado do PageSpeed? Vamos a isso!

Funcionário empurra pessoas no comboio em Tóquio

Este artigo não se aplica a todos os developers, e o ideal será ter um pré-processador como o Gulp para automatizar estes processos de forma a aumentar a sua produtividade.

Irei basear-me na configuração de um servidor com Apache (CPanel) e no pré-processador Gulp.

Conteúdo estático CSS e JS

A maioria dos tutoriais na net vão indicar que se deve fazer a compressão destes ficheiros em tempo real pelo servidor. Essa é a forma mais fácil de o fazer mas trás várias desvantagens: aumento de carga, consumo de memória e tempo de compressão que pode ser contraproducente e demorar mais do que servir o elemento sem compressão, dependendo do servidor e tipo de compressão.

Com a utilização de pré-processadores para minificar CSS e JS, passar SASS para CSS e afins podemos adicionar mais 1 ou 2 passos e ter a melhor compressão possível sem carga alguma no servidor.

Vamos usar Gzip com o algoritmo Zopfli, desenvolvido pela Google, e um novo formato Brotli também desenvolvido pela Google especificamente para a web.

O primeiro passo é configurar o nosso servidor para enviar a codificação certa com a extensão com compressão e adicionar alguns headers para compatibilidade com proxys.

Este código pode ser adicionado a um ficheiro .htaccess ou semelhante, ou adicionado a nível geral no servidor. No caso de um servidor CPanel pode ser adicionado ao ficheiro post_virtualhost_global.conf em Apache Configuration > Include Editor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Ficheiros com compressão Brotli
<Files *.js.br>
    AddType "text/javascript" .br
    AddEncoding br .br
</Files>
<Files *.css.br>
    AddType "text/css" .br
    AddEncoding br .br
</Files>

# Ficheiros com compressão Gzip
<Files *.js.gz>
    AddType "text/javascript" .gz
    AddEncoding gzip .gz
</Files>
<Files *.css.gz>
    AddType "text/css" .gz
    AddEncoding gzip .gz
</Files>

# Headers para proxys
<Files *.br>
	Header set Content-Encoding: br
	Header set Vary: Accept-Encoding
</Files>
<Files *.gz>
	Header set Content-Encoding: gzip
	Header set Vary: Accept-Encoding
</Files>

Depois associado a cada domínio / vhost também num ficheiro .htaccess ou semelhante adicionamos uma regra para devolver o ficheiro em Brotli ou Gzip conforme o que for suportado pelo browser do utilizador.

1
2
3
4
5
6
7
8
9
10
11
12
# Necessário caso ainda não tenha sido iniciado anteriormente
RewriteEngine On

# Fornece ficheiro pré-comprimido em Brotli
RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{REQUEST_FILENAME}.br -f
RewriteRule ^(.*)$ $1.br [L]

# Fornece ficheiro pré-comprimido em Gzip
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [L]

A configuração está feita, e agora como gerar os ficheiros? No artigo antigo sugeri usar o 7-Zip para criar os Gzip, mas agora existem ferramentas melhores. Se não usam um pré-processador podem usar o 7-Zip, assim como usar esta ferramenta para a compressão em Brotli, mas vão ter mais trabalho

Gerar ficheiros estáticos através do Gulp

Como uso Gulp para várias tarefas como passar SASS para CSS, minify e cache busting de CSS, JS e SVG faz todo o sentido adicionar estas tarefas de compressão ao meu processo que corro antes de enviar os ficheiros para produção.

Com a integração com o PHPStorm com dois cliques em menos de 500ms tenho tudo pronto a enviar, ficheiros Gzip e Brotli incluídos.

Se não usam um pré-processador como o Gulp não sabem o que estão a perder.

Vamos precisar de dois módulos: gulp-zopfli e gulp-brotli. Podem ser facilmente instalados com estes dois comandos:

1
2
npm install gulp-zopfli --save-dev
npm install gulp-brotli --save-dev

Adiciona-se os require ao gulpfile.js

1
2
var zopfli = require('gulp-zopfli');
var brotli = require('gulp-brotli');

De seguida criamos duas novas tarefas, uma para a compressão Gzip com o algoritmo Zopfli e outra para Brotli. Para simplificar apenas adicionei como exemplo ficheiros CSS e JS mas pode ser aplicado a outras extensões como SVG. O mesmo para o caminho, estão aqui hardcoded para ser mais fácil a sua compreensão.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Compressão Gzip
gulp.task('zopfli', function(){
    return gulp.src('dist/*.{js,css}')
        .pipe(zopfli({ format: 'gzip' }))
        .pipe(gulp.dest('dist/'));
});

// Compressão Brotli
gulp.task('brotli', function(){
    return gulp.src('dist/*.{js,css}')
        .pipe(brotli.compress({
            extension: 'br',
            quality: 11
        }))
        .pipe(gulp.dest('dist/'));
});

E agora é uma simples questão de adicionar estas novas tarefas à tarefa existente que corro antes de enviar ficheiros estáticos para o servidor em produção.

1
2
3
4
5
gulp.task('build', gulp.series(
    'clean',
    gulp.parallel('styles', 'scripts'),
    gulp.parallel('zopfli', 'brotli')
));

Já usava o método antigo, vale a pena mudar?

O método antigo já é uma boa optimização. A compressão em Gzip com o 7-Zip já permitiam reduções superiores a 60% e se a diferença entre 7-Zip e Gzip com Zopfli é de apenas 1%, com Brotli temos uma diferença de 6%.

Aqui fica uma tabela com os resultados de um teste que efectuei num ficheiro Javascript.

MinifyGzip (7-Zip)Gzip (Zopfli)Brotli
Tamanho5,99 KB2,37 KB2,33 KB1,94 KB

Vale a pena mudar se for usado um pré-processador, ai apenas se gastam 30 minutos a adicionar estas configurações ao servidor e a adicionar duas novas tarefas ao processo já existente. No caso do Brotli as diferenças fazem especial sentido em mobile e já existe suporte em Android e browsers como o Chrome e Firefox. Até o Edge em Desktop suporta!

Conteúdo dinâmico

Usar Zopfli e Brotli em conteúdo dinâmico não faz sentido. O ponto forte destes novos algoritmos é que apesar de demorarem mais tempo no processo de compressão têm tempos de descompressão muito semelhantes ao Gzip normal. E é por isso que apenas devem ser usados em ficheiros estáticos, pré-comprimidos antes de os enviar para o servidor.

No caso de conteúdo dinâmico (páginas vindas de PHP, chamadas AJAX, etc) devemos continuar a usar o mod_deflate do Apache.

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

Também pode ser adicionado conteúdo estático ao mod_deflate para simplificar as coisas em ambientes onde não existem pré-processadores ou que existem ficheiros CSS e JS gerados dinamicamente através de um CMS por exemplo.

Como testar se funcionou?

A ferramenta de Compressão HTTP foi actualizada para verificar não só a compressão com Gzip e Deflate mas também Brotli. Basta colocar o endereço do ficheiro CSS, JS ou outro e confirmar se a compressão funciona em Gzip e Brotli.

No meu último artigo falei sobre os resultados de performance com e sem Memcached. Algumas das perguntas foram sobre que tipo de servidor tinha e em que empresa estava alojado.

Datacenter genérico

Estou actualmente com a RamNode e tenho um VPS KVM com discos SSD.

Quando escrevi o artigo anterior tinha a VPS com apenas 2GB de Ram, entretanto reduziram os preços e decidi aumentar para 3GB de Ram e ter mais espaço em disco. A máquina encontra-se na Holanda e as latências são baixas, ao nível de um outro servidor que tinha em Inglaterra.

Já estou com esta empresa desde Dezembro de 2015 e não me posso queixar, o uptime é fantástico e a performance dos servidores é muito boa para o valor praticado.

Portanto se ficaram curiosos com a performance reportada no último artigo e se procuram um servidor rápido com discos SSD, possibilidade de ter licença do CPanel mais barata e sem gastar rios de dinheiro já sabem, é na RamNode.

Devemos sempre fazer os nossos testes de performance quando testamos algo. Nem sempre o que se diz nos fóruns e em sites da especialidade se converte em melhorias caso dos nossos sites em especifico.

E no meu caso cheguei a essa conclusão ao efectuar alguns testes com o Memcached.

Disco SSD da Samsung

Quando desenvolvi o o meu próprio CMS um dos pontos onde me foquei foi na performance, essencialmente na cache e na redução de pedidos ao servidor. Isto permitiu-me reduzir custos e ter vários sites com um total superior a 250 mil visitas mensais a correr num servidor com apenas 2GB de Ram.

E não são sites estáticos, tal como o Mais Gasolina que tem várias actualizações diárias feitas pelos utilizadores, assim como outros sites onde existem API’s a serem consumidas por serviços externos. Mas com a cache é quase como se fossem.

Actualmente uso uma cache em filesystem, são ficheiros estáticos que são lidos pelo PHP que faz algumas verificações sobre os headers a enviar e devolve o conteúdo que já foi guardado com compressão.

Mas depois de muito ler e ver testes de performance onde o Memcached se mostrava superior até em sistemas com discos SSD decidi experimentar. A alteração de código era mínima, em vez de duas verificações para perceber se o ficheiro existia e abrir e ler o ficheiro, ligava-me ao Memcached e recebia os mesmos dados. Na teoria como estava em memória seria muito mais rápido.

Decidi então testar, primeiro com o sistema actual. Fiz vários acessos com browsers diferentes e fiz uma média do tempo de resposta do servidor através dos vários inspectores de cada browser. Depois com o Memcached fiz o mesmo teste.

Certamente depois de tudo o que li iria ser mais rápido mas constantemente os acessos eram mais lentos entre 1 a 2 ms. Ainda pensei, 2GB de Ram é pouco e pode estar a influenciar os meus testes. Graças à virtualização foi fácil colocar o servidor com 4GB de Ram, o dobro. Repeti os testes e o resultado foi o mesmo, mais 1 a 2 ms com Memcached.

Quer isto dizer que o Memcached é lento? Não! Mas eu podia ter-me guiado pela opinião de outras pessoas e pensar para mim próprio: instalei o Memcached, agora os sites estão mais rápidos. No meu caso em concreto o Memcached não compensa, até porque o sistema operativo não é parvo e acaba por colocar os ficheiros mais lidos em memória. O tempo adicional deve-se ao overhead da ligação ao serviço do Memcached, porque tanto os ficheiros estáticos como o conteúdo do Memcached já estavam em memória.

E antes de começarem a remover Memcached, Varnish ou Squid dos vossos servidores ou a enviarem-me emails a dizer que estou errado, percebam que estou a relatar o meu caso em concreto e o Memcached é uma óptima solução, mas não aqui.

Onde quero chegar com este artigo, ou TL;DR, antes de efectuarem alterações de performance testem e façam testes antes e depois de aplicarem essa alteração e comparem os valores. Não basta aceder uma vez, efectuar alterações, aceder novamente e comparar tempos de resposta. É preciso efectuar vários testes, obter uma média e comparar porque existem muitas variáveis em jogo.

Infelizmente ainda vejo developers e sysadmins a seguirem a lógica de aplicar a grande novidade do Github ou o que leram no Stackoverflow como uma verdade absoluta sem testarem se existem melhorias ou não, e isso tem que mudar para o beneficio de todos, mas especialmente dos utilizadores.

O primeiro trimestre deste ano manteve as tendências do ano anterior, com um aumento do número de utilizadores em mobile, especialmente em Android. E está na altura de começar a matar o Internet Explorer.

Estatísticas

 

Browsers
Browsers

Sem grandes alterações relativamente ao trimestre anterior, apenas o Internet Explorer continua com uma queda nos acessos. 97% dos utilizadores deste browser estão com a versão 11, mas com o aumento de utilizadores em Windows 10 está na hora de começar a mostrar avisos tal como se fez com as versões 6 e 8 do IE e terminar de vez com este browser.

Sistemas Operativos
Sistemas Operativos

Novamente sem grandes alterações com o Windows a manter-se o mais usado mas com Android a ganhar quota de mercado.

O número de utilizadores com a versão 10 já é superior a 50% no universo de utilizadores de Windows.

Resoluções
Resoluções

Nas resoluções continua o mesmo panorama, 360×640 e 1366×768 são as mais usadas e penso que durante este ano não devemos ter grandes alterações, excepto a queda de resoluções mobile baixas com apenas 320px de largura.

As estatísticas aqui apresentadas são provenientes de vários sites com um público alvo generalista. São incluídos os dados de cerca de 200.000 utilizadores únicos baseados em Portugal.
Os dados aqui apresentados podem não corresponder ao público alvo do seu website.

A equipa do CPanel tem andado ocupada com novas funcionalidades de performance e segurança, uma delas é o suporte a HTTP2 com o Easy Apache 4. Está disponível de forma experimental, mas dos testes que efectuei está bastante estável.

E os sites demoram menos 40% do tempo a carregar!

SR71 Blackbird

Efectuei alguns testes através do Pingdom de forma faseada para obter uma média antes e depois de aplicar o protocolo HTTP/2 na página inicial do Mais Gasolina por efectuar pedidos de vários endereços e ter vários tipos de recursos a serem carregados (CSS, JS, imagens, fontes, etc). No total são feitos 47 pedidos e é descarregado um total de 390kB.

Com HTTP/1.1 a média de carregamento ficou nos 1.26s até todos os conteúdos estarem disponíveis, já com HTTP/2.0 a média ficou nos 758ms, uma diferença considerável, perto de 40% mais rápido.

A instalação é extremamente simples, basta seguir os passos indicados na página onde foi pedida esta funcionalidade e em menos de 2 minutos ter os vossos sites com HTTP/2, presumindo que já têm SSL activo, mas se não têm o CPanel também trata disso.

Depois disso podem consultar os headers a partir do vosso browser ou usar uma ferramenta como HTTP2 Test da KeyCDN para verificar que o vosso site já suporta HTTP/2.

Uma forma de tornar o Apache mais rápido é desactivar o suporte a ficheiros .htaccess. Neste artigo vamos aprender como o fazer, mas sem perder a versatilidade que um .htaccess permite.

Comboio Maglev

Os ficheiros .htaccess permitem definir configurações especificas a um determinado domínio sem ser necessário aceder às configurações do servidor em si. Isto é óptimo para ambientes de alojamento partilhado ou servidores privados com vários websites, permitindo configurações independentes para cada domínio.

Mas esta leitura é lenta, o Apache na sua configuração padrão pode recuar vários directórios à procura de um ficheiro .htaccess e aplicar as suas regras. Isto é feito em cada pedido, mesmo com conteúdo estático. Se desactivarmos esta funcionalidade o Apache fica muito mais rápido.

Desactivar é simples, mas queremos manter as regras do mod_rewrite, mod_expires e afins. Estes são os passos que segui para o fazer num servidor com CPanel, mas existem outras formas de o fazer.

Desactivar o .htaccess

Através do WHM do CPanel se acedermos a Apache Configuration > Include Editor vamos editar o ficheiro post_virtualhost_global.conf onde vamos colocar as nossas configurações. Este ficheiro não é rescrito na actualização do Apache, sendo através do CPanel o método ideal em vez de editar os ficheiros do Virtual Host directamente via SSH.

Neste ficheiro vamos colocar os apontadores para os nossos ficheiros .htaccess

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Regras gerais
<Directory "/">
	IndexIgnore *
	AllowOverride none
</Directory>

# Regras separadas por directório, por site
<Directory "/home/username/public_html/">
	IncludeOptional /home/username/public_html/.htacces[s]
</Directory>

<Directory "/home/outrousername/public_html/">
	IncludeOptional /home/outrousername/public_html/.htacces[s]
</Directory>

Explicando o código, no directório inicial “/” vamos aplicar as regras comuns a todo o servidor, neste caso remover os indexes das pastas sem ficheiros index e desactivar o .htaccess com o AllowOverride como none.

Depois para cada pasta de cada site que temos vamos criar uma entrada onde colocamos o ficheiro .htaccess.

O ficheiro é incluído sempre dentro de um parâmetro Directory. Assim em caso de erro no ficheiro ou um ataque apenas vamos afectar aquele domínio.

Usa-se o IncludeOptional com um pequeno truque que encontrei no Stack Overflow para que seja verificado um padrão no nome do ficheiro, desta forma se o ficheiro for eventualmente eliminado não ocorrem erros de configuração e o Apache continua a funcionar.

Se pretenderem também podem copiar o conteúdo do ficheiro .htaccess para aqui, mas desta forma o conteúdo fica separado em ficheiros por cada site, torna-se mais fácil a sua gestão e mantém-se a compatibilidade com algumas funcionalidades do CPanel ou scripts como o WordPress.

Porque é mais rápido desta forma?

Ao contrário de um ficheiro .htaccess carregado pela forma convencional, onde as regras são interpretadas e aplicadas sempre que é feito um pedido (mesmo em conteúdo estático), aqui as regras são carregadas e interpretadas quando o Apache inicia, ficando em memória.

Removemos assim o processo de verificar várias pastas à procura de ficheiros .htaccess e a leitura dos mesmos.

Pontos a ter em conta

Desta forma continua a ser possível usar ficheiros .htaccess, mas o modo de funcionamento não é igual.

Como indiquei os ficheiros são lidos quando o Apache arranca, isto quer dizer que podemos remover ou editar estes ficheiros e as novas regras apenas são aplicadas se reiniciarmos o serviço. Dependendo do sistema operativo onde estamos a correr podemos forçar via SSH o carregamento das regras com um reload.

O ano de 2016 chegou ao fim e destacou-se por ser um ano com um grande crescimento nos acessos através de telemóveis em Portugal.

O crescimento foi de tal forma que o número de utilizadores móveis já é superior ao número de utilizadores com desktop / portáteis e continua a subir. O Android já tem quase tanta utilização nos acessos à Web como o Windows.

Estatísticas

 

Browsers
Browsers

O Chrome continua a ganhar terreno, podendo-se tornar no próximo Internet Explorer com uma fatia significativa do mercado. Neste momento 64%.

No caso do Internet Explorer apenas a versão 11 continua com acessos, já as versões do IE10 e IE9 contam com um número inferior a 1000 utilizares, num universo de 200.000.

Novos websites a serem desenvolvidos podem optar por suportar apenas a versão 11 do IE. Ignorar este browser infelizmente ainda não é possível porque conta com 7% do mercado.

Sistemas Operativos
Sistemas Operativos

Os acessos em mobile continua a ser superiores aos em desktop, mas o Windows continua a ser o mais usado, seguido pelo Android. Estes dois sistemas operativos dominam o mercado com mais de 80% dos utilizadores.

Linux continua a cativar poucos utilizadores em desktop e portáteis, tendo uma percentagem de utilização inferior a 0,5% e deixa assim de figurar nas estatísticas. O Windows Phone que tem um número de utilizadores irrisório consegue ter mais do dobro de acessos do que Linux.

Resoluções
Resoluções

Nas resoluções continua o mesmo panorama, 360×640 e 1366×768 são as mais usadas.

As estatísticas aqui apresentadas são provenientes de vários sites com um público alvo generalista. São incluídos os dados de cerca de 200.000 utilizadores únicos baseados em Portugal.
Os dados aqui apresentados podem não corresponder ao público alvo do seu website.
 
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.