Sugerencias
← TIL
~2 min de lectura
#performance#ci-cd#lighthouse#devops

Configurando Lighthouse CI en tu pipeline

Dejá de festejar el 100/100 de Lighthouse en tu máquina local. La performance web no es una foto; es una regresión constante. Si no tenés “Presupuestos de Rendimiento” automatizados en tu pipeline que bloqueen físicamente los Pull Requests que degradan tus Core Web Vitals, el próximo commit de un junior va a hundir tu conversión B2B.

¿Cómo implementás la barrera de peaje?#

El corazón de Lighthouse CI es su archivo de configuración, que dicta exactamente qué métricas tolerás y cuáles son innegociables.

Terminal
campa@macbook~$npm install -g @lhci/cli

          added 1 package, and audited 2 packages in 1s
        

Luego, definís el contrato en la raíz de tu proyecto:

lighthouserc.json
{
  "ci": {
    "collect": {
      "staticDistDir": "./dist",
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 1 }],
        "first-contentful-paint": ["warn", { "maxNumericValue": 2000 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Para que esto funcione en piloto automático, lo integrás a GitHub Actions usando su action oficial:

.github/workflows/ci.yml
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build project
        run: npm run build
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: './lighthouserc.json'
          uploadArtifacts: true
          temporaryPublicStorage: true
🛠️Mitigando la Varianza de RedHaz clic para expandir

Te vas a dar cuenta rápido de que los runners gratuitos de GitHub no son estables. Si corrés Lighthouse una sola vez, un pico de red puede hacer fallar un PR válido. Por eso usamos "numberOfRuns": 3. LHCI ejecuta la auditoría tres veces y utiliza la mediana para aplicar las aserciones. Además, notarás que usamos "error" para la puntuación general (bloquea el merge) pero "warn" para el FCP (solo avisa). Esto evita fricción innecesaria mientras mantenés a raya las regresiones graves.

¿Por qué esto es vital para el negocio?#

Descubrir que tu checkout tarda 4 segundos después de que un cliente se queja en Twitter es carísimo. El rendimiento web es un riesgo legal en muchos casos. Automatizar esta métrica es dar un paso de senior hacia un desarrollo sin fricciones locales.

$0Costo de Regresión
Impacto
Prevención Automática

Bloqueando el código lento en el pipeline, eliminás el costo de que QA y los usuarios lo sufran en producción.

¿Deberías implementar Lighthouse CI hoy?

Compralo si querés

  • Métricas estables y predecibles en el tiempo
  • Terminar el debate 'en mi compu anda rápido'
  • Asegurar accesibilidad AAA desde el día 1

Preparate para

  • Aumentar el tiempo total de tu CI/CD (aprox 2-3 mins)
  • Falsos positivos ocasionales en runners virtuales saturados
  • Mantener (y a veces flexibilizar) los presupuestos a medida que la app crece

Referencias#

g CO₂
Enlace copiado al portapapeles