Este estudo é feito sobre um trabalho de consultoria que realizei num website baseado em Joomla! versão 2.5, mas boa parte das informações aqui existentes (senão todas) poderão ser usadas para outros CMS’s e websites.

Cenário de pré-otimização

Um dos proprietários do portal de notícias Radar do Futuro me contatou pois o website estava com tempos de resposta extremamente altos, chegando em vários momentos a atingir 30 segundos para carregar e renderizar a página principal.

E as verificações iniciais confirmaram o problema. Em diversas sequências de testes com a ferramenta Webpagetest, a média de tempo de carga ficou em torno de 20 segundos. Para um site pouco complexo, algo estava errado pois mesmo estando hospedado num datacenter já conhecido por dar trabalho aos desenvolvedores, o tempo era extremamente alto. Além disso, a ferramenta YSlow confirmava com um nível de performance “D” (A – melhor, E – pior) os problemas e a ferramenta PageSpeed apresentava uma pontuação de 66 pontos em 100 possíveis.

Olhando um pouco abaixo da superfície para traçar uma linha de trabalho e reduzir este tempo, as primeiras conclusões foram:

1. A página principal carregava mais de 1.2MB de dados; imagens, conteúdo, scripts, etc. Um valor que precisava ser reduzido rapidamente;
2. Falta de compactação de arquivos. Além desse problema, as opções de compressão de conteúdo não estavam ativadas e tampouco os caches corretamente configurados;
3. Excessivo número de requisições para arquivos JavaScript e CSS;
4. Configurações equivocadas dentro do CMS

Com estes quatro principais pontos já descritos, começaram os trabalhos de otimização na sequência que estão aqui listados. É interessante entender a lógica dessa sequência pois ela impacta não somente no tempo dispendido nas tarefas de otimização, mas também na redução de re-trabalho futuro.

Redução do tamanho da página

Ao contrário que pode imaginar, as dimensões da página não foram modificadas, mas sim, seu “peso” total, ou seja, o primeiro passo era reduzir o tamanho total dos elementos carregados para depois poder afinar (ou fazer um tuning) a resposta.

[media-credit id=2 align="aligncenter" width="650"][/media-credit]Os principais elementos que dão peso em uma página são: arquivos flash, imagens, scripts JavaScript e arquivos CSS. Destes, somente arquivos flash não estavam presentes nativamente (mas aparecem esporadicamente como anúncios), e os outros, em números excessivos e grandes, principalmente arquivos JavaScript que ultrapassavam inclusive em bytes as imagens.

O primeiro passo foi concentrar esforços nas imagens. Elas foram otimizadas em seus tamanhos com as ferramentas online PunyPNG e Image Optimizer e algumas, principalmente aquelas pertencentes ao slideshow, redimensionadas para o tamanho máximo da largura da área que ocupam. Isso evitaria que o navegador fizesse o redimensionamento de uma imagem grande para uma menor a fim de colocar dentro do espaço disponível e ganharia-se em tempo de carga e redução do peso da página. Infelizmente a extensão utilizada não faz esta simples, mas importante tarefa dentro do CMS, como existe dentro do CMS Drupal. Além disso, claro, o cliente não sabia desta situação (mas foi devidamente informado no relatório final).

Após os trabalhos nas imagens, o próximo passo foi focado nos arquivos JavaScript, principalmente para tentar entender porque estavam sendo carregados mais de meio megabyte de texto (não se esqueça, arquivos JavaScript são textos). A resposta veio com a investigação do source code da página principal onde era possível ver duas ou mais cargas de um mesmo script realizadas por diferentes extensões, problema este que poderia ser evitado pelos programadores das extensões realizado uma simples verificação se determinado script já está carregado (jQuery, MooTools e outros ditos pesados) e não chamá-los novamente se a resposta for positiva.

Por não existir uma forma de “desabilitar” a carga dos arquivos via um hook como existe no WordPress (eu pelo menos desconheço, se alguém souber, por favor, deixe um comentário), foram realizadas modificações dentro das extensões para que estes arquivos não fossem carregados em duplicidade e as chamadas transferidas para o template com condicionais. Mesmo não sendo uma opção elegante, foi a melhor encontrada para reduzir o tempo de carga. Conjuntamente, todos os arquivos JavaScript foram otimizados com a ferramenta PageSpeed para a remoção de comentários e outros caracteres não necessários.

Logo após, foi a vez dos arquivos CSS que sofriam problema similar aos arquivos JavaScript; chamadas desnecessárias e arquivos necessitando serem compactados. Além destas tarefas, boa parte deles foram eliminados e seus conteúdos colocados em um único arquivo para reduzir a quantidade de requisições no final (o mesmo foi realizado com boa parte do arquivos JavaScript).

Nesta etapa também foi ativada a compactação gzip de arquivos (mediante configuração no arquivo .htaccess) e o sistema de cache sintonizado, pois existem dois disponíveis: um do próprio CMS e outro do tema. O resultado deste trabalho inicial pode ser visto na imagem a seguir:

Sim, uma redução de 761Kbyes na página principal. Além disso, o número de requisições caiu, principalmente com o cache ativo.

