너무 많은 지연 로드가 성능에 미치는 영향

코어 웹 바이탈을 염두에 두고 지연 로드 이미지를 위한 데이터 기반 조언

Felix Arntz

Rick Viscomi

지연 로드는 필요할 때까지 리소스 다운로드를 지연하여 데이터를 절약하고 중요한 애셋에 대한 네트워크 경합을 줄이는 기술입니다. 2019년에 웹 표준이 되었으며, 현재 이미지용 loading="lazy"는 대부분의 주요 브라우저에서 지원됩니다.

이 가이드에서는 브라우저 수준 이미지 지연 로드의 채택 및 성능 특성을 이해하기 위해 공개적으로 사용 가능한 웹 투명성 데이터 및 임시 A/B 테스트를 분석한 방법을 요약합니다. 연구 결과에 따르면 지연 로드가 불필요한 이미지 바이트를 줄이는 데는 매우 효과적인 도구일 수 있지만, 과도하게 사용하면 성능에 부정적인 영향을 미칠 수 있습니다. 구체적으로, 이 분석에 따르면 초기 표시 영역 내에서 이미지를 더 빠르게 로드할 때(나머지 이미지는 지연 로드) 두 환경의 장점을 모두 활용할 수 있습니다. 즉, 로드되는 바이트가 줄어들고 코어 웹 바이탈이 개선됩니다.

채택 현황

HTTP Archive의 최신 데이터에 따르면 기본 제공 이미지 지연 로드는 웹사이트의 29%에서 사용되고 있으며 채택률이 빠르게 증가하고 있습니다.

HTTP 보관 프로젝트에서 원시 데이터를 쿼리하면 도입을 촉진하는 웹사이트 유형을 더 명확하게 이해할 수 있습니다. 브라우저 수준 이미지 지연 로드를 사용하는 사이트의 84% 는 WordPress를 사용하고, 2% 는 다른 CMS를 사용하며, 나머지 14% 는 알려진 CMS를 사용하지 않습니다. 이러한 결과는 WordPress가 도입을 주도하고 있는 이유를 명확하게 보여줍니다.

채택률도 주목할 만합니다. 1년 전 2020년 7월에는 지연 로드를 사용하는 WordPress 사이트가 수만 개의 웹사이트로 구성되어 있었는데, 총 600만 개 (전체의 1%)였습니다. 이후 WordPress에서만 레이지 로드 채택이 100만 개가 넘는 웹사이트 (전체 웹사이트의 14%)로 성장했습니다.

상관 성능

HTTP 보관 파일을 자세히 살펴보면 최대 콘텐츠 페인트 (LCP) 측정항목을 통해 브라우저 수준 이미지 지연 로드가 있거나 없는 페이지의 실적을 비교할 수 있습니다. LCP 데이터는 실험실에서 진행되는 합성 테스트가 아닌 Chrome 사용자 환경 보고서 (CrUX)의 실제 사용자 환경에서 가져옵니다. 다음 차트는 상자 및 수염 플롯을 사용하여 각 페이지의 75번째 백분위수 LCP 분포를 시각화합니다. 선은 10번째 및 90번째 백분위수를 나타내고 상자는 25번째 및 75번째 백분위수를 나타냅니다.

지연 로드가 없는 페이지 중앙값의 75번째 백분위수 LCP는 2,922밀리초인 반면, 지연 로드가 있는 중간 페이지의 LCP는 3,546밀리초입니다. 전반적으로 지연 로드를 사용하는 웹사이트는 LCP 성능이 더 낮은 경향이 있습니다.

이는 상관관계 결과이며 반드시 지연 로드가 성능 저하 원인을 가리키는 것은 아니라는 점을 짚고 넘어가야 합니다. WordPress 사이트가 지연 로드 사용자 집단에서 차지하는 비중을 고려할 때 WordPress 사이트가 약간 느린 경향이 있다면 그 차이를 알 수 있습니다. 이러한 변동성을 없애기 위해 WordPress 사이트로 초점을 좁혀나갈 수 있습니다.

안타깝게도 WordPress 페이지를 드릴다운할 때도 동일한 패턴이 나타납니다. 지연 로드를 사용하는 페이지는 LCP 성능이 더 느립니다. 지연 로드가 없는 WordPress 페이지 중앙값의 75번째 백분위수 LCP는 3,495밀리초이며, 지연 로드를 사용한 중앙값 페이지의 경우 3,768밀리초입니다.

