Como já era de se esperar, o Facebook vem fazendo o possível e o impossível para bloquear quaisquer meios de exportar os contatos. Já bloqueou extensões e plugins que faziam isso. Tudo para dificultar o crescimento do Google+. Ok, dá pra entender, vai contra o que é útil para o usuário, mas vai a favor dos interesses do Facebook.

Aqui vai a dica então… tudo que você vai precisar para isso é uma conta de email no Yahoo! Caso não tenha, dá pra criar uma rápido e sem custo.

Passo a passo

1. Abra a página do Yahoo! em http://www.yahoo.com.br/

2. Clique em “email”, no menu lateral esquerdo, para acessar o seu email @yahoo.

3. Entre com seu handle Yahoo! e sua senha, e clique no botão para entrar.

4. No menu superior do webmail, clique em “Contatos”

5. No lado direito da tela que vai abrir, siga com a primeira opção, “Importar contatos”

6. Escolha Facebook, e autorize o acesso na janela que vai abrir.

7. Com isso, o Yahoo! vai fazer a importação de todos os seus contatos do Facebook.

8. Clique no link para ver a lista dos contatos que acabaram de ser importados.

9. Marque todos eles, vá no botão “Ações” logo em cima, e escolha “Exportar tudo”.

10. Clique para exportar os contatos no formato Yahoo! CSV, e os contatos já estarão prontos para serem importados no Google, ou abertos em uma planilha.

11. Pronto! Só se logar no Gmail, e importar o arquivo que você fez download na parte de contatos. Entrando no Google+, todos estarão lá, prontos para serem convidados / adicionados.

É bom fazer isso o quanto antes… vai saber quanto tempo vai demorar até o Facebook bloquear isso tambem.

Artigos relacionados

• Nenhum artigo relacionado

<meta name="generator" content="WordPress 2.8.4" />

Muita gente não gosta de anunciar para o mundo a versão usada. Seja por não querer exibir o uso do WordPress, ou por medo de alguem usar essa informação para um possível ataque contra essa versão específica do WordPress, existe uma forma muito simples de retirar isso do cabeçalho, sem precisar editar os arquivos do sistema (que a priori, nunca devem ser editados).
Essa tag é inserida no cabeçalho através de uma action padrão, chamada wp_generator. Para não exibir, basta remover a action, adicionando o seguinte código no functions.php do seu tema:

<?php
remove_action('wp_head', 'wp_generator');
?>

Pronto, com isso o seu site não irá mais exibir esta tag no cabeçalho.

Artigos relacionados

• Agendando eventos no WordPress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

CFLAGS="-O2 -fomit-frame-pointer -march=nocona -pipe"

Essas flags especificam uma otimização nível 2 (pode ir de 0 a 3 – o 3 quebra alguns pacotes, por isso é recomendável usar o 2), e especifica também para qual conjunto de instruções os binários serão gerados. No meu caso, estou dizendo que os binários deverão ser compilados para se usar todo o poder do processador nocona (os dual/quad cores da Intel).
Até aí, tudo funcionando bem. Montei um sistema todo com essas flags, e estava tudo muito bem, até que precisei instalar o Bacula, um software para se fazer backups de sistemas completos.
O Bacula, com as CFLAGS padrões estava gerando um binário quebrado. Pesquisando, descobri que o projeto Hardened do Gentoo, que usa uma série de artifícios para gerar executáveis mais seguros e imunes contra ataques como buffer overflow era o responsável, pois por padrão ele passa a flag “FORTIFY_SOURCE” para o compilador, e isso estava quebrando o Bacula.
Uma das formas de se resolver esse problema seria alterando as CFLAGS no /etc/make.conf, adicionando -U_FORTIFY_SOURCE a elas. Porém, o grande problema é que as CFLAGS são válidas globalmente, e dessa forma, todos os pacotes seriam compilados com essa flag extra, matando parte dos recursos do projeto Hardened.
O que eu queria era poder compilar somente o Bacula com essa flag extra. Uma das formas é usar o diretório /etc/portage/env para criar variáveis de ambientes específicas para cada pacote.
Basta seguir os seguintes passos:

