Google Mueller, LCP 최적화가 엉뚱한 곳을 겨냥하는 사례를 조명하다

Search Engine Journal이 Google Search Advocate John Mueller가 공유한 web.dev 사례 연구를 다뤘다. 브라질 이커머스 플랫폼 Nuvemshop이 1년간 Core Web Vitals 개선 작업을 수행하면서 겪은 LCP 측정 함정과 해결 과정이 핵심이다.

무엇이 새로운가

Nuvemshop 스토어프론트의 85%에 캐러셀이 존재했는데, CSS transition 때문에 브라우저의 LCP 감지가 실제 사용자가 먼저 보는 캐러셀이 아닌 아래쪽 배너를 LCP 요소로 잡는 문제가 있었다. 즉, 기존 최적화가 실제 LCP가 아닌 요소를 대상으로 진행됐다. 수정 사항은 세 가지로 요약된다: 상단 섹션의 CSS transition 제거, 첫 번째 이미지에서 loading="lazy" 제거, LCP 후보 이미지에 fetchpriority="high" 적용. 추가로 엣지 캐싱도 도입했다. 결과적으로 양호한 LCP 점수를 가진 스토어 비율이 57%에서 96%로 올랐다고 자체 보고했다. 전체 Core Web Vitals 통과율도 48%에서 72%로 개선됐다고 한다. 다만 원문도 명시하듯 이 수치는 자체 보고이며 통제된 실험이 아니다.

설정 파일에 어떤 의미인가

이 사례는 특정 빌드 도구나 설정 파일의 변경보다는 HTML 마크업과 CSS 렌더링 방식의 조정에 가깝다. loading="lazy"와 fetchpriority="high" 속성은 프레임워크 수준에서 제어되는 경우가 많다. 예를 들어 Next.js의 Image 컴포넌트는 priority prop으로 fetchpriority와 lazy loading을 함께 제어하고, Nuxt Image나 Astro 등도 유사한 설정을 제공한다. 커스텀 테마나 CMS 템플릿 시스템을 운영한다면, 상단 섹션 이미지의 로딩 속성이 템플릿 설정에서 어떻게 결정되는지 점검할 필요가 있다. 다만 원문은 특정 프레임워크 설정과의 상호작용을 상세히 다루지 않으므로, 사용 중인 프레임워크 문서에서 LCP 관련 이미지 우선순위 옵션을 직접 확인하는 것이 정확하다.

다음 단계 제안

지금 운영 중인 사이트에서 실제 LCP 요소가 무엇인지부터 확인하자. Chrome DevTools의 Performance 패널이나 PageSpeed Insights에서 LCP 요소를 직접 눈으로 볼 수 있다. 캐러셀이나 동적 레이아웃을 쓰고 있다면, CSS transition이 LCP 감지를 밀어내고 있는지, 상단 이미지에 loading="lazy"가 붙어 있진 않은지 점검하는 것만으로도 의미 있는 첫걸음이 된다. 원문의 사례 연구 전문과 web.dev 원본 글에 구체적인 디버깅 흐름이 나와 있으니 참고할 것.

---

원문 전체 보기: Google’s Mueller Flags A Case On Why LCP Fixes Miss the Target (Search Engine Journal)