[북잡 프로젝트] Lighthouse를 이용한 CI/CD 기반 웹 성능 테스트 자동화 도입

평소에 정말 좋아하는 앱이 있는데 = 펫 프렌즈 🐶 😻 ❤️

앱을 좋아하다보니(=관심 많아) 펫프렌즈의 기술 블로그(프론트엔드)를 자주 보게 된다.

그 중 가장 흥미로웠던 부분은 ‘웹 성능 측정 자동화 비법: Lighthouse CI와 CI/CD의 만남’이라는 제목으로 Lighthouse CI를 활용해 CI/CD 파이프라인에 성능 측정을 통합하고 자동화한 경험을 공유한 내용이었다.

개발을 하면서 성능 측정은 프론트엔드 개발자에게 정말 중요한 부분이라고 느껴왔고 지난 프로젝트에서도 성능 중심의 리팩토링을 진행했기 때문에 더욱 흥미롭게 봤다.🥳 (사랑해요! 펫!프!렌!즈!)

특히 이번 북잡 프로젝트는 실사용자를 모집해 실제로 운영해나갈 계획이기 때문에 웹 성능 측정이 그 어느 때보다 중요하다고 판단해서 우리 북잡 프론트엔드 팀도 Lighthouse를 이용한 CI/CD 기반 웹 성능 테스트 자동화 도입을 결정했다 ✨

☹️ 이전 프로젝트에서 문제점

• 매번 페이지에서 수동으로 lighthouse를 실행하는 불편함이 분명 존재했다.

• 기기에 따라서 결과가 매번 달라지는 문제가 있어 일관된 결과를 얻기 어렵다는 한계가 있었다.

🐥 그래서 도입했지 !

• Lighthouse CI를 도입하면서 main branch에 배포하면 성능 측정을 자동화 할 수 있도록 했다.

✨ 과정

deploy.yml

name: Run Lighthouse Audit
    uses: treosh/lighthouse-ci-action@v9
        with:
          urls: https://bookjob.vercel.app
          configPath: ./lighthouserc.json

Lighthouse를 GitHub Actions에서 실행하는 부분을 추가해줬다.

lighthouserc.json

{
  "ci": {
    "collect": {
      "url": ["https://bookjob.vercel.app/"],
      "numberOfRuns": 3,
      "startServerReadyPattern": "listening on",
      "startServerReadyTimeout": 60000
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.5 }],
        "categories:accessibility": ["warn", { "minScore": 0.5 }],
        "categories:best-practices": ["error", { "minScore": 0.5 }],
        "categories:seo": ["warn", { "minScore": 0.5 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

를 추가해줬다.

이 설정은 GitHub Actions에서 Lighthouse CI를 실행할 때 어떻게 수집(collect), 검사(assert), 업로드(upload)할지를 정의하는 부분이다.

Lighthouse CI는 ci 루트 아래에 3가지 주요 단계로 나뉜다

• collect

• assert

• upload

1. collect: 웹사이트 데이터를 어떻게 수집할지 정의

   "collect": {
      "url": ["https://www.bookjob.co.kr/"], //lighthouse를 몇 번 반복 실행할지 설정
      "numberOfRuns": 3,
      "startServerReadyPattern": "listening on", //서버가 준비되었는지를 판단할 출력 패텅
      "startServerReadyTimeout": 60000 //서버가 준비되기를 기다리는 최대 시간
    }

2. assert: Lighthouse 점수가 기준 이하일 경우 실패 또는 경고로 처리

"assert": {
  "assertions": {
    "categories:performance": ["error", { "minScore": 0.5 }],
    "categories:accessibility": ["warn", { "minScore": 0.5 }],
    "categories:best-practices": ["error", { "minScore": 0.5 }],
    "categories:seo": ["warn", { "minScore": 0.5 }]
  }
}

→ 여기서 error는 GitHub Actions Job을 실패시키고, "warn"은 성공은 하지만 알림만 뜨게 해준다

3. upload: 결과를 어떻게 저장할지

"upload": {
  "target": "temporary-public-storage"
}

• Lighthouse 리포트를 임시 공개 스토리지에 저장하고 CI 실행이 끝나면 URL이 주어져서 결과를 웹에서 확인 가능하다.

→ ✅ 결과 링크는 GitHub Actions 실행 로그에 표시됨.

🌱 적용 결과

처음에는 이렇게 실패가 떴다.

점수가 내가 설정한것 보다 낮았기 때문 ㅋㅋㅋㅋㅋㅋㅋ☹️

모든걸 0.5로 내려줬더니 이제는 실패없이 잘 동작한다👍🏻

📝 느낀점 & 배운점

vercel을 활용해서 배포한 경험은 꽤 있었지만 ci/cd까지 구축하는 건 처음이었다. 그래서일까 시행착오가 정말정말 많았다.😅

GitHub Actions 설정부터 쉽지 않았다. 레퍼런스를 봐도 막상 내 프로젝트에 적용하면 자잘한 YAML 문법 오류나 Vercel token 설정 같은 부분에서도 여러 번 실패했다. yarn build는 잘 되는데 Lighthouse가 실행되지 않는다든지 배포 후 URL이 아직 준비되지 않아서 Lighthouse가 실패한다든지 예상치 못한 문제가 계속 발생했다.

그럼에도 불구하고 한 단계씩 문제를 해결하면서 “코드를 푸시하면 자동으로 빌드 → Vercel 배포 → Lighthouse 테스트까지" 이어지는 CI/CD 파이프라인을 구축할 수 있었다. 지금은 main 브랜치에 push만 하면 성능 지표까지 자동으로 확인되는 흐름이 만들어져 있어 만족스럽다.!!!

그리고 메인인 Lighthouse CI/CD를 도입!!

Lighthouse CI/CD를 도입하면서 프로젝트의 웹 품질 관리가 한층 체계적이고 자동화되었다.

처음에는 설정이 조금 복잡하게 느껴졌지만 한번 구성해두니 이후부터는 별다른 작업 없이도 매 배포마다 성능 측정이 가능해져서 효율적이었다..!! 최고 🙌🏻

특히 기준 점수 미달 시 경고 또는 에러 처리되는 점이 유용했고 실제로 성능 점수를 개선하기 위한 작업의 동기 부여도 되었다. (사실 처음에는 너무 낮게 측정돼서 충격받음 😳 )

또한 CI 실행 결과로 제공되는 Lighthouse 리포트 링크는 프론트엔드 팀원 간의 품질 공유와 회고에 도움이 될 것 같다.(아직은 성능 개선하는 단계는 아님!) 그리고 단순히 코드가 잘 돌아가는 것뿐 아니라 사용자 경험과 웹 표준까지 함께 챙길 수 있게 되어 만족스러웠다.

향후에는 페이지별로 Lighthouse 테스트 범위를 늘려보고 성능 저하가 발생한 부분에 대해 PR 단위로 분석할 수 있는 체계를 구축할 예정이다! 🥳❤️ 정말 재밌고 흥미로웠던 Lighthouse를 이용한 CI/CD 기반 웹 성능 테스트 자동화 도입,, 🥰