1. 1. Pegue o nome completo do pacote, na forma categoria/pacote. No caso do Bacula, o nome completo é app-backup/bacula.
2. 2. Crie o arquivo /etc/portage/env/categoria/pacote, ou no nosso caso, /etc/portage/env/app-backup/bacula. Caso o diretório “env” não exista, crie toda a árvore necessária.
3. 3. Nesse arquivo, você pode especificar as variáveis de ambiente que serão definidas exclusivamente para a compilação do pacote. Assim, podemos definir CFLAGS neste arquivo:

   CFLAGS="${CFLAGS} -U_FORTIFY_SOURCE"

Pronto. Com isso, temos a flag extra -U_FORTIFY_SOURCE adicionada às flags globais, e só serão utilizadas para o pacote em questão.

Artigos relacionados

• O limite de 4 (ou 3?) Gb de memória

http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado

Para diferenciar, eu poderia usar URLs como as abaixo:

http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado?rss

http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado?email

Desta forma, o site tem como saber de onde o visitante veio, bastando colocar no feed o sufixo “?rss”, e nos boletins o “?email”. O site checaria se a URL contém um desses sufixos, e incrementaria um contador em algum lugar (banco de dados, arquivo, etc).
O grande problema, é que uma vez que os buscadores encontrem essas URLs alternativas, irão notar que o conteúdo é o mesmo para as 3 páginas, e existe a chance de que seu site seja penalizado por isso.
Uma das formas de se lidar com isso é usar a tag <link> para informar qual é a URL “canônica” da página atual. A tag é simples:

<link rel="canonical" href="http://www.example.org/caminho-da-pagina" />

Esta tag é a mesma nas 3 páginas, e indica ao buscador qual é a URL canônica da página. Seguindo o nosso exemplo, nas 3 páginas acima, teríamos a tag:

<link rel="canonical" href="http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado" />

Claro, esta tag serve como uma “dica” para os buscadores, e eles podem usá-la ou não. Na maioria das vezes, ela será usada.
E embora eu tenha dado o exemplo de páginas anunciadas por email ou feed RSS, a utilidade vai bem além disso.
Se você tem um site, digamos de e-commerce, e tem uma página que ordena os produtos por preço, popularidade, etc, e essa ordenação é passada como parâmetro na URL, o conteúdo da página será essencialmente o mesmo, porém com a posição diferente (dependendo da ordenação). O buscador pode entender que a página é duplicada. Uma tag <link> como esta, apontando para a URL sem ordenação resolveria o problema.

Artigos relacionados

• Otimização: imagens inline
• Páginas de manutenção

<img src="imagem.png" />

ou então, podemos carregá-la como imagem de fundo de um elemento qualquer usando CSS:

.classe { background-image:url(imagem.png); }

Um dos problemas em páginas que possuem muitas imagens é que cada imagem requer a abertura de uma nova conexão HTTP, e com a limitação de 2 conexões por host (é uma restrição dos navegadores que seguem a especificação HTTP), o tempo de carga da página pode acabar crescendo bastante.

A lógica

Uma solução para este problema é ao invés de carregar as imagens externas, colocá-las diretamente dentro da página, seguindo a mesma lógica que já usamos com CSS. Por exemplo, podemos especificar uma folha de estilo externa:

<link rel="stylesheet" type="text/css" href="arquivo.css" />

ou então podemos colocar os estilos inline:

