Google Lighthouse: do DevTools ao CI/CD

Ei, desenvolvedor web, você conhece o Google Lighthouse? 💡
Essa ferramenta deveria estar no seu dia-a-dia! Ela permite auditar a performance, acessibilidade, SEO e até mesmo as melhores práticas do seu site.

Por que usar o Google Lighthouse?

Performance: Identifique gargalos que estão deixando sua página lenta e obtenha recomendações detalhadas sobre como melhorar o tempo de carregamento.
Acessibilidade: Verifique se o seu site está acessível para todos os usuários, incluindo aqueles com deficiências.
SEO: O Lighthouse oferece insights valiosos para otimizar seu conteúdo e garantir que ele seja facilmente encontrado pelos mecanismos de busca.
Melhores Práticas: Valide se o seu site segue as melhores práticas de desenvolvimento web, como segurança e uso adequado de APIs.

Beleza, mas como uso o Lighthouse? 🤔

Basta acessar o DevTools do Google Chrome e procurar a aba do Lighthouse!

Você pode customizar a análise, selecionando o modo de auditoria, o tipo de dispositivo e as categorias desejadas. Após isso, é só clicar no botão "Analyze page load".

Ao finalizar a auditoria, o Lighthouse vai gerar um relatório completo com os Scores de cada categoria:

O mais interessante é que o relatório vem acompanhado de sugestões de melhorias para aprimorar os Scores. Você pode expandir cada problema encontrado para entender o que pode ser feito. É uma excelente forma de aprender mais sobre aspectos da web para tornar um site o mais eficiente possível.

Utilizando via linha de comando

Mas a grande sacada em utilizar o Lighthouse, na minha opinião, não é realizar a auditoria de forma manual, mas sim automatizar esse processo. Isso é possível graças a ferramenta de linha de comando que o Google disponibiliza.

É possível instalar o Lighthouse via npm ou yarn e realizar uma auditoria de URLs específicas ou de arquivos HTML estáticos. Podemos customizar de diversas maneiras a auditoria, verifique todas as opções pela documentação.

npm install -g lighthouse
# or usar o yarn:
# yarn global add lighthouse

lighthouse http://example.com

Já pensou o quão eficiente é rodar a auditoria do Lighthouse a cada Pull Request aberto? E o melhor: é possível definir “budgets”, que se caso não forem alcançados, uma falha é emitida e o Pull Request não será margeado sem antes realizar as melhorias.

Imagine uma situação onde uma pessoa subiu um Pull Request com uma nova lib que está prejudicando a performance da aplicação. Somente com um Code Review talvez não seja possível identificar esse problema. Mas com uma automação do Lighthouse, o Score de performance será visível e imediatamente notificado.

Existem integrações do Lighthouse para todas as opções de CI/CD do mercado. Eu utilizo a Lighthouse CI Action do Github Actions. Ela possui diversas customizações para atender diversos cenários.

Integrando Lighthouse no Github Actions

Primeiramente, precisamos de uma aplicação frontend. Como estou acostumado a trabalhar com Angular, vou utilizá-lo, mas a tecnologia aqui pouco importa. Vou criar o projeto com o seguinte comando:

ng new lighthouse-ci

GitHub - andrewarosario/lighthouse-ci

Para utilizar o Continuous Integration do Github Actions, precisamos criar Workflows dentro do seguinte diretório: .github/workflows. O nome precisa ser exatamente esse, caso contrário, não será possível executar nosso Workflow. Portanto criarei na raiz do repositório o arquivo .github/workflows/lighthouse.yml.

name: Lighthouse
on:
  pull_request:
    branches:
      - main
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install dependencies
        run: npm ci
      - name: Build the project
        run: npm run build
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: "./.github/lighthouse/lighthouserc.json"
          temporaryPublicStorage: true

Este workflow será disparado a cada Pull Request com o target para a branch main. Esta é somente uma sugestão. Você pode customizar conforme a necessidade do seu projeto.

Ele possui um job com os seguintes steps:

• Obtém o código a partir da action actions/checkout;
• Instala as dependência com o npm ci (semelhante ao npm install, porém é mais recomendado em ambientes de automação);
• Realiza o build do projeto com npm run build;
• Executa a auditoria do Lighthouse nos arquivos estáticos que foram gerados pelo build com duas opções:
  configPath para definir o caminho com as configurações da nossa análise, e temporaryPublicStorage, que será o relatório da auditoria que poderemos acessar por uma URL.

Com este arquivo, já temos a configuração pronta! Agora precisamos subir esse código no Github. Portanto faremos os seguintes passos:

• Criar um repositório pelo Github;
• Fazer o commit das alterações;
• Executar o push para o repositório.

O nosso workflow ainda não vai ser disparado pelo simples fato de que instruímos o arquivo .yml a triggar somente ao abrir uma Pull Request.

Lighthouse em ação na Pipeline

Agora que já temos o script pronto, vamos subir uma Pull Request para o Github com alguma alteração intencional para vermos o Lighthouse CI em ação.

Para forçar uma falha na auditoria, posso subir uma alteração removendo o atributo alt de um elemento img. Essa prática irá disparar um problema de acessibilidade pelo Lighthouse. A Pull Request pode ser conferida neste link.

Este e outros erros foram encontrados na Pipeline! Podemos configurar para que um Pull Request somente possa ser mergeado quando todos esses problemas forem resolvidos, garantindo que nada problemático seja subido para a branch principal.

O botão de Merge fica desabilitado caso a análise do Lighthouse falhe.

O mais interessante é que com essas configurações no CI, temos o relatório completo hospedado temporariamente para análises mais profundas. A Action vai gerar um link com um HTML onde podemos analisar a auditoria.

Aqui está o mesmo problema, com muito mais detalhes.

É importante mencionar que podemos customizar todos os nossos "budgets" pelo arquivo lighthouserc.json. No repositório de exemplo eu somente atribuí um preset que é bastante difícil de ser alcançado. Porém, você pode definir todos os scores máximos para as definições que façam mais sentido para a sua aplicação. Verifique a documentação para entender como definir seus próprios budgets.

Conclusão

Neste artigo aprendemos sobre a poderosa ferramenta Lighthouse e como ela pode ser uma aliada para garantir performance, acessibilidade, SEO e melhores práticas de uma página web.

Além disso, entendemos como podemos integrar a auditoria do Lighthouse em uma Pipeline de CI/CD, criando barreiras para que Pull Requests que afetem negativamente a auditora não sejam mergeados enquanto os problemas não sejam resolvidos.