1. Use imagens mais leves!
2. Indique no código HTML as dimensões da imagem
3. Limite os widgets e botões ao essencial
4. Diminua a quantidade de posts apresentada na primeira página
5. Veja-se livre de código desnecessário
6. Reduza a quantidade de pedidos HTTP
7. Diminua o tamanho dos ficheiros CSS e JS
8. Limpe o código redundante dos templates

A abundância de largura de banda, o preço reduzido do espaço em disco e do processamento criaram uma atmosfera de facilidade. Sobrou contudo uma razão bastante boa, racionalmente falando, para optimizar o peso de uma página e seus componentes: a velocidade a que o destinatário a recebe. E mesmo ao nível do servidor, cada milissegundo conta.

1. Use imagens mais leves!
   • A maioria dos autores envia fotos sem prestar atenção às dimensões reais, por vezes muito grandes; é vulgar vermos a instrução para o limite da dimensão das imagens dado através do código na altura da inserção (o width e o height), mas esse “truque” só reduz a dimensão de exibição: o ficheiro da imagem mantém-se inalterado e quase sempre tem um peso extraordinário!
   • A solução: edite as imagens ANTES de as enviar para a Net. Qualquer editor de imagem serve, até o Paint, embora não o recomende de todo: antes usar um serviço web de optimização de imagens como este, que é versátil quanto baste.
   • Tome por referência a largura de 600 pixels: acima disso é garantido que a imagem vai sair do espaço útil da janela de uma grande parte dos browsers. Eu faço as minhas imagens com 450 pixels de largura, no máximo. Preste também atenção, no caso das fotos tiradas de máquinas digitais, à resolução. Guarde a versão grande, mas para publicar na Web faça uma cópia com o máximo de 72 pixels: acima disso os monitores simplesmente não mostram, cortam os pixels do meio.
   • Com esta medida, reduzi o peso total da primeira página de um determinado blogue de uns incríveis 4 Megabytes para uns 700 Kb — ainda acima do ideal — sem que o próprio autor notasse qualquer alteração na visualização do seu blogue!
2. Indique no código HTML as dimensões da imagem.
   • Parece disparate, meter nos preencher os parâmetros width e height com as dimensões correctas da imagem — mas não é: esta indicação poupa tempo ao computador do leitor, cujo browser fica a saber que espaço deve reservar para a imagem mesmo antes dela chegar (o código da página é mais leve e chega primeiro), fazendo a apresentação correcta do texto enquanto a imagem ainda está em trânsito.
   • Além da velocidade, torna a recepção da página mais agradável, causando impressão positiva.
3. Limite os widgets e botões ao essencial.
   • Nem falo do ruído visual que provoca o excesso de widgets e botões que “adornam” tantos blogues respeitáveis. Limito a análise ao respectivo mau contributo para a velocidade.
   • Verifique se todos os widgets e botões estão funcionais; sei de casos em que o serviço já está desactivado há algum tempo…
   • Verifique se têm de facto alguma utilidade. A maior parte dos botões torna-se inútil ao fim de um certo tempo, quando surge uma nova moda, um novo “top blogs”, o último grito do widget…
   • Verifique, através do seu contador, se a quantidade de tráfego enviado pelo serviço é de molde a justificar a sua permanência. Se não for, e se não achar que é um botão ou widget particularmente prestigiante, tire-o. Só está a fazer peso, ninguém lhe liga, não serve para nada.
   • Uma boa regra para a selecção do que vai colocar (ou deixar…) na sua barra lateral é: o que tem a ganhar? Prestígio? Links? Tráfego? Meça o que dá e o que recebe. A maioria das widgets não dá nada, ou dá muito pouco para o que recebe da exposição na SUA página.
4. Diminua a quantidade de posts apresentada na primeira página.
   • O tempo em que percorríamos uma página inteira, por aí abaixo, já lá vai há que anos… Hoje, o visitante ou é seu leitor regular, e visita-o com frequência suficiente para já ter lido os posts da semana passada (e para saber maquinalmente onde está o arquivo…), ou é um leitor novo, a quem a primeira impressão do seu blogue é o que está acima da linha de água — e a velocidade a que este lhe surge no monitor!
   • Não se fie no mau exemplo de alguns bloggers históricos que mantém lençóis de um mês (!) na primeira página: o seu blogue ainda não é daquele campeonato. Use as suas armas, porque não dispõe das deles. Seja como for, mesmo para um blogger de topo é um erro uma página longa e só os anacrónicos bloggers as mantém.
   • Nas blogosferas mais adiantadas a tendência é para páginas de entrada pequeníssimas. Não aconselho mudanças dramáticas: ir encurtando aos poucos é mais prudente.