이 경우에도 지연 로드로 인해 페이지 속도가 느려지는 것은 입증되지 않지만 지연 로드를 사용하면 성능이 느려질 수 있습니다. 인과 관계 질문에 답하기 위해 실험실 기반 A/B 테스트를 설정했습니다.

인과적 실적

A/B 테스트의 목표는 WordPress 코어에서 기본 제공되는 이미지 지연 로드가 LCP 성능을 낮추고 이미지 바이트를 줄였다는 가설을 증명하거나 반증하는 것이었습니다. 이때 사용한 방법은 twentytwentyone 테마의 WordPress 웹사이트 데모를 테스트하는 것이었습니다. 데스크톱 및 에뮬레이션된 휴대기기에서 WebPageTest를 사용하여 아카이브 및 단일 페이지 유형(예: 홈 및 기사 페이지)을 모두 테스트했습니다. 지연 로드를 사용하는 페이지와 사용하지 않는 페이지의 조합을 각각 테스트했으며, 각 테스트를 9번 실행하여 LCP 중앙값과 이미지 바이트 수를 얻었습니다.

이 결과는 데스크톱과 모바일의 보관 파일 테스트와 단일 페이지 테스트의 LCP 중앙값을 밀리초 단위로 비교합니다. 아카이브 페이지에서 지연 로드를 사용 중지했을 때 LCP가 크게 개선되었습니다. 그러나 단일 페이지에서는 차이가 적었습니다.

지연 로드를 사용 중지하면 단일 페이지가 약간 더 빨라지는 것으로 보입니다. 그러나 LCP의 차이는 데스크톱 테스트와 모바일 테스트에서 모두 하나의 표준 편차 미만이므로 이는 변동에 기인한 것으로 간주되며 변경은 전체적으로 중립적입니다. 반면 자료실 페이지의 차이는 표준 편차가 2~3에 가깝습니다.

이 결과는 각 테스트의 이미지 바이트 중앙값 (KB)을 비교합니다. 예상대로 지연 로드는 이미지 바이트 수를 줄이는 데 매우 명확하게 긍정적인 영향을 미칩니다. 실제 사용자가 전체 페이지를 스크롤하면 모든 이미지가 표시 영역에 들어올 때 로드되지만, 이러한 결과를 보면 초기 페이지 로드 성능이 개선되었음을 알 수 있습니다.

A/B 테스트 결과를 요약하자면 WordPress에서 사용하는 지연 로드 기법은 지연된 LCP 대신 이미지 바이트를 줄이는 데 매우 도움이 됩니다.

수정사항 테스트

이 실험에서 WordPress의 현재 지연 로드 구현에서 가장 중요한 측면은 표시 영역 (스크롤 없이 볼 수 있는 부분) 내에서 이미지를 지연 로드한다는 것입니다. CMS 블로그 게시물에서는 이를 피해야 할 패턴으로 인정하고 있지만, 당시의 실험 데이터에 따르면 LCP에 미치는 영향이 적고 WordPress Core에서 구현을 간소화할 가치가 있다고 밝혔습니다.

이 새로운 데이터를 바탕으로 스크롤 없이 볼 수 있는 부분에 표시되는 지연 로드 이미지를 방지하는 실험용 수정사항이 생성되었으며, 첫 번째 A/B 테스트와 동일한 조건에서 수정사항을 테스트했습니다.

이러한 결과는 훨씬 더 고무적입니다. 스크롤해야 볼 수 있는 부분의 이미지만 지연 로드하면 LCP 회귀가 완전히 역전되고 지연 로드를 완전히 사용 중지하는 것보다 약간 개선될 수도 있습니다. 지연 로드를 사용하지 않는 것보다 얼마나 빠를 수 있을까요? 한 가지 이유는 스크롤해야 볼 수 있는 부분의 이미지를 로드하지 않으면 LCP 이미지와의 네트워크 경합이 줄어 더 빠르게 로드될 수 있기 때문입니다.

이미지 바이트 측면에서 수정사항은 기본 동작과 비교할 때 전혀 변경되지 않습니다. 이것이 현재 접근 방식의 강점 중 하나였기 때문에 바람직합니다.

