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

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

A página, normalmente bem simples, informa ao visitante que o site está passando por problemas temporários, ou está em manutenção, e que voltará em breve.

Porém, uma coisa frequentemente ignorada é o que os buscadores percebem quando encontram uma página dessas. Ao chegar na página principal do seu site e se deparar com uma página dizendo que o site está temporariamente fora do ar, se os devidos cuidados não forem tomados, o robô irá indexar a página, e passará a figurar nas buscas.

Ou seja, ao invés de ter o conteúdo real da página no índice do buscador, teremos o conteúdo da página de erro, o que definitivamente não é o que desejamos.

Como fazer pra que isso não ocorra?

Pra falar a verdade, a resposta é bem simples: enviando o status HTTP adequado para as páginas de erro. Da mesma forma que uma página não encontrada gera um erro 404, uma página indisponível deve gerar um erro 503, informando ao buscador ou cliente que a página é um erro temporário.

Isto pode ser feito em qualquer linguagem de programação, bastando alterar os cabeçalhos enviados. Em PHP, ficaria assim:

<?php
header("HTTP/1.1 503 Service Unavailable")/
header("Retry-After: 60");
?>

Para alterar para outra linguagem, basta pesquisar como se enviar cabeçalhos HTTP. Todas as linguagens de programação disponibilizam uma forma de se fazer isso.

A primeira linha informa o código de erro 503, que o navegador ou buscador irá interpretar como um erro temporário no servidor, e não como uma resposta normal (código 200).

Já a segunda, informa em quanto tempo, em segundos, o cliente deve retornar a página para ter o conteúdo real. Este cabeçalho é opcional, mas se dá pra se estimar o tempo necessário para que o erro seja sanado, é uma boa idéia colocá-lo. No caso, estou informando ao cliente que a página estará de volta em 1 minuto.

O mais importante, no caso, é que um buscador não irá indexar uma página com erro 503.

O W3C possui uma página com a explicação detalhada de todos os erros HTTP.

Artigos relacionados

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