5. Veja-se livre de código desnecessário.
   • O meu último template carregava por defeito um Javascript com 28 Kb que nunca era processado porque eu não usava uma determinada funcionalidade da minha instalação WordPress… Isto diz tudo.
   • Verifique se todos os ficheiros carregados pelo seu template são realmente necessários e elimine as chamadas no código se não forem. Evitará o duplo desperdício de tempo, do lado do servidor e do lado do cliente.
6. Reduza a quantidade de pedidos HTTP.
   • Quantos mais elementos tem uma página, mais pedidos HTTP são enviados pelo browser para o servidor, aumentando o tempo de resposta deste para “construir” a página que vai servir. Há sempre imagens a mais num template, por exemplo.
   • Limite o número de objectos e junte-os: um único ficheiro CSS contendo todos os elementos é melhor que três, ou quatro — até cinco, como tenho visto em tantos casos. O mesmo é válido para os ficheiros de scripting (Javascript, nomeadamente).
   • (Esta é uma optimização que ainda não fiz no C! por falta de tempo, mas não tarda.)
7. Diminua o tamanho dos ficheiros CSS e JS.
   • Contém sempre anotações do autor que podem ser retiradas sem prejuízo algum, bem pelo contrário. É cada vez mais frequente nos fabricantes de pluginstemplates o cuidado em disponibilizarem versões leves, com menos funcionalidades, ou no mínimo documentação que permite ao autor saber que parte do código Javascript pode retirar se não usa determinada função.
   • Mantenha as cópias anotadas à parte, para as alturas em que vai trabalhar no template, e use cópias depuradas. Vai ver que consegue facilmente ganhos de 15 a 30% no tamanho desses ficheiros.
8. Limpe o código redundante dos templates.
   • No WordPress como nas outras plataformas, os templates são feitos para adaptação a milhares de casos diferentes. Daí os códigos como <?php bloginfo('name'); ?> e <?php bloginfo('rss_url'); ?>. O primeiro coloca naquele ponto do template o nome do blogue e o segundo coloca o endereço do feed RSS. Eis duas informações que não mudam muitas vezes… Pelo que ao substitui-las pelo nome e pelo endereço estamos a poupar chamadas à base de dados. São milissegundos, certo, mas repetem-se de cada vez que uma página é mostrada — num dia de muito tráfego fará alguma diferença ao seu servidor.

Há técnicas mais extremas de limpeza de templates. Aprendi algumas delas por causa dos problemas de crescimento tanto do weblog.com.pt como agora da TubarãoEsquilo. Com a última, reduzi num quarto de segundo o tempo de carregamento de cada uma das páginas do Arrastão! Falarei disso num próximo artigo.

1. O curioso
2. O social
3. O reservado
4. O introvertido
5. O oportunista (não negativo, sublinha)
6. O arrivista

Auto-classifico-me na classe dos oportunistas: uso o Twitter sobretudo como canal alternativo de distribuição do que escrevo na Internet (PauloQuerido) e dos fluxos noticiosos do Expresso, da SIC e da TubarãoEsquilo, e muito pouco como microblogging, interagindo raramente através do serviço.
Uma curiosidade: também o Twitter atrai os fakers — indivíduos que usam (ou abusam) de nomes muito populares, criando contas de apelo irresistível como a de José Sócrates. Mas ao contrário da bitola americana, onde só triunfam fakers com piada e/ou inteligência, este faker português é tosco e não tem arcaboiço para aguentar a farsa. É pena — alguns dos melhores momentos da web social têm sido proporcionados pelo brilhantismo irreverente de fakers.

Tudo vai bem quando corre bem, até que o inesperado acontece. Desta vez a minha dor de cabeça envolveu o plugin recomendado pelo FeedBurner: o FeedSmith. O FeedSmith limita-se a detectar e redireccionar o feed do nosso blog, para o nosso endereço feed no FeedBurner.
Eis a mensagem de erro que surgiu:
Warning: ob_start() [ref.outcontrol]: output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter' in /home/danielma/public_html/wp-includes/functions.php on line 408

O erro surgia no topo do blog e no próprio feed impedindo que os meus artigos chegassem aos assinantes.

A solução
A solução foi mais simples de encontrar do que o que eu julgava. Bastou desactivar o plugin e inserir umas linhas de código no ficheiro .htaccess:


RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/NomeDoMeuFeed [R,L]


Este código deverá ser copiado para a zona antes da secção de código adicionada pelo WordPress
e “NomeDoMeuFeed” deverá ser substituído pela designação do vosso feed no FeedBurner.

( Daniel Marques tem um blogue pessoal e é um dos mais recentes autores TubarãoEsquilo com o Controlo remoto — um blogue de marca sobre televisão digital. )

O melhor disto é que a explicação é mais complicada do que o código. Vamos lá.