<style type="text/css">
.classe1 { font-color:#f00; }
#id2 { width:200px; }
</style>

Codificando a imagem

Até aí, tudo bem, afinal CSS é texto, e texto entra bem dentro de uma página. Mas como colocar uma imagem dentro de uma página, uma vez que a imagem é binária?
Simples! Primeiro, codificamos a imagem de binário para ASCII usando a codificação base64. Existem várias formas de se fazer isso, e boa parte das linguagens de programação disponibiliza funções para fazer esta codificação. Por exemplo, em PHP, podemos fazer:

<?php
print base64encode(file_get_contents("arquivo.png"));
?>

A saída disso é algo mais ou menos assim:

iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6
YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AF
uALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==

Pronto, já temos a representação codificada da imagem.
Para que a saída coubesse na tela, quebrei a saída em 3 linhas. A saída real é toda em uma só linha, mas como veremos adiante, tanto faz, pois podemos usar quebras de linha.

URLs do tipo “data”

Antes de colocarmos a imagem dentro da página, precisamos ver como funcionam as URLs do tipo “data”. A URL segue o seguinte formato:

data:[<tipo MIME>][;charset="<charset>"][;base64],<dados>

onde:

• tipo MIME é o tipo do arquivo que vamos colocar, no nosso caso, image/png;
• charset é a codificação utilizada, para o caso de arquivos texto (não usaremos no nosso exemplo).
• base64 é a codificação utilizada. Se for omitida, o navegador entenderá que estamos usando US-ASCII, e no caso de imagens, não vai dar certo;
• e por último, dados contém a string com o arquivo codificado (aquela sequencia grande de caracteres ali de cima). A string pode ser quebrada com espaços ou quebras de linha.

Juntando tudo

Pois bem, agora que temos a representação codificada da imagem e já sabemos usar URLs do tipo “data”, podemos colocá-la diretamente na página, usando a própria tag img:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZc
GAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6n
yt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==" />

Ou então uma regra de CSS, da seguinte forma:

.classe { background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUh
EUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0
AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7U
Z3wAAAABJRU5ErkJggg==); }

É claro que usar esta técnica, como quase tudo na vida, tem várias vantagens e desvantagens.

As vantagens

Temos várias vantagens em usar um esquema deste tipo:

• Suporte na grande maioria dos navegadores modernos: Firefox, Opera, Safari, Konqueror e Chrome;
• Antes de mais nada, estamos diminuindo o número de requisições HTTP, e consequentemente, evitamos o tráfego associado à requisição (cabeçalhos HTTP);
• Como a imagem está inline, conseguimos “fugir” do limite de 2 conexões por host, já que estamos evitando a abertura de novas conexões;
• Para imagens pequenas, temos um ganho real em bytes transferidos, pois embora a imagem codificada em base64 fique maior, estamos evitando de enviar os cabeçalhos HTTP (que somam em média 200 bytes).
• Conexões seguras (que usam https) só mostram o “cadeado” fechado se todos os elementos externos forem carregados através de https também. E o overhead associado a uma conexão https é bem maior que o de uma conexão http normal. Com a imagem inline, ganhamos mais um pouco.

As desvantagens

Temos várias desvantagens, algumas contornáveis:

• Internet Explorer até a versão 7 não tem suporte. Só a partir do 8. A forma de se usar para os dois navegadores é usando arquivos CSS separados para cada navegador (ou um pré-processador de CSS que detecte o navegador e dê a saída com o que for suportado);
• Imagem inline em uma página (usando tag img) não são cacheadas pelo navegador. Se usada dentro do CSS, aí sim teremos o cache em ação, pois o navegador irá cachear o CSS;
• Uma imagem codificada em base64 tem seu tamanho aumentado em 33%. Para imagens grandes, é uma perda considerável, mas para imagens pequenas (da ordem de 500 bytes), temos um ganho, pois mesmo com o aumento da imagem, estamos evitando o envio dos cabeçalhos, e podemos sair ganhando na soma;
• Dificuldade de manutenção: se uma imagem é alterada, ela precisa ser recodificada. Existem formas de se automatizar isso.

Um exemplo

A imagem que aparece aqui embaixo está inline, e foi colocada usando uma tag img (a qualidade está baixa pra não ficar muito grande):

Clicando o botão direito na imagem e escolhendo “Exibir imagem” (no Firefox ou em outro navegador que dê suporte), dá pra se ver na barra de endereços a URL usada pra criar a imagem.
E claro, se você não está vendo imagem nenhuma, provavelmente está usando o Internet Explorer. E já passou da hora de passar a usar um navegador decente, que suporta os padrões web, não é?

Artigos relacionados

• Evitando conteúdo duplicado
• Otimização de sites com memcached
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify

Como o cache pode ajudar?

