Ei, aventureiro do mundo web! Se você está aqui, provavelmente sabe como é difícil atingir aquela pontuação perfeita no Google Lighthouse. Vou te contar como consegui esse feito e otimizei o meu site. Se prepare, porque isso é conteúdo avançado!
Antes de embarcar nessa jornada de otimização, estávamos utilizando WordPress. Embora seja uma plataforma incrível, não tínhamos nenhum especialista em WordPress conosco. Mesmo contando com ferramentas como o Elementor e diversos plugins de cache, a verdade é que dominar sua otimização parecia uma tarefa hercúlea. Era como tentar escalar uma montanha sem o equipamento certo.
Então, nos voltamos para a infraestrutura. Se quiséssemos ter controle total sobre nosso site, precisaríamos começar pela base. Foi quando o Docker chamou nossa atenção. Esse incrível recurso nos proporcionou um ambiente controlado, consistente e, o melhor de tudo, fácil de replicar. Isso significava que, não importava onde estivéssemos rodando o site - no meu PC ou em um servidor remoto -, o comportamento seria sempre o mesmo. E, sinceramente? Nada supera a paz de espírito de saber que não haverá surpresas desagradáveis por conta de diferenças de ambiente!
O Jekyll se apresentou como uma solução brilhante para quem, como eu, queria se libertar da complexidade das bases de dados e servidores de aplicação. Mas, para mergulhar de verdade nesse universo, é essencial ter um bom domínio de HTML e CSS. Ou seja, é indispensável ser um programador front-end. E ainda que o Jekyll seja simples e poderoso, nem tudo foi um mar de rosas. Me deparei com vários plugins que, infelizmente, mais atrapalharam do que ajudaram. Muitos dos plugins do Jekyll que tentei usar simplesmente não funcionavam corretamente ou causavam problemas inesperados, comprometendo a integridade do site.
Aqui entra uma reviravolta interessante: como eu não tinha experiência com Ruby, a linguagem em que muitos desses plugins são escritos, precisei buscar ajuda. E foi aí que o ChatGPT se tornou meu aliado. Mesmo sem entender nada de Ruby, com a ajuda do ChatGPT, consegui navegar por esses desafios e criar soluções personalizadas para o meu site.
Apesar dos obstáculos, o resultado valeu a pena. Ao integrar o Jekyll com Docker, alcancei um setup incrível. Em vez de regerar o site a cada visita, ele é construído uma única vez e, em seguida, é servido de maneira veloz para qualquer visitante, em qualquer canto do mundo. Um blog estático é leve, rápido e, mesmo com as adversidades, descobri que é surpreendentemente flexível.
Revitalizar um site é uma tarefa complexa e muitas vezes desafiadora. Não se trata apenas de dar um novo visual, mas de entender o que já funciona bem e o que precisa ser reformulado. A chave é preservar o que é valioso e eliminar o que não acrescenta valor.
Em minha pós-graduação, tive a oportunidade de aprender a usar o SEMrush, uma ferramenta de SEO impressionante, embora tenha um custo um pouco salgado. Foi graças a ele que pude mergulhar profundamente nas métricas do meu site e analisar o desempenho de cada uma das mais de 400 postagens que possuía. O que descobri foi surpreendente: 380 desses posts não tinham recebido um único acesso! Isso me fez perceber a importância de focar na qualidade e relevância, e não apenas na quantidade.
Com essa informação em mãos, decidi concentrar meus esforços nas páginas importantes que realmente atraíam tráfego e tinham bom posicionamento no Google. Dediquei tempo para identificar e recriar essas páginas no novo formato do site, garantindo que o conteúdo de qualidade que elas continham não se perdesse durante o processo de migração. Esta decisão não apenas otimizou a experiência do usuário, mas também assegurou que o site mantivesse sua relevância nos motores de busca.
Não se engane, as URLs antigas ainda têm valor, principalmente se estiverem bem posicionadas nos motores de busca. Para garantir que não perdesse esse tráfego, utilizei o poder do redirecionamento 301. Ele indica aos motores de busca que a página foi movida permanentemente para um novo endereço. Assim, ao invés de encontrar um erro, o visitante é direcionado suavemente para o novo conteúdo. E o melhor de tudo, o SEO não é prejudicado!
Quando começamos a pensar em design e responsividade, o Bootstrap surge quase que imediatamente em nossas mentes. E não é à toa! Ele é, sem dúvida, uma das frameworks mais populares e eficientes para desenvolver sites responsivos. Então, fazia sentido que eu o escolhesse para o meu projeto.
Ao longo dos anos, percebi que o Bootstrap não só oferece uma variedade incrível de componentes, mas também permite que tenhamos um layout coeso em diferentes dispositivos. Além disso, a comunidade por trás dessa framework é incrivelmente ativa, o que significa uma tonelada de recursos, tutoriais e soluções para possíveis problemas. A escolha pareceu óbvia e não me arrependo nem por um segundo!
Mas, como tudo tem seu lado ruim, tive alguns problemas com o Bootstrap. Um deles foi a quantidade de JavaScript que veio acoplada. Não me entenda mal, o JS do Bootstrap é excelente, mas nem sempre precisamos de tudo. Decidi mergulhar no código e remover aquilo que era desnecessário para o meu site, garantindo assim uma performance ainda melhor. O resultado? Um site mais enxuto e rápido, sem perder a beleza e funcionalidade que o Bootstrap oferece.
Imagens são essenciais em qualquer site. Elas dão vida, cor e contexto. Mas elas também podem ser um dos maiores empecilhos quando falamos de desempenho web. Foi por isso que embarquei em uma missão para otimizar cada pixel.
O formato WEBP foi uma verdadeira revolução na minha jornada. Em comparação com formatos tradicionais como JPEG e PNG, o WEBP oferece uma compressão significativamente melhor sem perder a qualidade. Isso significa imagens mais leves, que carregam mais rápido e, consequentemente, melhoram a experiência do usuário. Se você ainda não experimentou, recomendo fortemente que dê uma chance ao WEBP.
Utilizei a própria ferramenta de converter imagens desde blog.
Na era atual, onde os dispositivos móveis dominam a navegação na web, fica evidente a necessidade de otimizar cada detalhe de um site. Entre esses detalhes, as imagens destacam-se como um dos elementos mais pesados que podem afetar a velocidade de carregamento.
Foi pensando nisso que decidi criar versões de imagens adaptadas para diferentes tamanhos de tela: 320px, 640px, 960px e 1280px. Assim, garanti que os usuários móveis baixassem apenas o tamanho de imagem que realmente precisam, melhorando a performance e proporcionando uma experiência de navegação mais fluida.
Mas, como tornar esse processo mais eficiente? Aqui entra uma das minhas ferramentas secretas: ChatGPT. Mais uma vez, recorri a ele para gerar um script Ruby. Esse script automatiza a tarefa de pegar todas as imagens e criar as variações necessárias, integrando-se perfeitamente ao meu ambiente Jekyll. Uma verdadeira mão na roda!
Outro truque no meu arsenal de otimização foi substituir imagens degradê por gradiente CSS puro. A capacidade do CSS de criar gradientes sofisticados tornou desnecessário usar imagens para esse propósito. Além de reduzir o número de solicitações ao servidor, isso deu ao meu site um visual mais nítido e um carregamento mais ágil.
Se tem uma coisa que eu aprendi ao tentar otimizar meu site, é que menos pode ser mais, especialmente quando estamos falando de FontAwesome. Para muitos de nós, o FontAwesome é aquela biblioteca incrível de ícones que adiciona um "tchan" ao nosso site. No entanto, ela pode pesar no desempenho se não for usada corretamente.
Em vez de carregar toda a biblioteca, decidi ser mais seletivo. Por quê? Bom, cada ícone carregado desnecessariamente é peso extra para o seu site. E não estamos aqui para fazer nosso site malhar, certo? Então, eu mergulhei fundo na biblioteca, e selecionei apenas os ícones que realmente estava usando. Isso fez uma diferença surpreendente no tempo de carregamento.
Outra decisão que tomei foi tirar o FontAwesome de CDNs externos. A cada CDN que usamos, é necessário um check DNS, que pode adicionar um tempo precioso ao carregamento. Hospedando os ícones selecionados localmente, consegui evitar essa verificação adicional. Resultado? Um desempenho ainda mais rápido!
Se você não conhece o Lazy Load, prepare-se para ser apresentado ao seu novo melhor amigo em performance web. Em resumo, ele garante que as imagens só sejam carregadas quando estão prestes a ser exibidas na tela. Simples, mas poderoso.
Você já rolou por uma página e notou que as imagens só aparecem à medida que você desce? Esse é o Lazy Load em ação. Ao implementá-lo, garanti que as imagens abaixo da dobra (fora da tela inicial) só fossem carregadas quando o usuário realmente as alcançasse. Isso reduziu o tempo inicial de carregamento, fazendo a página parecer mais ágil.
Agora, uma dica crucial: lembre-se de não usar o lazy load em imagens que devem ser exibidas imediatamente ao carregar o site. Se uma imagem é essencial e precisa estar visível desde o início, mantenha-a fora do lazy load para garantir que ela apareça sem atrasos.
Não são apenas as imagens que podem se beneficiar do Lazy Load. Também apliquei essa técnica nos iframes. Se você usa vídeos ou outros conteúdos embutidos, esta dica é para você. Assim como as imagens, os iframes só carregarão quando estiverem prestes a entrar na viewport.
Ah, o servidor! Esse coração batendo por trás de todo site. Uma pequena mudança aqui pode fazer uma diferença enorme no desempenho global do seu site.
Quando iniciei minha jornada de otimização, uma das decisões mais impactantes que tomei foi a adoção do HTTP2 no Apache. Se você não está familiarizado com isso, aqui vai um breve resumo: ao contrário do seu antecessor, o HTTP2 permite a transferência simultânea de múltiplos arquivos. Em outras palavras, ele é projetado para tornar o carregamento das páginas muito mais eficiente.
Graças a essa mudança, consegui ganhar impressionantes 6 pontos a mais no Google Page Speed. Você pode pensar que isso seria motivo para comemorar, certo? Bem, para muitos seria, mas eu não estava completamente satisfeito. Era óbvio que ainda havia espaço para melhorias.
Essa insatisfação foi justamente o que me levou a considerar soluções mais avançadas, como a implementação do Cloudfront em etapas futuras da minha otimização. Mais pra frente eu explico melhor.
Você deve estar se perguntando: "Por que raios ele rodou o PageSpeed várias vezes?" A resposta é simples: a carga do servidor pode variar. Ao rodar o teste mais de uma vez, quis garantir que estava recebendo uma visão mais acurada do desempenho real do meu site. E, você sabe, só para ter certeza de que aquele 100 brilhante não foi só sorte!
Quando falamos de desenvolvimento web, o CSS é um gigante! Ele é o grande responsável por dar estilo, cor e vida aos nossos sites. À medida que nossos projetos evoluem, contudo, acabamos acumulando uma série de códigos CSS que, no fim das contas, não são utilizados. É como ter um guarda-roupa cheio de roupas, mas só usar metade delas. Então, como fazemos uma "limpa" nesses estilos não utilizados?
A resposta é: Purge CSS. Mas, antes de você correr para implementá-lo, tenho que te alertar: o Purge CSS pode ser um tanto traiçoeiro. Em algumas situações, ele pode acabar removendo estilos que você não queria. É como tentar fazer uma limpeza no armário e acabar doando aquela sua camisa favorita por engano.
Confesso que já tive minhas desavenças com o Purge CSS no passado. Em alguns projetos, ele não funcionou bem, e eu acabei não gostando da experiência. Porém, desta vez, com HTMLs bem estruturados e organizados, o resultado foi surpreendentemente bom! A lição que fica é: use o Purge CSS com sabedoria e atenção. Ele pode ser uma ferramenta poderosa, mas, como qualquer ferramenta, requer cuidado no manuseio.
Imagine que você criou um belo site, com diversas classes e estilos diferentes. Mas, após analisar, percebe que só está usando, digamos, 50% de todo o CSS que escreveu. Os outros 50% são apenas peso morto, tornando seu site mais lento do que o necessário. É frustrante, certo?
O Purge CSS é uma ferramenta mágica que analisa seu HTML gerado e verifica quais classes CSS estão sendo realmente usadas. Ele então cria um novo arquivo CSS contendo apenas os estilos que você realmente precisa. Isso significa uma carga mais rápida e uma pontuação melhor no Google Lighthouse!
jQuery tem sido um fiel companheiro para muitos de nós ao longo dos anos. Ele facilita a manipulação do DOM, tratamento de eventos e animações. Mas, assim como qualquer biblioteca ou framework, se não for usado com sabedoria, pode se tornar um gargalo de desempenho.
Em vez de carregar o jQuery em todas as páginas, mesmo quando não é necessário, decidi carregá-lo apenas onde realmente fazia diferença. Isso não apenas reduziu o tempo de carregamento, mas também melhorou a experiência geral do usuário.
Para otimizar ainda mais o carregamento do jQuery, utilizei os atributos async e defer. Ambos permitem que o navegador continue processando a página enquanto o script está sendo baixado, mas com pequenas diferenças:
Essa dupla otimizou significativamente o carregamento da página, garantindo que o conteúdo fosse visível mais rápido para os usuários.
Ao falar em otimização de sites, não podemos ignorar a velocidade de entrega do conteúdo. E foi pensando nisso que decidi usar o Cloudfront para acelerar a distribuição do meu site estático.
Cloudfront é um serviço de rede de entrega de conteúdo (CDN) da Amazon. Ele armazena cópias do seu site em servidores ao redor do mundo, entregando o conteúdo a partir do servidor mais próximo do usuário final. Isso reduz drasticamente o tempo de carregamento.
Mas não basta apenas usar uma CDN. É vital garantir que o DNS do seu site esteja apontando para ela, otimizando ainda mais a velocidade de carregamento. Portanto, após configurar o Cloudfront, redirecionei o DNS do meu site para ele, e voilà: velocidade máxima atingida!
Olha, foi uma jornada e tanto! Mas ver aquele 100 brilhando no Google Lighthouse fez tudo valer a pena. Espero que essas dicas te ajudem tanto quanto me ajudaram. Boa otimização!