Otimize seu site com páginas de erro personalizadas

Muitas são as razões pelas quais as pessoas resolvem abrir um blog ou disponibilizar um site na Internet. Diversos são os níveis de conhecimento técnico das pessoas que mantêm websites funcionando, e é comum que esse conhecimento venha a ser construído diariamente, à medida que as necessidades vão surgindo. E, acrescento, creio que esta seja a melhor e mais saudável maneira de aprender (acreditem ou não, estudei para ser professor, e na faculdade eu era fanboy do Jean Piaget e do Lev Vygotsky, considerados os "pais" do Construtivismo - link para a Wikipedia).

O caminho natural (e aqui não faço nenhum juízo de valor) de quem pouco ou nada sabe acerca de publicação de sites na Internet é experimentar-se em plataformas fechadas e prontas, como o Google Blogspot, ou o WordPress.com; algumas pessoas se decepcionam com as limitações que esses serviços apresentam, nada obstante sua excelência, e resolvem contratar uma hospedagem e ter suas próprias instalações do WordPress ou qualquer outro gerenciador de conteúdo, em seu próprio domínio. É para esses que escrevo esse pequeno e simples tutorial.

Dada minha experiência vendendo hospedagem de sites, bem como a minha própria experiência como usuário de serviços de hospedagem, posso dizer sem medo de errar que a maioria esmagadora dos donos e mantenedores de sites raramente personalizam as configurações de seus sites: utilizam todas as configurações padronizadas que a hospedagem oferece, instalam seu CMS preferido (na maior parte das vezes o WordPress) e o máximo de modificações que fazem são nos arquivos dos temas, ou seja, para modificar a aparência do site. Muito raros são os que mexem nas configurações menos óbvias, configurações estas que muitas vezes podem significar um enorme ganho de performance para o servidor.

Uma das configurações mais simples de fazer, mais eficientes e mais ignoradas é a de páginas de erro personalizadas. Explico.

Quando alguém instala o WordPress na raiz de um domínio, ele passa a gerenciar todas as requisições que são feitas a qualquer recurso do domínio, devido às URLs amigáveis. O Drupal também tem essa característica, e imagino que qualquer CMS que se preze também terá. Por um lado é excelente, porque o WordPress passa a gerenciar todas as requisições de arquivo, e quando alguém solicitar algo que não exista no servidor nem seja um artigo, o WordPress exibirá a página de erro 404 padrão, definida pelo arquivo 404.php no diretório do tema utilizado. Por outro lado é péssimo, exatamente pelo mesmo motivo: quando algum recurso é solicitado, como uma imagem ou um MP3 que foram propositalmente excluídos do servidor, todo o core do WordPress deverá ser carregado e interpretado apenas para exibir uma página de erro, que nem mesmo poderia ter anúncios do AdSense, ou seja, para o dono do site uma página bem inútil.

O problema fica potencializado se pensarmos que o Googlebot de algumas semanas para cá anda indexando muito mais rapida e freqüentemente os sites com histórico de atualização rápida (como costumam ser os blogs), e que uma passadinha dele pode significar centenas ou milhares de requisições a cada poucos segundos: cada requisição dessas sobrecarregará todo o sistema ao exigir que todo o WordPress (ou outro CMS, refiro-me ao WP apenas por ele ser o mais comum do meu universo) seja todo carregado e interpretado pelo Apache e pelo PHP. Ah, claro, nem só de Googlebot vive a indexação de um site, o que implica que o problema demanda ainda mais atenção.

Basicamente, creio que podemos fazer uma grande economia de recursos ao livrar o WP de gerenciar páginas 404 relativas a arquivos de imagem, folhas de estilo e Javascripts externos. Isso pode ser obtido facilmente acrescentando umas poucas linhas ao arquivo .htaccess padrão do WP.

O arquivo .htaccess padrão do WordPress costuma ter o seguinte conteúdo:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

Em resumo esse conjunto de regras instrui o Apache a submeter toda e qualquer requisição ao index.php (o WP), contanto que não exista um arquivo (!-f) ou diretório (!-d) com o mesmo nome. Para resolver nosso problema vamos criar uma página estática de erro e acrescentar duas regrinhas ao .htaccess para que arquivos com a extensão especificada não sejam interpretados pelo WP.

Usuários de hospedagens com cPanel (como os meus clientes) podem criar páginas de erro personalizadas pelo próprio painel de controle do domínio, e ele criará páginas com o nome 404.shtml, 500.shtml, etc, na raiz do site. Pode ser útil pela praticidade editar as páginas de erro pelo cPanel.

Suponhamos que a sua página estática de erro tenha sido criada e salva com o nome de arquivo "404.html".

A primeira coisa a fazer é acrescentar no início do .htacess a regra que dirá que arquivos com as extensões que desejamos que não existam devem ser substituídos pelo nosso arquivo:

<FilesMatch "\.(gif|jpe?g|png|s?html|css|js|cgi)$">

ErrorDocument 404 /404.html

</FilesMatch>

Quase pronto. Agora vamos dizer ao Apache para não incluir arquivos com as extensões acima na super-regra ultra-simples que faz com que qualquer arquivo tente ser tratado pelo WP, imediatamente após as regras padrão do WP:

RewriteCond %{REQUEST_FILENAME} !\.(gif|jpe?g|s?html|css|js|cgi)$

O arquivo .htacces devidamente modificado, então, vai ficar assim:

<FilesMatch "\.(gif|jpe?g|png|s?html|css|js|cgi)$">

ErrorDocument 404 /404.html

</FilesMatch>

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !\.(gif|jpe?g|s?html|css|js|cgi)$

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

Note que ao efetuar uma atualização pelo Fantastico (ou seja lá qual for o instalador automático de programas da sua hospedagem) as modificações acima podem ser perdidas. Convém, portanto, fazer um backup do seu .htaccess para o caso de algum incidente.

Se você tiver seu site em um servidor dedicado poderá fazer as alterações acima diretamente no httpd.conf (o arquivo de configuração do Apache), pois o .htaccess é considerado um gargalo de processamento. Seja como for, é muito mais "econômico" usar o .htaccess da maneira que proponho do que deixar o WP lidar com toda e qualquer página de erro 404.

Atualização: esqueci de citar a referência para este artigo: http://drupal.org/node/56773