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

Como funciona na teoria?

O funcionamento de um CAPTCHA de letras tortas é bem simples. O servidor gera uma string que será transformada em uma imagem. A string é salva em algum lugar (normalmente em uma variável de sessão). A imagem é apresentada dentro de um formulário. Ao submeter o formulário, o script checa se o que o usuário digitou bate com o conteúdo da variável de sessão. Se bater, o usuário passou no teste.
Na teoria, tudo muito simples.

Mas e na prática?

Na prática, tudo também pode ser igualmente simples. Ao invés de reinventar a roda, podemos utilizar uma classe chamada Securimage, que serve justamente para gerar CAPTCHAs.

Securimage

Securimage é uma classe em PHP que utiliza a biblioteca gráfica GD para gerar imagens com CAPTCHAs. A classe é bastante versátil, e suporta várias opções, como fontes TTF, imagens de fundo, linhas, arcos e bem mais.
O primeiro passo é baixar o pacote com a versão mais recente e descompactá-lo em algum lugar. A partir deste ponto, vou assumir que o pacote foi descompactado em uma pasta chamada “securimage” no diretório raiz do site.

Criando o form com a imagem

Dentro do formulário que se deseja proteger, colocamos uma tag img, que irá conter a imagem gerada pelo Securimage:

<img id="captcha" src="/securimage/securimage_show.php" alt="CAPTCHA" />

Este script securimage_show.php é bem pequeno (3 linhas), e irá criar um CAPTCHA com as opções padrões da classe. Veremos mais adiante algumas formas de se customizar a imagem.
Além da imagem, também precisamos de um campo para o usuário digitar as letras contidas na imagem:

<input type="text" name="captcha_txt" />

E com isso o formulário está pronto.

A checagem no backend

O usuário viu a imagem, digitou os dados e submeteu o formulário. Agora é hora de checar se o código digitado bate com o texto contido na imagem.
Logo no início do script que recebe os dados do formulário (em caso de dúvida, veja o atributo action da tag form), é preciso inicializar as variáveis de sessão:

<?php session_start(); ?>

É importante que este código venha antes de qualquer saída, ou teremos um erro do tipo “Cannot modify header information – headers already sent….”. Na dúvida, coloque logo no início.
O restante da checagem é bastante simples. Basta instanciarmos um objeto da classe Securimage e chamar um método que faz a checagem:

<?php
require_once $_SERVER['DOCUMENT_ROOT'] . '/securimage/securimage.php';
$securimage = new Securimage();
 
if ($securimage->check($_POST['captcha_txt'])) {
    // Código digitado corretamente
    die("Ok, o código foi digitado corretamente.");
}
else {
    // Código digitado não bate com a imagem
    die("Erro: código incorreto.");
}
?>

O exemplo acima apenas ilustra como é feita a checagem. As chamadas a die() devem ser substituídas de acordo com a lógica da página onde o CAPTCHA está sendo inserido. No caso do código estar correto, deve-se prosseguir com o processamento do formulário, e caso não esteja, possivelmente exibir novamente o formulário com uma mensagem de erro. Será gerado um novo CAPTCHA automaticamente.

Outras opções

Como dito anteriormente, a classe é bastante versátil, e suporta diversas opções para a geração das imagens. Todas as opções estão descritas na documentação da classe, mas vou transcrever várias das opções aqui.
Para se customizar a imagem, basta editar diretamente o script securimage_show.php, que é o script usado na tag img. Originalmente, ele é apenas o seguinte:

<?php
include 'securimage.php';
$img = new securimage();
 
$img->show();
?>

Podemos passar opções para a classe antes de chamar o método show(). Apenas para ilustrar, aqui vai um exemplo bem customizado:

<?php
include 'securimage.php';
$img = new securimage();
$img->code_length = 8; // 8 ao invés de apenas 4 caracteres
$img->charset = "AEIOU"; // Apenas vogais
$img->image_width = 280; // Padrão é 175px para 4 caracteres
$img->multi_text_color = "#ff0000,#0000ff"; // Letras azuis e vermelhas
$img->image_bg_color = "#ffff00"; // Fundo amarelo
$img->show();
?>

E abaixo, 3 exemplos de CAPTCHAs gerados por este script:

Como já dito, a classe suporta muitas outras opções, o melhor mesmo é ler a documentação caso se deseje customizar mais.

Artigos relacionados

• Evitando SQL injection em PHP
• Os 10 piores CAPTCHAs do mundo
• Segurança no envio de emails em PHP
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Evitando spam em formulários
• 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

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