Nos outros artigos, vimos como diminuir o número de requisições (agrupando vários arquivos em um só) e também como diminuir o tamanho do que é transferido.
Mas… e se não precisarmos fazer todas essas requisições? A grande maioria das páginas de um site tem arquivos em comum, e que não mudam. Imagens estáticas, folhas de estilo CSS e scripts em JavaScript. E após a primeira carga, o navegador já vai ter esses arquivos localmente.
Só nos resta dizer pra ele quando e o que ele pode usar nas requisições seguintes.

Quais as formas de se usar o cache?

Uma vez que o navegador tenha, digamos, uma imagem estática em cache, existem duas formas dele proceder pra saber se o arquivo é atual ou não.
A primeira é fazer uma requisição indicando a data em que o arquivo foi buscado. Essa requisição é feita enviando um cabeçalho “If-Modified-Since”, com a data do arquivo local. Caso o arquivo não tenha sido modificado, o servidor responde com o código 304 (Not Modified) ao invés de devolver o arquivo novamente.
A segunda forma é somente pedir o arquivo caso ele já tenha expirado.
Logicamente a segunda forma é bem mais econômica, pois evita a abertura da conexão.
Porém, temos um problema: como saber se um arquivo já expirou?

O cabeçalho “Expires”

Qualquer arquivo solicitado em uma conexão HTTP pode ter associado um cabeçalho Expires, que indica explicitamente a “data de vencimento” daquele arquivo. Ou seja, até a data especificada, o arquivo é válido e não precisa ser checado novamente. Após isso, o navegador deve considerar o arquivo como expirado, e solicitar novamente.
Então, para arquivos estáticos, podemos colocar uma regra dizendo que a data de vencimento dele é em um futuro distante. Isso pode ser feito, em um servidor Apache, com uma regra semelhante a esta:

ExpiresActive On
ExpiresByType image/gif "access plus 5 years"
ExpiresByType image/jpeg "access plus 5 years"
ExpiresByType image/png "access plus 5 years"
ExpiresByType text/css "access plus 5 years"

Neste exemplo (que utilizo aqui neste site), estou indicando explicitamente que arquivos do tipo GIF, JPEG, PNG e CSS tem validade de 5 anos da data do download. Antes disso, o navegador pode assumir que o conteúdo é atual e utilizá-lo.
Deixei o JavaScript de lado porque atualmente não estou utilizando nenhum script neste site. Caso queira adicionar na lista, basta duplicar uma das linhas, usando o tipo text/javascript.
Após o primeiro acesso, todas as imagens e folhas de estilo serão cacheadas, e o navegador não irá solicitá-las novamente. Isso dá um bom ganho de desempenho, pois o número de requisições necessárias para carregar as páginas subsequentes (e o correspondente tamanho em bytes) cai consideravelmente.

O resultado

Tomando como exemplo a página inicial deste site, e testando com um navegador com o cache completamente limpo, temos, para o primeiro acesso 21 conexões, sendo 1 para a página propriamente dita, 3 arquivos CSS externos, e 17 imagens externas.
Em um segundo acesso à mesma página (cliquei no logotipo lá em cima à esquerda), apenas uma única conexão foi aberta, para baixar somente a página em si. Todas as imagens e folhas de estilo já estavam no cache do navegador, e ele “sabe” que elas só vão expirar daqui a 5 anos. Logo, não tem porque verificar se foram alteradas.

Possíveis problemas

Um dos problemas neste tipo de configuração é o que fazer caso se precise fazer uma alteração em uma imagem ou em um arquivo CSS.
Nesses casos, como o navegador não está nem checando, o melhor a fazer é alterar o nome do arquivo, por exemplo, colocando um número contendo a versão ou a data de modificação. Com isso, o navegador irá interpretar o arquivo como algo novo, que ele ainda não possui em cache, e que precisa ser baixado.
Porém, o ganho que se consegue com o uso dessa técnica faz, na minha opinião, valer a pena o esforço. Existem algumas formas de se automatizar o processo de alteração do nome do arquivo, que deixarei para discutir em um outro artigo.

Artigos relacionados

• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Otimização de sites com memcached
• Otimização: imagens inline
• Páginas de manutenção

Comparação em ponto flutuante

As variáveis do tipo float sofrem de um problema de precisão, pois dependendo do número, ele pode não ter uma representação binária (em potências de 2) exata. Para nos resolver, o PHP (e a grande maioria das linguagens) faz o arredondamento do número. Por exemplo, se fizermos o seguinte teste:

<?php
var_dump(0.1 + 0.2 == 0.3); // saída:  bool(false)
?>

Claro que, matematicamente falando, 0.1 + 0.2 é igual a 0.3. Porém, a forma como o PHP guarda esses números internamente não é exata. Para vermos como o PHP guarda cada um desses números, podemos chamar a função serialize():

<?php
print serialize(0.1); // d:0.1000000000000000055511151231257827021181583404541015625;
print serialize(0.2); // d:0.200000000000000011102230246251565404236316680908203125;
print serialize(0.3); // d:0.299999999999999988897769753748434595763683319091796875;
?>

E fazendo a conta, fica evidente que 0.1 + 0.2 não dá 0.3. E então, como fazer para comparar variáveis do tipo float sem chance de errarmos?
Uma forma é definir uma constante, que por convenção chamarei de EPSILON, que terá o valor do menor número fracionário possível. Qual valor colocar? Depende da aplicação! Se sua aplicação mexe com valores financeiros, normalmente você precisa se preocupar com frações de 2 ou 3 casas decimais no máximo. Podemos então definir o EPSILON, com uma boa margem de segurança, para 1e-5, ou seja, 0.00001.
Tendo esta constante, se queremos checar se dois números são iguais, podemos simplesmente checar se a diferença entre eles é menor que EPSILON. Caso seja menor, podemos considerar os números iguais. Da mesma forma, podemos fazer a comparação entre floats da mesma forma.
Uma função simples, que tem o retorno semelhante à função de comparação de strings strcmp(), mas que serve para comparar floats poderia ser definida assim:

<?php
define("EPSILON", 1e-5);
 
function floatcmp($a, $b) {
    $diff = abs($a-$b);
    if ($diff < EPSILON) {
        return 0;
    }
    return ($a<$b) ? -1 : 1;
}
?>

Esta função recebe dois números como parâmetro. Se os números forem iguais, ou seja, se a diferença entre eles for menor que a nossa margem de erro aceitável EPSILON, a função retorna 0, caso contrário retorna -1 se o primeiro número for menor, ou então 1 caso o segundo seja o menor. Bastante simples e eficaz.
Para fazermos o teste acima, podemos agora proceder assim:

<?php
if (floatcmp(0.1+0.2, 0.3) == 0) {
    print "são iguais";
}
else {
    print "são diferentes";
}
?>

O resultado, como esperado, será “são iguais”.

Números começados com zero

Outro problema muito comum, principalmente quando estamos lidando com datas, é o da comparação de números iniciados com 0. Por exemplo:

<?php
var_dump(09 == 9); // saída:  bool(false)
?>

Isto ocorre porque o PHP trata qualquer número iniciado com 0 como um número octal, ou seja, na base 8. Caso o número não seja um octal válido, a conversão para no primeiro dígito inválido. No caso acima, 09 vira 0 (pois não existe 9 na base octal).
Para fazer esta comparação, uma das formas seria a seguinte:

<?php
var_dump("09" == 9); // saída:  bool(true)
?>

Agora, temos a string “09″, que será convertida no inteiro 9 (base 10 mesmo) antes da comparação, e aí sim, o resultado será o esperado.

Busca de strings com strpos()

É muito comum usarmos a função strpos() para buscarmos strings. O formato da função é:

int strpos (string $haystack, mixed $needle  [, int $offset=0 ] )

onde haystack é onde estamos fazendo a busca, e needle é o que queremos encontrar. O retorno desta função é a posição onde a string foi encontrada, ou false caso ela não seja encontrada. O terceiro parâmetro, opcional, serve para informar a partir de que posição queremos fazer a busca.
Façamos o seguinte teste:

