Zalando가 Lighthouse CI를 사용해 성능 피드백 시간을 1일에서 15분으로 단축한 방법

Zalando의 웹팀은 Lighthouse CI를 통합하여 성능에 대한 선제적인 접근 방식을 취할 수 있었으며 자동화된 상태 확인을 통해 현재 커밋을 기본 브랜치와 비교하여 성능 저하를 방지할 수 있음을 확인했습니다.

Jan Brockmeyer
Jan Brockmeyer
Jeremy Colin
Jeremy Colin

활성 고객이 3,500만 명 이상인 Zalando는 유럽 최고의 온라인 패션 플랫폼입니다. 이 게시물에서는 Lighthouse CI를 사용하기 시작한 이유, 구현의 용이성, 팀에 대한 이점을 설명합니다.

Zalando는 웹사이트 실적과 수익의 관계를 잘 알고 있습니다. 이전에는 카탈로그 페이지의 로드 시간을 인위적으로 늘리는 것이 이탈률, 전환율, 사용자당 수익에 얼마나 영향을 미치는지 테스트했습니다. 결과는 명확했습니다. 페이지 로드 시간이 100밀리초 개선되면서 참여도는 증가했으며 이탈률은 낮추고 세션당 수익이 0.7% 증가했습니다.

100밀리초

페이지 로드 시간 개선

0.7%

세션당 수익 증가

회사의 승인이 항상 실적으로 이어지지는 않습니다.

회사 내부의 강력한 성능 승인에도 불구하고 성능을 제품 제공 기준으로 설정하지 않으면 쉽게 벗어날 수 있습니다. 2020년 Zalando 웹사이트 디자인을 변경할 때 Google은 우수한 사용자 환경을 유지하면서도 새로운 기능을 제공하는 동시에 맞춤 글꼴과 선명한 색상으로 웹사이트를 개편했습니다. 그러나 새롭게 디자인된 웹사이트와 앱의 출시 준비가 완료되었을 때 얼리 어답터 측정항목에서 새 버전의 속도가 더 느렸음을 알 수 있었습니다. 콘텐츠가 포함된 첫 페인트는 최대 53% 느렸으며 측정된 상호작용까지의 시간은 최대 59% 까지 느렸습니다.

Zalando의 웹

Zalando 웹사이트는 15개 이상의 기능팀이 프런트엔드 마이크로서비스를 기여하는 프레임워크를 개발하는 핵심 팀에서 만들었습니다. 새 버전을 지원하는 동시에 웹사이트의 일부를 보다 중앙 집중식 아키텍처로 전환했습니다.

이전 Mosaic 아키텍처에는 내부 측정항목으로 페이지 성능을 측정하는 방법이 포함되었습니다. 하지만 내부 실험실 성능 모니터링 도구가 부족했기 때문에 실제 사용자에게 출시하기 전에는 성능 측정항목을 비교하기 어려웠습니다. 매일 배포함에도 불구하고 성능 개선을 위해 노력하는 개발자를 위한 피드백 루프가 하루 정도 있었습니다.

웹 바이탈과 Lighthouse의 지원

사내 측정항목이 새로운 설정에 제대로 적응하지 못했기 때문에 완전히 만족하지 못했습니다. 무엇보다도 고객 경험에 중점을 두지 않았습니다. 코어 웹 바이탈로 전환했습니다. 그 이유는 압축되었지만 포괄적이며 사용자 중심적인 측정항목 세트를 제공했기 때문입니다.

출시 전에 성능을 개선하기 위해 적절한 실습 환경을 만들어야 했습니다. 이는 필드 데이터의 90번째 백분위수를 나타내는 조건을 테스트하는 것 외에도 재현 가능한 측정값을 제공했습니다. 이제 성능 개선을 위해 노력하는 엔지니어들은 가장 큰 영향을 미치기 위해 어디에 집중해야 하는지 알고 있었습니다. 이미 Lighthouse 감사 보고서를 로컬에서 사용하고 있었습니다. 따라서 첫 번째 반복은 스테이징 환경에서 변경사항을 테스트할 수 있는 Lighthouse 노드 모듈 기반 서비스를 개발하는 것이었습니다. 이를 통해 약 1시간의 안정적인 성능 피드백 루프를 얻었고, 이를 통해 성능을 그대로 제공하고 출시 버전을 저장할 수 있었습니다.

pull 요청에 대한 성능 피드백 제공

거기서 멈추고 싶지 않았습니다. 실적을 중시하는 동시에 능동적으로 대처할 수 있는 기회를 얻고 싶었기 때문입니다. Lighthouse 노드 모듈에서 Lighthouse CI (LHCI) 서버로 전환하는 작업은 그리 어렵지 않았습니다. 기존 회사 서비스와의 통합을 강화하기 위해 자체 호스팅 솔루션을 선택했습니다. LHCI 서버 애플리케이션이 Docker 이미지로 빌드되면 이 이미지는 PostgreSQL 데이터베이스와 함께 Kubernetes 클러스터에 배포되고 GitHub에 보고됩니다.

Google의 프레임워크는 이미 개발자에게 몇 가지 성능 피드백을 제공하고 있었습니다. 구성요소 번들 크기를 커밋할 때마다 임곗값과 비교했습니다. 이제 GitHub 상태 확인으로 Lighthouse 측정항목을 보고할 수 있습니다. 이로 인해 성능 임곗값을 충족하지 않으면 CI 파이프라인이 실패하며, 다음 이미지와 같이 세부 Lighthouse 보고서 링크가 포함되어 있습니다.

성공한 검사 행을 보여주는 GitHub UI 이미지
Lighthouse CI GitHub 상태 확인 기능을 사용하면 개발자가 프로덕션에 도달하기 전에 회귀를 쉽게 파악하고 해결할 수 있습니다.
커밋과 기본 브랜치를 비교하는 방법을 보여주는 Lighthouse CI의 비교 이미지
기본 브랜치와 비교한 Lighthouse CI 커밋 보고서입니다.

성능 범위 확장

우리는 매우 실용적인 접근 방식에서 시작했습니다. 현재 Lighthouse는 가장 중요한 두 페이지인 홈페이지와 제품 세부정보 페이지에서만 실행됩니다. 다행히 Lighthouse CI를 사용하면 실행 구성을 쉽게 확장할 수 있습니다. 웹사이트의 특정 페이지에서 작업하는 기능팀에서 일치하는 URL 패턴과 어설션을 설정할 수 있습니다. 이를 통해 실적 범위가 확대될 것이라고 확신합니다.

이제 대규모 버전을 빌드할 때 훨씬 더 확신을 가질 수 있으며 개발자는 코드 성능에 관한 훨씬 짧은 피드백 루프를 즐길 수 있습니다.