지연 로드가 너무 많을 때의 성능 영향

Core Web Vitals를 고려한 이미지 지연 로드에 관한 데이터 기반 조언입니다.

Felix Arntz

Rick Viscomi

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

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

입양

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

HTTP Archive 프로젝트의 원시 데이터를 쿼리하면 어떤 종류의 웹사이트가 채택을 주도하고 있는지 더 명확하게 파악할 수 있습니다. 브라우저 수준 이미지 지연 로드를 사용하는 사이트의 84% 는 WordPress를 사용하고, 2% 는 다른 CMS를 사용하며, 나머지 14% 는 알려진 CMS를 사용하지 않습니다. 이러한 결과는 WordPress가 채택을 주도하고 있음을 분명히 보여줍니다.

채택률도 주목할 만합니다. 1년 전인 2020년 7월에는 지연 로드를 사용하는 WordPress 사이트가 약 600만 개의 코퍼스 중 수만 개의 웹사이트 (전체의 1%)를 차지했습니다. 이후 WordPress에서만 지연 로드 채택이 100만 개 이상의 웹사이트 (전체의 14%)로 증가했습니다.

상관관계 실적

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

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

이러한 결과는 상관관계가 있으며 지연 로드가 성능 저하의 원인이라고 반드시 지적하는 것은 아닙니다. 가설적으로, 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의 차이는 데스크톱 및 모바일 테스트 모두에서 표준 편차 1 미만이므로 이는 변동으로 인한 것일 수 있으며 전반적으로 변화가 없는 것으로 간주할 수 있습니다. 이에 비해 보관 파일 페이지의 차이는 표준 편차 2~3에 가깝습니다.

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

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

수정사항 테스트

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

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

이 결과는 훨씬 더 유망합니다. 스크롤해야 볼 수 있는 부분의 이미지만 지연 로드하면 LCP 회귀가 완전히 반전되고 지연 로드를 완전히 사용 중지하는 것보다 약간 개선될 수도 있습니다. 지연 로드를 전혀 사용하지 않는 것보다 어떻게 더 빠를 수 있을까요? 한 가지 설명은 스크롤해야 볼 수 있는 이미지를 로드하지 않으면 LCP 이미지와의 네트워크 경합이 줄어들어 더 빠르게 로드할 수 있다는 것입니다.

이미지 바이트 측면에서 이 수정사항은 기본 동작과 비교하여 전혀 변경되지 않습니다. 이는 현재 접근 방식의 장점 중 하나였기 때문에 매우 좋습니다.

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

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

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

구현

이미지를 지연 로드하는 더 나은 방법, 즉 이미지 절약과 더 빠른 LCP 성능을 모두 확인했으니 사이트에서 이 방법을 어떻게 사용할 수 있을까요? 가장 우선순위가 높은 변경사항은 WordPress 코어에 패치를 제출하여 실험적 수정사항을 구현하는 것입니다. 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});

위의 JavaScript 스니펫은 최신 LCP 요소를 평가하고 지연 로드된 경우 경고를 로깅합니다.

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

결론

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

비교적 새로운 웹 플랫폼 API를 사용해 보는 것은 위험과 보상을 모두 수반할 수 있습니다. 이러한 API를 최첨단 기능이라고 부르는 데는 이유가 있습니다. 브라우저 수준 이미지 지연 로드의 까다로움을 이해하기 시작하면서 이를 사용하여 더 나은 성능을 달성하는 방법의 장점도 확인하고 있습니다.