lazyload가 오히려 상품 상세의 CLS에 나쁜 영향을 줄 때

문제

lazyload는 이미지 최적화에서 자주 쓰이는 기본 기법입니다. 화면 밖 이미지를 나중에 불러와 초기 전송량을 줄이고, 첫 화면 로딩 부담을 낮추는 데 도움이 됩니다. 하지만 상품 상세에서는 lazyload가 잘못 적용되어 오히려 LCP와 CLS에 나쁜 영향을 주는 경우가 있습니다.

가장 흔한 문제는 첫 화면 대표 이미지까지 lazyload 대상이 되는 것입니다. 고객이 상품을 보려고 들어왔는데 대표 이미지를 일부러 늦게 불러오면 LCP가 늦어집니다. 또 이미지 영역의 높이가 미리 잡히지 않은 상태에서 lazyload 이미지가 뒤늦게 들어오면 아래 콘텐츠가 밀립니다. 고객 입장에서는 페이지가 불안정해지고, 버튼 위치가 바뀌는 경험이 됩니다.

lazyload 자체가 문제는 아닙니다. 문제는 어떤 이미지를 늦게 불러와도 되는지, 늦게 들어올 이미지의 공간을 미리 확보했는지 판단하지 않고 일괄 적용하는 것입니다.

원인

상품 상세에는 우선순위가 다른 이미지가 섞여 있습니다. 대표 상품 이미지, 핵심 혜택 배너, 상세 설명 이미지, 리뷰 이미지, 추천상품 썸네일은 모두 같은 중요도를 갖지 않습니다. 첫 화면에 필요한 이미지는 빨리 보여야 하고, 하단 상세 이미지는 늦게 불러와도 됩니다. 이 구분 없이 모든 이미지에 lazyload를 걸면 중요한 이미지까지 뒤로 밀립니다.

CLS는 영역 예약 실패에서 자주 발생합니다. 이미지의 실제 크기나 비율을 브라우저가 알지 못하면, 이미지가 로드되는 순간 레이아웃이 다시 계산됩니다. 하단 이미지라면 덜 치명적일 수 있지만, 상단 배너나 대표 이미지에서 발생하면 고객이 보는 화면 안정성에 직접 영향을 줍니다.

흔한 오해는 lazyload가 많을수록 항상 좋다는 것입니다. 실제로는 초기 화면에서 필요한 이미지는 eager 또는 preload 대상이 될 수 있고, 화면 밖 이미지는 lazyload 대상이 됩니다. 성능 최적화는 지연이 아니라 우선순위 조정입니다.

해결

내부에서 먼저 해야 할 일은 이미지를 우선순위별로 나누는 것입니다. 첫 화면 대표 이미지와 핵심 배너는 우선 로드하고, 하단 상세 이미지와 추천상품 썸네일은 lazyload로 늦춥니다. 이미지 영역에는 width/height 또는 aspect-ratio를 지정해 로딩 전에도 공간이 유지되도록 합니다.

다음으로 실제 CLS 원인을 확인해야 합니다. PageSpeed Insights의 CLS 항목이나 Chrome DevTools Performance에서 layout shift가 발생한 요소를 봅니다. 이미지가 원인인지, 광고·배너·리뷰 위젯이 원인인지 확인해야 합니다. 이미지가 원인이라면 크기 지정과 로딩 순서가 첫 조치입니다.

M2 Live Cloud 관점에서는 페이지 앞단에서 이미지와 상품기술서 영역의 우선순위를 정리하는 접근을 씁니다. 첫 화면에 필요한 이미지는 우선 처리하고, 하단 이미지는 늦게 불러오며, 영역은 안정적으로 유지되도록 정책을 나눕니다. 단순 lazyload 적용보다 중요한 것은 고객이 보는 순서에 맞춘 로딩 설계입니다.

지금 실행

• 직접 확인: PageSpeed Insights에서 LCP 요소와 CLS 발생 요소를 확인하세요. DevTools Performance의 layout shift track을 보면 어떤 이미지나 배너가 화면을 밀었는지 알 수 있습니다.
• 내부 조치: 첫 화면 대표 이미지와 핵심 배너는 lazyload에서 제외하고, 하단 이미지에만 적용하세요. 모든 이미지 영역에는 aspect-ratio 또는 width/height를 지정해 로딩 전 공간을 확보합니다.
• 구조 검토: 상품기술서와 셀러 HTML에 lazyload, 고정 폭 이미지, 외부 배너가 뒤섞여 있어 일괄 규칙 적용이 어렵다면 페이지 앞단에서 우선순위와 레이아웃 안정성을 정리하는 방식을 검토해야 합니다.