이 수정사항에는 몇 가지 주의사항이 있습니다. WordPress는 서버 측에서 지연 로드할 이미지를 결정합니다. 즉, 사용자의 표시 영역 크기나 이미지가 해당 표시 영역 내에서 초기 로드되는지 여부에 대해 아무것도 알 수 없습니다. 따라서 수정은 마크업에서 이미지의 상대적 위치에 대한 휴리스틱을 사용하여 이미지가 표시 영역에 로드될지 추측합니다. 특히 이미지가 페이지의 첫 번째 추천 이미지이거나 기본 콘텐츠의 첫 번째 이미지인 경우 스크롤 없이 볼 수 있는 부분 또는 스크롤 없이 볼 수 있는 부분에 있다고 간주되어 지연 로드되지 않습니다.

제목의 단어 수 또는 주요 콘텐츠 앞부분의 단락 텍스트 양과 같은 페이지 수준 조건은 이미지가 표시 영역 내에 있는지 여부에 영향을 줄 수 있습니다. 휴리스틱의 정확성, 특히 표시 영역 크기 및 페이지의 스크롤 위치를 변경하는 앵커 링크의 사용에 영향을 줄 수 있는 사용자 수준 조건도 있습니다.

따라서 수정사항은 일반적인 경우에 좋은 성능을 제공하기 위해서만 보정되며, 이러한 결과를 모든 실제 시나리오에 적용할 수 있도록 미세 조정이 필요할 수 있음을 인정하는 것이 중요합니다.

구현 (:#implementation)

이미지 지연 로드를 위한 더 나은 방법, 이미지 절감액 및 LCP 성능 향상에 대해 알아봤습니다. 이제 사이트에서 이를 어떻게 사용할 수 있을까요? 가장 우선순위가 높은 변경은 실험용 수정사항을 구현하기 위해 WordPress Core에 패치를 제출하는 것입니다. CMS에 대한 브라우저 수준 지연 로드 블로그 게시물의 안내도 스크롤 없이 볼 수 있는 부분의 지연 로드의 부정적인 영향과 CMS에서 휴리스틱을 사용하여 이를 방지하는 방법을 명확히 설명합니다.

이러한 권장사항은 모든 웹 개발자에게 적용되므로 Lighthouse와 같은 도구에서 지연 로드 안티패턴을 플래그하는 것이 좋습니다. 감사 진행 상황을 확인하려면 GitHub의 기능 요청을 참고하세요. 그때까지는 LCP 요소가 지연 로드되는 인스턴스를 찾기 위해 개발자가 할 수 있는 한 가지 작업은 필드 데이터에 더 자세한 로깅을 추가하는 것입니다.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

위의 자바스크립트 스니펫은 최신 LCP 요소를 평가하고 지연 로드된 경우 경고를 기록합니다.

이는 지연 로드 기법의 날카로운 측면과 플랫폼 수준에서의 API 개선 가능성도 보여줍니다. 예를 들어 loading 속성에도 불구하고 수정과 비슷한 처음 몇 개의 이미지를 기본적으로 로드하는 실험을 Chromium에서 사용할 수 있는 미해결 문제가 있습니다.

결론

사이트에서 브라우저 수준의 이미지 지연 로드를 사용하는 경우 구현 방법을 확인하고 A/B 테스트를 실행하여 성능 비용을 더 잘 파악하세요. 스크롤 없이 볼 수 있는 부분에 이미지를 빠르게 로드하는 것이 도움이 될 수 있습니다. WordPress 사이트가 있다면 곧 WordPress Core에 패치가 제공될 것입니다. 다른 CMS를 사용하는 경우 해당 CMS가 여기에 설명된 잠재적인 성능 문제를 알고 있는지 확인하세요.

비교적 새로운 웹 플랫폼 API를 사용해 보면 위험과 보상이 수반될 수 있는데, 여기에는 첨단 기능이라고 불리는 이유가 있습니다. 우리는 브라우저 수준의 이미지 지연 로딩의 골칫거리를 이해하기 시작함과 동시에 이 기능을 사용하여 성능을 향상하는 방법에 대한 이점도 목도하고 있습니다.

사진: 프랭키 로페즈(Unsplash 제공)