Configuração do CMS

Otimização não é somente reduzir o tamanho de uma página ou ficar espremendo arquivos. Existe muito mais e uma das atividades que impactam fortemente é a correta configuração da ferramenta que está sendo usada. Numa analogia, de nada adianta ter um carro turbinado se não existe uma mínima regulagem do sistema de injeção. Tal qual um motor, um website é composto de várias partes que precisam trabalhar em harmonia para chegar no objetivo que é… correr!

Extensões e módulos habilitados e não usados, consomem recursos da ferramenta, seja em Joomla!, seja em Drupal ou WordPress. Um mísero byte que esteja lá e que não deveria estar pode ajudar a reduzir a velocidade de carga. Lembre-se que estamos falando de milissegundos.

Neste caso existiam diversos módulos e extensões órfãs dentro do CMS que foram desabilitados e/ou removidas, ajudando sensivelmente o front-end mas também o back-end do sistema (que não era foco do trabalho mas ganhou um extra). Diversos editores de texto, marcadores, módulos pessoais e até mesmo extensões não mais usadas foram removidas para aliviar a carga do CMS quando ele precisa processar requisições, sejam estas vinda de usuários que acessam as páginas, como também daqueles que inserem conteúdo no sistema.

Logo após, verificando as demais áreas, foram encontrados erros de configuração no template que contribuíam com os problemas de performance. Nesta etapa, bom senso e um pouco de leitura do código do template utilizado ajudaram a reduzir mais alguns décimos a resposta para o usuário.

Cenário de pós-otimização

Após o término dos trabalhos, uma verificação final para obter os valores atuais:

Opa, parece que alguma coisa está errada. 13,8 segundos para a primeira carga? Por quê? E a segunda dentro de um tempo esperado?

Se forem observadas as duas tabelas, encontra-se facilmente o problema: o tempo que o servidor começa a responder as requisições. Na primeira carga ele responde após 7 segundos e na segunda, após 1.38 segundos, o que é uma diferença e tanto e que impacta diretamente na performance do website.

Com uma curiosidade imensa para tirar a prova dos nove, fiz uma cópia de todo o website em meu servidor nos Estados Unidos e refiz os testes. O resultado foi o seguinte então:

Com a simples troca de servidor (e datacenter), o tempo de resposta caiu de 7.1 segundos para 0,4 segundos, confirmando as suspeitas do datacenter nacional.

Datacenters

Com dito anteriormente, otimização não é somente um trabalho no website. É preciso que vários elementos estejam em harmonia para que possam ser atingidas boas experiências de navegação e carga pelo usuário. Uma dessas peças são os servidores, tanto de bases de dados quanto de HTTP. Se o website está hospedado em um servidor de baixa performance ou sobrecarregado, não existe otimização no website que resolva o problema. Ele pode ser minimizado mas não solucionado a bom termo.

Normalmente hospedar websites em servidores que compartilham espaço, processamento e banda com outros websites, apresentam este tipo de problema. Para maximizar o investimento em hardware, são colocados 100, 200, 500 clientes em uma única máquina e qualquer deslize de um desses clientes com uma configuração, afeta todos os demais. Outro problema enfrentado é que, na grande maioria dos datacenters, quando um website é hospedado neste modelo de compartilhamento, não é possível realizar configurações para afinar os serviços de bancos de dados e aplicação web (como foi este caso) pois você estaria mexendo nas configurações de outros websites. Então é feita uma configuração padrão e você tem que se adequar a mesma.

Conclusões

Diante do cenário apresentado e dos resultados, foi indicada a mudança de datacenter para reduzir ainda mais o tempo de resposta do website. Outras abordagens ainda poderiam ser tomadas para reduzir o tempo final, como a distribuição de conteúdo estatíco por domínios diferentes e o uso de CDN’s. Entretanto estas abordagens são mais demoradas pois requerem profundas mudanças no website e são custosas pelo pagamento do serviço de CDN mensalmente e pelo tempo de trabalho que deverá ser dedicado para estas tarefas.

Para websites pequenos, institucionais ou que não é o negócio da pessoa/empresa, o uso destas opções extrapola a relação custo/benefício. Já para empresas grandes, e-commerces e websites de alto tráfego, são essenciais. Porém, mesmo não utilizando-as, é possível fazer muito pelo website, principalmente nos seguintes pontos:

• cuidado com as imagens que coloca em seu website – é muito bom passar numa ferramenta de busca, achar uma imagem interessante e colocar no site. Mas quanto esta imagem está trazendo de carga? Será que ela está otimizada? Sempre otimize imagens e sempre utilize as imagens do tamanho correto para o espaço que tem. Isso faz com que o navegador não perca tempo renderizando as imagens;
• cuidado com CSS – ferramentas de desenvolvimento rápido (RAD) são grandes criadoras de excesso de bytes. Um código CSS limpo (e depois compactado) traz um resultado surpreendente. Dividir o CSS também é uma técnica válida; um menor para a página principal com somente aquelas classes e identificadores que são usados nela e outro para ser carregado nas outras páginas. Mas tenha ciência que esta não é uma tarefa fácil pois requer um pouco de programação no CMS.
• cuidado com extensões, plugins, módulos e outras coisas adicionais – se você usa um CMS, elimine completamente tudo aquilo que você não usa. Com isso, além de desafogar o CMS, remove brechas de segurança que aquele plugin esquecido no canto possa ter.

