로딩 UI가 Web Vitals에 미치는 영향

문제 발견

상품 데이터를 100개 추가한 뒤 Lighthouse 검사를 진행했습니다. 데이터가 늘었으니 자연스럽게 LCP가 큰 문제일 것이라 예상했어요.

상품 수 증가 → 네트워크 요청 증가 → 렌더링 비용 증가

하지만 결과는 LCP는 예상 범위 내였고, CLS는 사용자 경험을 해칠 수 있는 수준이었습니다. 이 지점에서 단순히 “성능이 나쁘다”라고 보기보다, 왜 CLS가 더 크게 잡혔는지를 먼저 이해해야겠다고 생각했어요.

그래서 문제를 이렇게 나누어 보았습니다.

• 페칭 전략 문제 (LCP 관점)
• 로딩 UI 레이아웃 전환 문제 (CLS 관점)

페칭 방식 재검토

기존에는 상품 데이터를 한 번에 모두 페칭해 렌더링하는 구조였습니다. 초기에는 문제가 없었지만, 상품 수가 늘어나면서 화면에 보이지 않는 상품까지 함께 처리되며 초기 렌더링 부담이 점점 커지고 있었어요.

이 방식은 장기적으로 유지하기 어렵다고 판단하였고, 렌더링 단위를 줄이기 위해 무한 스크롤과 Load More 방식을 검토했습니다.

무한 스크롤을 선택하지 않은 이유

우선 처음 생각했던건 무한스크롤 이였는데, 무한 스크롤은 화면 하단에 도달하면 자동으로 다음 데이터를 불러오는 방식으로 피드 형태의 콘텐츠를 빠르게 소비하는 서비스에는 적합하다고 느꼈습니다.

하지만 패션 커머스에서는 사용자가 스크롤을 멈추고 상품의 이미지, 가격, 정보 등을 비교하며 천천히 살펴보는 경우가 많습니다. 이런 상황에서 콘텐츠가 자동으로 추가되면, 보고 있던 기준점이 흐려지거나 화면이 의도치 않게 밀리는 경험을 줄 수 있다고 판단했어요.

Load More 방식을 선택한 이유

그래서 다음 데이터를 자동으로 로드하지 않고, 사용자가 명시적으로 요청했을 때만 추가 로드를 수행하는 Load More 방식을 선택했습니다.

이를 통해

• 초기 렌더링 부담을 줄이고
• 사용자가 화면 흐름을 통제할 수 있으며
• 커머스 특성에 맞는 탐색 경험을 유지할 수 있었습니다.

이 변경으로 LCP는 1.4초 -> 1.1초로 어느 정도 개선되었지만, CLS 문제는 여전히 남아 있었습니다.

CLS가 높게 측정된 이유

상품 리스트 페이지에서 기능적으로 큰 문제는 없었지만, 로딩 과정에서 화면이 어색하게 변하는 느낌이 계속 신경 쓰였습니다. 로딩 스피너가 사라지고 상품 카드가 렌더링되는 순간 그리드가 다시 배치되는 듯한 인상이 반복되었습니다.

CLS가 높게 측정된 이유도, 실제 픽셀 이동보다는 이런 레이아웃 구조 전환에 있었다고 판단했습니다.

사용자 환경을 고려한 초기 로딩 UI

모든 사용자가 항상 좋은 네트워크나 기기 환경에서 서비스를 이용하지는 않는다.

저사양 기기나 느린 네트워크 환경에서는 초기 로딩이 길어질 수 있고, 아무 정보가 없는 로딩 스피너는 체감 대기 시간을 길게 느끼게 만들 수 있고, 이는 이탈로 이어질 가능성이 있다고 생각합니다.

그래서 초기 진입 시 로딩 스피너 대신, 실제 상품 카드 구조를 그대로 반영한 Skeleton UI를 적용했습니다. 로딩 중에도 화면의 구성과 정보 배치를 미리 인지할 수 있어, 느린 환경에서도 기다릴 수 있는 화면을 만드는 데 적합하다고 느꼈습니다.

Skeleton UI 적용

• 로딩 전과 후에도 레이아웃 구조가 동일하게 유지
• CLS 0.846 -> 0.039으로 개선

총 개선 결과

러닝 포인트

로딩 스피너를 사용할 때는 데이터가 도착하는 순간 화면 구조가 바뀌며, 사용자가 보고 있던 기준점이 계속 흔들렸습니다. 반면 Skeleton UI를 적용하자 로딩 전후의 화면 구조가 유지되면서, 사용자는 기다리는 동안에도 다음에 무엇이 나올지 예측할 수 있었습니다. 이 경험을 통해 CLS는 단순히 레이아웃을 미세 조정하는 문제가 아니라, 로딩 중 사용자가 어떤 흐름을 따라가고 있는지를 설계하는 문제라는 걸 느꼈습니다.