Este é o segundo artigo com informações sobre o novo tema do blog, o dpw2014; dando continuidade ao primeiro, este é focado, especificamente, em desempenho/performance. Lembrando que o objetivo de tanta “meta informação” é, claro, ajudar: o fato de explicar e mostrar quais tecnologias/métodos foram (e estão sendo) usados nesta nova versão podem servir de inspiração e/ou fonte de novos conhecimentos para muitos. E esperamos que seja assim, mesmo!
Notas preliminares sobre performance
Já há alguns anos, mesmo antes de os maninhos se juntarem na webfatorial, havia começado a ter preocupações sobre performance/desempenho em desenvolvimento web. Foi a época em que tive contato com as primeiras leituras sobre o tema, principalmente através de materiais diversos de Steve Souders; as famosas dicas do Yahoo! sobre performance (na época, já que não existia Google Chrome, o YSlow era muito usado); depois disso aprendendo, também, ao estudar o HTML5 Boilerplate; daí surgiram outros recursos, como PageSpeed Tools e; sempre lendo muitos artigos em blogs de “pessoas comuns” (que, particularmente, até hoje, mesmo depois depois da morte do Google Reader, ainda gosto mais do que os “famosos”).
Dessas épocas passadas do desenvolvimento web até os dias de hoje, muita coisa foi sendo descoberta, tecnologias evoluíram, novas técnicas surgiram e – mesmo com termos como FEO, TTI e outros, vindos diretamente das profundezas do narcisismo das minorias – melhorar o desempenho, velocidade real e percepção de velocidade de carregamento, ainda continua sendo algo divertido! :-)
Algo que os mais sensatos costumam dizer e a experiência comprova, é que não é possível aplicar todas as melhores técnicas ao mesmo tempo. Todas as dicas de implementação, descobertas e aperfeiçoamentos sobre performance devem ser encaradas como diretivas de aperfeiçoamento de desempenho de projetos web (algumas são mais complexas de implementar, claro), não como leis divinas que condenam ao sofrimento eterno aqueles que não as utilizam.
Então, mesmo que você conheça absolutamente todas as técnicas e saiba sobre configurações dos diferentes ambientes de desenvolvimento possíveis, será impossível aplicar tudo. Como exemplo, imagine que uma técnica que vai beneficiar muito a parte de SEO do site vá de encontro a algo que esteja melhorando um pouco o desempenho atual e que uma seja conflitante com a outra. Qual vai você vai escolher usar? Esse tipo de custo de oportunidade estará presente em qualquer projeto web (não somente quando o assunto é desempenho/performance).
Tecnologias e técnicas
Incrementar a performance de um site não é tarefa feita num só dia, seguindo uma “receita de bolo” qualquer; trata-se de um processo multidisciplinar. A seguir, algumas considerações gerais (nem tão cronológicas) sobre este processo aqui no desenvolvimento para web.
Ordem de atuação?
Como os que leram os “livros-base” sobre performance sabemos, cerca de 80%~85% da performance de um site pode ficar por conta do front-end. Então, geralmente é mais sensato começar a se preocupar com “gargalos” em configurações de servidor e códigos back-end depois de já ter feito esforços para diminuir o número de requisições HTTP; dar preferência a estilos e scripts externos (posicionando-os corretamente na estrutura do documento); otimizar imagens; enfim. Depois disso, sim, começar a verificar se o Gzip está habilitado (e se o nível de compressão está adequado ao projeto); configurar a expiração de assets; melhorar o tempo de resposta do servidor etc.
Evidentemente que tais diretrizes pressupõem um código back-end minimamente aceitável, com preocupação no uso de recursos, sem repetições e uso de recursos não-essenciais, sem “gargalos” de desempenho com loops e condicionais desnecessários, baixa complexidade ciclomática etc.
Seria impossível estipular uma ordem “correta” para a aplicação disso, mas, na prática, dependendo de quantas pessoas trabalham no projeto simultaneamente, (geralmente) essa “ordem” pode ser ignorada e o processo de otimizar acontecer nas várias “frentes” do desenvolvimento web ao mesmo tempo. Sendo este o caso ou não (um trabalho solo), o gosto, temperamento, disposição pessoal, identificação com o projeto e disponibilidade do(s) envolvido(s) são fatores que sempre influenciam. Estamos falando de seres-humanos, certo? :-)
WordPress
No caso específico do dpw2014, já que se usa WordPress, a maior parte do back-end já estava pronta e a estendemos com o uso de plugins (alguns desenvolvidos “em casa” e brevemente disponibilizados para a comunidade) e funções específicas.
Relevante a desempenho, estamos usando, no momento:
Como curiosidade, no quadro de plugins também é possível encontrar:
- Akismet (mesmo sem form, algun bots conseguem comentar)
- Google XML Sitemaps
- JSON API
- Similar Posts (com o necessário Post-Plugin Library)
- WordPress Helper Functions (brevemente será liberado para a comunidade)
- WordPress SEO
- WP-Syntax
Na antiga versão do blog, estava sendo usado para a exibição de códigos-fonte o Crayon Syntax Highlighter, mas resolvemos alterá-lo para algum mais leve e com visual mais limpo (embora o Crayon tivesse muitas opções de visual, também); dentre os vários disponíveis, escolhemos o WP-Syntax, que foi escolhido devido à implementação semelhante (o que, praticamente, não requer maiores cuidados com posts já publicados).
Para ajudar com o SEO, na versão passada era o Platinum SEO Pack, mas, numa revisão geral que foi feita, o WordPress SEO se mostrou muito mais eficiente nas áreas consideradas relevantes ao blog.
Em algum momento se pensou em usar alguma solução como o Plugin Organizer, mas provavelmente seria mais complicado se valer dos benefícios do W3 Total Cache e, dentro das necessidades do projeto, ele não se fez necessário.
Ademais, alguns outros plugins (que não precisam ser citados) também estão rodando. Outro detalhe: na versão anterior, havia muitos plugin desabilitados, mas ainda constando no painel para fins de referência. Como reza a lenda que até isso pode influenciar um pouco na performance (ao acessar o Painel, com certeza), estes foram sumariamente excluídos.
Hospedagem e servidor
Há anos usamos os serviços da Dreamhost, mas, ultimamente, estamos começando a pesquisar e testar outros – não por ter muitas insatisfações com o primeiro (que possui ótimo custo-benefício, por sinal), mas para explorar novas possibilidades, mesmo – e, para o teste da nova versão do desenvolvimento para web, escolhemos começar com a DigitalOcean.
Indiscutivelmente, um plano não-compartilhado possui inúmeros benefícios, dentre os quais um dos melhores é a total liberdade de configuração do servidor – e, neste caso, uma configuração de hardware melhor (memória, processamento, armazenamento SSD e outros pormenores). E pelo preço de um cafezinho! ;-)
Em função disso, optamos também por trocar de servidor. Dentre as “alternativas” ao Apache mais populares, ficamos com o Nginx. Nginx merece um artigo à parte (e, de fato, há planos para esta publicação), mas, grosso modo, ele existe para ser um servidor HTTP e/ou proxy reverso de alto desempenho. E preste atenção no termo alto desempenho!
Para a maioria de nós, acostumados com o bom e velho Apache, muita coisa muda, especialmente em relação à integração com PHP e maneira como o Nginx é configurado. Entretanto, não é nenhum bicho-de-sete-cabeças e, com alguns poucos dias de estudo, já é possível ter um servidor Nginx rodando o WordPress.
Foi surpreendente a diferença de desempenho logo ao rodar o WordPress, sem quaisquer configurações adicionais: parecia que o plugin de cache já estava habilitado! Em vários aspectos, a DigitalOcean está passando em nossos testes pessoais (e com louvor)! Vamos deixando por aqui para ver no que dá; tudo indica que não teremos decepções.
Análises e estatísticas
Para finalizar, deixamos os números atuais do desenvolvimento para web em algumas das ferramentas mais usadas para mensuração de performance. Claro que ainda há o que ser feito e estes não são os últimos resultados que serão alcançados, mas uma das maiores belezas do desenvolvimento web é que tudo evolui!
GTmetrix
Os atuais resultados no GTmetrix (que usa regras do PageSpeed e YSlow para análise) estão excelentes! Tirando recursos externos, que impossibilitam determinados tipos de otimização (e, via de regra, penalisa a pontuação em ferramentas de análise deste tipo), tudo está dentro dos conformes.
Felizmente, conseguimos Grade A em ambas as principais análises (ficando quase 20% acima da média).
Pingdom
No Pingdom, somente em 4 quesitos não conseguimos a pontuação máxima (estamos trabalhando nisso), ficando, no total, com 94/100 (87% mais rápido que a média).
WebPagetest
Outra ferramenta muito interessante é a WebPagetest, na qual não foi possível obter a classificação máxima no resultado em função do não cacheamento de scripts externos e por, no momento, não estarmos fazendo o uso de CDN.
Eis um vídeo do carregamento da página deste artigo que você está lendo agora gerado pela ferramenta, numa configuração que não deve fugir muito de um suposto mínimo usado pelo público do blog (Test Location: São Paulo; Browser: Chrome; Connection: Cable (5/1 Mbps 28ms RTT)) num acesso repetido (que, esperamos, seja seu caso):
Conclusão
Como é comum se dizer na área de otimização, performance é um processo. Então, para o atual momento do desenvolvimento para web, levando em consideração este processo, o resultado geral está bem melhor que a versão anterior.
E melhorar a si mesmo é, indubitavelmente, um sinal de progresso!