Além disso tudo, otimização é uma arte e tarefa diária. Cada post, cada comentário, cada imagem pode aumentar ou reduzir o tempo de resposta de seu website. É importante frisar que pesquisas realizadas com usuários de Internet indicam que os dez primeiros segundos de acesso em um website são aqueles que definem se o internauta vai ficar ou vai procurar outro. Ou seja, se seu website levar dez segundos para estar na tela do computador, você perdeu o internauta.

A otimização não é só importante para isso. Os sistemas de busca há algum tempo punem negativamente websites lentos. Com isso, mesmo que você tenha um bom conteúdo hospedado numa carroça, será difícil chegar num bom patamar de posicionamento dentro do Google, Yahoo! ou Bing.

Caso queira maiores informações sobre este projeto ou para seu website, entre em contato clicando aqui. Comentários? Sempre bem vindos! Utilize o formulário abaixo e deixe sua opinião.

Um dos maiores blog’s sobre comunidades open source do mundo também noticiou a migração do site da USP para Joomla!. A matéria pode ser lida clicando-se aqui.

A matéria completa pode ser lida clicando-se aqui.

229 cursos distribuídos em 40 unidades, 5 mil professores e 56 mil alunos fazem da USP – Universidade de São Paulo a número um na América Latina e umas das cem mais importantes do mundo. Desde 1997 na Internet, a universidade promoveu durante o ano passado uma pesquisa entre os visitantes do Portal USP (www.usp.br) para adequar seu portão de entrada aos anseios e demandas de seus usuários, tanto nacionais quando do exterior. O resultado foi a mudança do Portal USP e a criação de três outros sites que englobam um novo sistema de navegação entre as páginas, canais de notícias e eventos, mapas das unidades, informações para estrangeiros e também um novo design com o intuito de atender aqueles que visitam um dos sites mais acessados mundialmente no setor.

Para suportar a enorme demanda de requisições, esta nova versão foi desenvolvida sobre a plataforma livre de CMS (Content Management System) Joomla!, que aliando a facilidade de inclusão e gerenciamento de conteúdo com a performance e estabilidade requeridas pela instituição, atende os mais altos padrões exigidos pelo Grupo Gestor do Portal da USP, oferecendo ao público em geral acesso à toda a produção científica, cultural e tecnológica gerada pela universidade, bem como apresentar a instituição nacional e internacionalmente.

Contando com o auxílio de um consultor externo, o projeto de estruturação do portal demandou centenas de horas de trabalho da equipe do USP Online, departamento responsável pelo portal da universidade para a criação de um novo projeto gráfico, estudo de componentes e ferramentas usadas, bem como a migração de dados e informações existentes no antigo portal. Depois de várias pesquisas entre ferramentas livre de gestão, optou-se pelo CMS Joomla! principalmente por sua fácil integração das informações já existentes, pouca manutenção e facilidade de uso, quesitos básicos para o gerenciamento de um universo tão grande de informações.

Para conhecer o novo portal da USP, acesse http://www.usp.br Comentários sobre o mesmo são bem-vindos!

Este trabalho consistiu em:

• Pesquisa de ferramentas e suas versões de acordo com os critérios estabelecidos pela universidade;
• Adaptação de layout gráfico criado na instituição para um tema (template) Joomla!
• Implantação, customização (hacking), migração de dados e treinamento dos usuários;
• Consultoria técnica em administração, manutenção e segurança do CMS.

O design gráfico ficou a cargo do USP Online, departamento responsável pelo site da universidade e foi criado pelo seu principal designer, George Campos com o qual trabalhei constantemente durante duas semanas para atender o prazo estipulado pelo Comitê Gestor do Portal USP.

Como resultado, em 28/02/08 o novo portal entrou no ar no lugar daquele que já possuía quase quatro anos em funcionamento e as mudanças podem ser vistas nas imagens abaixo.

O website antigo da USP

O novo website

Alguns dados técnicos sobre o novo portal:

• Ferramenta de CMS utilizada: Joomla versão 1.5.x
• Número de registros importados: 4500
• Número de usuários com nível de edição (editores, administradores, etc): 14
• Número de conteúdos estáticos: 140
• Número de conteúdos dinâmicos: 8 por dia

Repercussão:

O novo website da USP foi bem aceito mundialmente e referenciado nos seguintes sites:

• Joomla.org – Website oficial do projeto Joomla!;
• CMS Report – Website especializado em notícias sobre ferramentas de gestão de conteúdo;
• OpenSource Community – Website de notícias sobre a comunidade Open Source mundial, em especial ferramentas de CMS;
• Br-Linux – O maior portal de notícias sobre tecnologia livre do Brasil;
• Joomla Clube – Portal brasileiro de usuários Joomla!