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

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

Felix Arntz

릭 비스코미

지연 로드는 필요할 때까지 리소스 다운로드를 연기하는 기법으로, 이를 통해 데이터를 보존하고 중요한 애셋의 네트워크 경합을 줄일 수 있습니다. 이는 2019년에 웹 표준이 되었으며 현재 이미지의 loading="lazy"는 대부분의 주요 브라우저에서 지원됩니다. 좋네요. 그런데 지연 로드 같은 것이 있나요?

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

채택 현황

HTTP Archive의 최신 데이터에 따르면 네이티브 이미지 지연 로드가 웹사이트의 17%에서 사용되고 있으며 채택률이 빠르게 증가하고 있습니다. 이러한 생태계 거점은 상대적으로 새로운 API로서 주목할 만합니다.

HTTP Archive 프로젝트의 원시 데이터를 쿼리하면 채택을 유도하는 웹사이트 유형을 더 명확하게 파악할 수 있습니다. 네이티브 이미지 지연 로드를 사용하는 사이트의 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,922ms인 반면 지연 로드를 사용하는 페이지 중앙값은 3,546ms입니다. 전반적으로 지연 로드를 사용하는 웹사이트는 LCP 성능이 저하되는 경향이 있습니다.

이는 상관관계 결과이며 지연 로드가 성능 속도 저하의 원인이라고 반드시 지적하는 것은 아닙니다. 가설적으로 WordPress 사이트가 약간 느려지는 경향이 있고 이 사이트가 지연 로드 사용자 집단을 구성하는 정도를 고려할 때 이러한 차이를 설명해 줄 수 있습니다. 이제 WordPress 사이트만 살펴봄으로써 이러한 가변성을 제거해 보겠습니다.

안타깝게도 WordPress 페이지를 자세히 살펴볼 때도 동일한 패턴이 나타납니다. 지연 로드를 사용하는 페이지는 LCP 성능이 더 느린 경향이 있습니다. 지연 로드를 사용하지 않는 WordPress 페이지 중앙값은 75번째 백분위수 LCP인 3,495ms와 달리 지연 로드를 사용하는 페이지 중앙값은 3,768ms입니다.

지연 로드로 인해 페이지 속도가 느려진다는 사실이 여전히 증명되지는 않지만 지연 로드를 사용하면 성능이 느려집니다. 인과관계 질문에 답하기 위해 실험실 기반 A/B 테스트를 설정합니다.

인과적 성능

A/B 테스트의 목표는 WordPress 코어에서 구현된 네이티브 이미지 지연 로드를 사용하면 LCP 성능이 느려지고 이미지 바이트 수가 감소한다는 가설을 증명하거나 반증하는 것이었습니다. Google에서 사용한 방법은 twentytwentyone 테마로 데모 WordPress 웹사이트를 테스트하는 것입니다. WebPageTest를 사용하여 데스크톱과 에뮬레이션된 휴대기기에서 보관 파일 및 단일 페이지 유형(예: 홈페이지 및 기사 페이지)을 모두 테스트했습니다. 지연 로드가 사용 설정된 페이지와 그렇지 않은 페이지의 조합을 각각 테스트하고 각 테스트를 9번 실행하여 LCP 중앙값과 이미지 바이트 수를 얻었습니다.

위 결과에서는 보관 파일 테스트와 데스크톱 및 모바일의 단일 페이지 테스트의 LCP 중앙값을 밀리초 단위로 비교한 것입니다. 보관 파일 페이지에서 지연 로드를 사용 중지한 후 LCP가 상당한 격차를 보였습니다. 그러나 단일 페이지에서는 차이가 더 중립적입니다.

지연 로드를 사용 중지하면 단일 페이지가 약간 빨라지는 것처럼 보입니다. 하지만 데스크톱 테스트와 모바일 테스트에서 LCP의 차이는 표준 편차가 1보다 작으므로 편차가 원인이며 변동이 전체적으로 중립적인 것으로 간주합니다. 이에 비해 자료실 페이지의 표준 편차는 2~3에 가깝습니다.

위 결과는 각 테스트의 이미지 바이트 중앙값 수 (KB)를 비교합니다. 예상대로 지연 로드는 이미지 바이트 수를 줄이는 데 매우 분명한 긍정적인 영향을 미칩니다. 실제 사용자가 전체 페이지를 아래로 스크롤하면 모든 이미지가 표시 영역으로 넘어가면서 어차피 로드되겠지만 이러한 결과는 초기 페이지 로드 성능이 개선된 것을 보여줍니다.

A/B 테스트의 결과를 요약하자면, WordPress에서 사용하는 지연 로드 기술은 이미지 바이트를 줄이는 데는 매우 도움이 되지만 LCP 지연 대가를 치러야 합니다.

수정 테스트

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

이 새로운 데이터를 고려하여 스크롤 없이 볼 수 있는 부분에 있는 이미지의 지연 로드를 방지하는 실험용 수정사항을 만들었으며 첫 번째 A/B 테스트와 동일한 조건에서 테스트했습니다.

이러한 결과는 훨씬 더 유망합니다. 스크롤해야 볼 수 있는 부분의 이미지만 지연 로드하면 LCP 회귀가 완전히 반전되고 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});

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

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

결론

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

상대적으로 새로운 웹 플랫폼 API를 사용하면 위험과 보상이 수반될 수 있는데, 이를 최첨단 기능이라고 부르는 데는 이유가 있습니다. 네이티브 이미지 지연 로드의 결함을 파악하기 시작하면서 성능 개선을 위해 이를 사용하는 방법의 좋은 점도 확인했습니다.

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