<?php
if (strpos('abcdefg','abc')) {
    print "encontrei";
}
else {
    print "não encontrei";
}
?>

A saída deste exemplo é “não encontrei”, mesmo com a string “abc” tendo sido encontrada na string “abcdefg”. O grande problema, neste exemplo, é que a string foi encontrada na posição 0. Logo, a função strpos() retorna 0. E o valor 0, em uma comparação booleana, é equivalente a false, e por isto o resultado acaba não sendo o esperado.
A forma correta de se fazer este teste é utilizando o operador ===, que além de checar o valor, também checa o tipo do retorno. Podemos fazer assim:

<?php
if (strpos('abcdefg','abc') !== false) {
    print "encontrei";
}
else {
    print "não encontrei";
}
?>

E agora, teremos o resultado esperado “encontrei”.

Existem várias outras “pegadinhas” no PHP (já escrevi por exemplo, sobre os operadores and e or, no artigo sobre precedência), que muitos podem considerar como bug ou algum problema sério da linguagem, mas a maior parte dos problemas tem uma explicação lógica.
Retirei parte dos exemplos de um post na Zend Developer Network, e como passei por problemas com floats recentemente, achei que seria interessante compartilhar.
Caso alguem tenha mais algumas “pegadinhas” para compartilhar, fique a vontade para fazer um comentário.

Artigos relacionados

• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

Porém, tão importante quanto minimizar o número de conexões, é ter certeza de que a quantidade de dados transferidos seja sempre a menor possível. Como vimos antes, o Minify já ajuda nesse sentido, pois retira dos scripts e das folhas de estilo caracteres desnecessários como espaços em branco e quebras de linha.

Este artigo não é específico de PHP, pois lida uma camada abaixo, direto no protocolo HTTP. As soluções apresentadas aqui podem ser implementadas diretamente na linguagem, mas ficam bem melhores se implementadas no servidor (Apache, no caso), como demonstrado neste artigo.

Começando com o HTTP 1.1, os navegadores podem especificar formas de codificação aceitáveis para o conteúdo, através do cabeçalho Accept-Encoding. Por exemplo, utilizando:

Accept-Encoding: gzip, deflate

o navegador indica para o servidor web que pode receber o conteúdo solicitado de forma comprimida, utilizando um destes dois métodos (gzip ou deflate). Caso o servidor possa comprimir utilizando uma das formas solicitadas, irá retornar um cabeçalho Content-Encoding, informando a codificação usada, como por exemplo:

Content-Encoding: gzip

A codificação mais popular hoje em dia é o gzip, que é uma especificação aberta e bem documentada pela RFC 1952. A outra codificação (deflate) também pode ser usada, mas é menos popular e menos eficiente que o gzip.

A codificação gzip consegue comprimir conteúdo texto (HTML, CSS, JavaScript, e outros) em aproximadamente 70%. Levando-se em consideração que mais de 90% dos navegadores atualmente em uso suportam esta compressão, é altamente recomendável configurar o servidor web para comprimir arquivos texto.

Para o Apache, dependerá da versão utilizada. O Apache 1.3 utiliza o mod_gzip, enquanto que o Apache 2.x usa o mod_deflate. Como o Apache 1.3 já não é muito utilizado, vou mostrar os exemplos para o mod_deflate.

Devemos levar em conta que somente arquivos texto devem ser comprimidos. Arquivos binários, como imagens, áudio e vídeo em geral já estão em um formato comprimido, e colocar mais compressão em cima, além de não diminuir o tamanho do arquivo (pelo contrário, as vezes até aumenta!), causa também desperdício de CPU para o servidor.

A configuração do mod_deflate em geral é feita especificando quais tipos de arquivo serão comprimidos. Em geral, arquivos texto devem ser comprimidos. Podemos, por exemplo, especificar que alguns tipos devem ser comprimidos utilizando diretivas de Apache como:

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript text/x-json

A primeira linha liga o mecanismo de compressão do mod_deflate, e a segunda especifica alguns tipos que devem ser comprimidos. No caso, estou informando ao servidor que arquivos tipo HTML, texto puro, XML, CSS, JavaScript e JSON devem ser comprimidos. Alguns navegadores mais antigos podem ter problemas com a compressão gzip, mas felizmente isto é coisa do passado. De qualquer forma, a página com a documentação do mod_deflate mostra como desligar a compressão de acordo com o navegador usado.