Como proceder
(Esta técnica foi produzida em código PHP mas é traduzível para outras linguagens. O exemplo é de aplicação imediata, por copia+cola, a um blogue em WordPress)

Localize o ficheiro index.php na raiz do seu blogue. No WordPress é simples: menu Gerir -> Ficheiros e clique no Modelo do Índice Principal (ver figura).
O conteúdo actual do ficheiro deverá ser este ou muito similar:
<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>


O que vamos lá colocar é isto (a negrito os acrescentos e a vermelho o que deverá mudar):
<?php
$idepassear = 0;
if (preg_match("/lnksts/", $_SERVER['HTTP_REFERER'])) {
$idepassear = 1;
}
if ($idepassear == 1) {
header("HTTP/1.1 307 Temporary Redirect");
header("Location: http://lnkths.com/certamente-teste");
exit;
}
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>


A explicação do código
$idepassear é uma variável. O nome dela… foi suavizado para publicação e trata-se de homenagem a um hacker que me ensinou umas artimanhas e que tem um gosto particular pelo calão. Podia chamar-se $variavelum. É inicializada a zero (era dispensável; mas incluí-a por uma questão de clareza — e não só; num post lá mais para a frente voltaremos a esta variável para mais acções de ciberdefesa).
A linha seguinte verifica se o cliente vem de alguma página através de um link e se sim, verifica se o sítio de origem contém a expressão lnkths. Se contiver, a variável $idepassear passa a ter o valor 1. Com essa expressão, qualquer link produzido em lnkths.com será dinamitado. (Cuidado com a expressão a escolher para colocar aqui; se for demasiado abrangente, pode bloquear mais endereços do que gostaria. Imagine que lá metia “blogspot”…)
A seguir, o coração do sistema (como eu gosto desta expressão): se o conteúdo de $idepassear for igual a 1, o cabeçalho (header) que o index.php envia para o browser contém a nova localização para onde o cliente deve ir. Como já disse, eu devolvo-os à procedência mas podemos aí colocar qualquer endereço! Como Location: http://google.com/search?q=troll
A parte do código 307 destina-se a eventuais motores de pesquisa que venham por ali: indica um redireccionamento temporário, pelo que o nosso domínio não será afectado (sem a indicação, não é claro se poderia perder algum “sumo” em termos de Google, que desconfia dos redireccionamentos, sobretudo dos condicionais. Não considerei no âmbito deste post qual o melhor código de redireccionamento — que, estou certo, alguns leitores gostarão de debater, e eu também.)
Se a variável $idepassear contiver o valor 0, o index.php salta para a instrução seguinte e desenvolve-se o pedido de página normal.

É importante
1. fazer primeiro uma cópia de segurança do conteúdo do index.php
2. copiar o código tal e qual, basta uma aspa a menos ou a mais, ou a omissão de um ponto e vírgula, para o index.php não funcionar! (pode sempre repor o conteúdo salvaguardado e repetir as instruções com mais cuidado)
3. colocar o bloco de alterações ANTES do resto do conteúdo do index.php.

Nota final
No meu caso, o uso destas simples linhas é uma acção ciberdefensiva activa — sobretudo sanitária, devo dizer, tendo em conta os “blogues” que bloqueei. Mas no caso do amigo que já beneficiou do código — que aplicou sem problema algum, embora eu suspeite que foi a primeira vez que mexeu em PHP — trata-se de mais do que isso. Sendo vítima de cyberbullying, evitar os links do seu troll, como carinhosamente o trata, tornou-se também num conforto moral.
Saber que podemos fazer algo, por pouco que seja, que afecte as intenções do perseguidor, é por um lado um sinal interior de resistência e por outro representa uma vitória num jogo onde nos avisaram que só teríamos derrotas.

Adendas
1. Este código é fornecido na versão it works for me — isto é, funciona comigo, é uma prova de conceito despretenciosa e não foi feito a pensar em uso por profissionais, que estão convidados desde já a apresentar versões mais robustas e decentes, que possam filtrar também por agente (browser), por exemplo.
2. Não sou versado em Javascript, pelo que atrever-me a escrever a versão nessa linguagem seria consumidora de tempo e o mais certo era não ficar obra decente às primeiras. Mas certamente algum leitor meu é, pelo que fica o repto para a versão Javascript — que tem a vantagem de alargar a utilização a muito mais plataformas, nomeadamente às plataformas de blogging comerciais como o Blogspot, ou o WordPress.com.
3. A mesma técnica pode ser usada, com eficácia forte e feia, para minorar os efeitos de ataques pontuais, ou súbitos, de spam. Foi, aliás, por aí que começou a vida do meu index.php reforçado com a variável $idepassear. Só mais tarde vi este seu potencial escondido e o modifiquei em conformidade (e o spam combate-se melhor a um nível mais perto da máquina.)