Um bom site para se testar se o servidor está configurado corretamente para servir conteúdo comprimido é o mod_gzip Test. Basta colocar a URL do site e clicar em “Test” para saber se o servidor está preparado para servir conteúdo comprimido.

Artigos relacionados

• Otimização em PHP, parte 1: Minify
• Otimização de sites, parte 3 – Cache
• Envio de emails em massa
• Otimização de sites com memcached
• Otimização: imagens inline
• Acessando sites fora do ar
• Páginas de manutenção

Existem alguns fatores que influenciam no tempo de carregamento de uma página:

• Tamanho total dos dados
• Tempo de geração da página
• Número de conexões HTTP necessárias

O tamanho total dos dados é de extrema importância, pois quanto mais dados pra se transferir (páginas, imagens, folhas de estilo, scripts externos, etc), maior o tempo de carregamento de uma página. O tempo de geração também é importante, e este tempo depende de uma programação eficiente e de um banco de dados rápido.

Porém, o número de conexões necessárias é frequentemente esquecido, e é um fator de extrema importância para que uma página seja carregada rapidamente.

Para entendermos o porque, precisamos saber o que o navegador faz quando pedimos para ele abrir uma página.

Primeiramente, é realizada uma consulta ao servidor DNS para se determinar o endereço do servidor que estamos tentando acessar. Esta consulta leva algum tempo, mas normalmente é cacheada pelo navegador uma vez feita. Num segundo passo, temos a primeira conexão, que baixa a página que foi pedida.

Após a busca da página, o navegador analisa sua estrutura, e busca elementos externos necessários, como imagens, folhas de estilo (CSS), scripts, arquivos de Flash, etc etc.

Cada elemento externo a ser baixado exige a abertura de mais uma conexão HTTP (nem sempre… existe pipelining e outras coisas que melhoram isso, mas pra simplificar, vou ignorar por enquanto). Cada conexão, para ser estabelecida, leva um tempo antes da transferência de dados ser iniciada. Este overhead gera um atraso, visto que muitas vezes, dependendo do tamanho do arquivo, o tempo para se estabelecer a conexão chega a ser maior que o tempo para se baixar o arquivo.

Some-se a isso uma regra que diz que navegadores devem abrir no máximo 2 conexões simultâneas por host. Ou seja, se a página possui 30 elementos externos a serem baixados, as conexões serão estabelecidas duas a duas até que os 30 sejam completados. Algo que se pode fazer para melhorar isto é dividir os elementos externos em alguns hosts diferentes, já que a regra manda 2 conexões por host, mas isto fica para mais adiante.

Muitas vezes, uma página possui vários arquivos CSS e vários scripts em JavaScript. Ao invés de utilizar, digamos, 5 tags para se carregar 5 arquivos CSS diferentes, e mais 10 tags para carregarmos 10 scripts externos, não seria muito melhor se pudéssemos abrir apenas duas conexões, e baixar todo o CSS em uma, e todo o JavaScript em outra? E melhor, que ao fazer isto eles já viessem “condensados”, de forma a diminuir seu tamanho?

Pois bem, a idéia do Minify é justamente fazer isto. O Minify é um script em PHP que recebe uma lista de arquivos como parâmetro (CSS ou JavaScript) e “junta” todos eles em um único download (ele faz mais, mas para mais detalhes, veja direto na página do Minify).

Para fazer a instalação, tudo muito simples. Basta descompactar o arquivo na raiz do site, e fazer algumas modificações nas tags. Ao invés de termos:

<script type="text/javascript" src="/js/script1.js"></script>
<script type="text/javascript" src="/js/script2.js"></script>
<script type="text/javascript" src="/js/script3.js"></script>
<script type="text/javascript" src="/js/script4.js"></script>
<script type="text/javascript" src="/js/script5.js"></script>

passamos a ter somente:

<script type="text/javascript" src="/min/?f=/js/script1.js,/js/script2.js,/js/script3.js,/js/script4.js,/js/script5.js"></script>

Ou seja, chamamos somente o “/min/”, e passamos como parâmetro (chamado f) uma lista com os scripts, separados por vírgulas, e o Minify se encarrega do resto. Com o CSS, a mesma coisa. Ao invés de termos:

<link rel="stylesheet" type="text/css" href="/css/style1.css" />
<link rel="stylesheet" type="text/css" href="/css/style2.css" />
<link rel="stylesheet" type="text/css" href="/css/style3.css" />
<link rel="stylesheet" type="text/css" href="/css/style4.css" />
<link rel="stylesheet" type="text/css" href="/css/style5.css" />

teremos somente:

<link rel="stylesheet" type="text/css" href="/min/?f=/css/style1.css,/css/style2.css,/css/style3.css,/css/style4.css,/css/style5.css" />

Apenas usando o Minify, já podemos conseguir baixar o número de conexões HTTP necessárias para se carregar a página inteira, e com isso, diminuir o tempo total.

Um site interessante, que fornece um mapa com todos os elementos do site, assim como o tempo de carregamento de cada um é o Full Page Test do Pingdom. O tempo de cada elemento é dividido em 3: tempo para se começar, tempo para se estabelecer a conexão e a transferência em si. Olhando bem, dá pra perceber que o tamanho das páginas (parte azul da barra) tem uma influência menor do que o número de conexões.

Existem outras técnicas, que podem ser usadas em conjunto com o Minify para melhorar ainda mais, mas ficarão para os próximos artigos da série.

Artigos relacionados

• Otimização de sites, parte 2 – Compressão
• Otimização de sites, parte 3 – Cache
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Envio de emails em massa
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Evitando SQL injection em PHP
• Otimização: imagens inline
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Precedência no PHP
• Acessando sites fora do ar
• Páginas de manutenção
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

<?php
$a = $expressao1 && $expressao2;
?>

O valor da variável $a será verdadeiro, se tanto $expressao1 e $expressao2 forem simultaneamente verdadeiras, e será falso caso uma das duas seja falsa.

Da mesma forma, temos o operador and, que da mesma forma que o &&, também funciona como um “e” lógico. A diferença está na precedência. O operador && é processado antes de uma atribuição, enquanto que o operador and é processado depois.

Para ilustrar, podemos fazer o seguinte teste:

<?php
$a = true && false;
$b = true and false;
var_dump($a);
var_dump($b);
?>

Se alguem achar que ao executar este código, tanto $a quanto $b valerão false, abra o PHP e execute para tirar a prova. Teremos $a valendo false, e $b valendo true, o que na verdade era de se esperar.

Para $a, o PHP processa a expressão (true && false), e atribui seu resultado (false) a $a. No caso de $b, a atribuição tem precedência, então o PHP processa primeiro a expressão “$b = true”, e depois disso faz o “e lógico” com o false (que dá false, mas não é guardado em lugar algum). Ou seja, a precedência fez a diferença neste caso. Poderíamos escrever o código da seguinte forma, para facilitar o entendimento:

<?php
$a = (true && false);
($b = true) && false;
var_dump($a);
var_dump($b);
?>

E da mesma forma que temos os dois operadores (&& e and), também temos os operadores || e or. A diferença entre os dois é a mesma que no caso do “and”, ou seja, apenas a precedência em relação ao operador de atribuição.

Ilustrando:

<?php
$a = false || true;
$b = false or true;
var_dump($a);
var_dump($b);
?>

Ou seja, da mesma forma que o exemplo anterior, teremos $a valendo true (pois um dos dois valores é verdadeiro), e $b valendo false, pois primeiro é feita a atribuição, e depois processado o “ou”.

Em caso de maiores dúvidas, a seção de operadores lógicos do manual do PHP certamente irá tirar qualquer dúvida.

Para quem pretende estudar para fazer a prova de certificação da Zend, é uma boa saber desses pequenos detalhes, pois a prova tem várias pegadinhas que podem pegar os desavisados.

Artigos relacionados

• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP