지연 로딩

요약 — 지연 로딩은 사용자가 이미지나 임베드 근처까지 스크롤할 때까지 브라우저가 다운로드를 미루게 해 초기 페이지 로드를 빠르게 합니다. 코드를 쓰지 않는 쉬운 방법은 <img>나 <iframe>에 loading="lazy"를 추가하는 것입니다. 꼭 기억할 규칙은 페이지 상단의 큰 이미지를 지연 로드하지 않는 것입니다. 그렇게 하면 더 빠른 것이 아니라 더 느리게 느껴집니다.

지연 로딩이란?

브라우저는 보통 페이지를 열면 모든 이미지와 임베디드 지도·동영상을 즉시 다운로드하려 합니다. 이미지가 많은 긴 페이지에서는 사용자가 끝내 스크롤해 보지 않을 항목까지 대량으로 다운로드하게 됩니다.

지연 로딩은 화면 밖 이미지와 임베드가 뷰포트 가까이 올 때까지 로드를 미룹니다. 페이지 상단은 빨리 표시되고 나머지는 스크롤에 맞춰 로드됩니다. 초기 데이터가 줄어 첫인상이 빨라지고 대역폭과 배터리도 절약되므로 특히 휴대전화에서 유용합니다.

쉬운 방법: loading 속성

예전에는 JavaScript 라이브러리가 필요했지만 현대 브라우저에는 기능이 내장돼 있습니다. 속성 하나만 추가하세요.

<img src="photo.jpg" loading="lazy" alt="…">

이것으로 끝입니다. 모든 주요 브라우저에서 JavaScript 없이 <img>와 <iframe>(YouTube 동영상, Google 지도, 소셜 위젯 등)에 작동합니다.

피해야 할 한 가지 실수

사람이 가장 먼저 보는 히어로 이미지처럼 페이지 상단의 큰 이미지는 지연 로드하지 마세요. 지연 로딩은 브라우저에 ‘기다려도 된다’고 알리므로 상단 이미지가 필요한 때보다 늦게 로드돼 페이지가 느리게 느껴집니다. Google도 페이지를 열자마자 보이는 항목에는 지연 로딩을 건너뛰라고 안내합니다.

간단히 말해 첫 화면 아래 항목은 지연 로드하고 첫 화면 위 항목은 정상 로드하세요.

SEO에 해로운가요?

그 자체로는 아닙니다. 일반적인 방식으로 구현하면 Google은 지연 로드 이미지와 콘텐츠를 문제없이 색인합니다. 검색엔진은 스크롤하거나 클릭하지 않으므로 콘텐츠를 그런 동작 뒤에 숨길 때만 문제가 됩니다. 이미지에 loading="lazy"를 쓰는 정도라면 괜찮습니다. Google이 이를 보는 방식과 확인법은 고급 탭을 참고하세요.

요약 — 지연 로딩은 화면 밖 이미지와 iframe이 뷰포트에 가까워질 때까지 미뤄 초기 페이지 용량(LCP 개선)과 시작 시 메인 스레드 작업(INP 개선)을 줄입니다. <img>/<iframe>의 기본 loading="lazy" 속성이 대부분의 JS 라이브러리를 대체했으며 의미 있는 값은 lazy와 eager뿐이고 auto는 폐기됐습니다. 치명적인 실수는 LCP·첫 화면 이미지를 지연 로드해 개선하려는 지표 자체를 늦추는 것과, Googlebot이 페이지와 상호작용하지 않으므로 실행하지 않는 스크롤·클릭 뒤에 콘텐츠를 두는 것입니다. 직접 순위 요소는 아니며 Core Web Vitals와 크롤링 가능성을 통해 간접적으로 작용합니다. Search Console URL 검사 도구에서 이미지 URL이 렌더링 HTML의 src 속성에 들어갔는지 확인하세요.

지연 로딩이 실제로 하는 일

원리는 간단합니다. 모든 리소스를 한꺼번에 로드하지 않고 필요할 때만 로드합니다. 미디어가 많은 페이지에서 모든 이미지와 임베드를 먼저 다운로드하면 방문자가 보지 않을 항목 때문에 대역폭·메모리·배터리를 낭비합니다. 화면 밖 항목을 미루면 첫 화면 콘텐츠가 더 빨리 그려집니다. Martin Splitt도 Google Search Off the Record의 ‘지연 로딩 해부’ 에피소드에서 페이지에 없어도 되는 중요하지 않은 이미지가 브라우저를 계속 바쁘게 하므로 결과를 만들지 않는 작업을 피하는 것이 목표라고 설명했습니다.

이는 많은 사람이 개선하려는 Core Web Vitals와 연결됩니다. 초기 네트워크 경합이 줄면 Largest Contentful Paint 요소가 더 빨리 렌더링됩니다. 광고·소셜 위젯·댓글·지도 iframe을 미루면 시작 시 메인 스레드 작업도 줄어 LCP뿐 아니라 Interaction to Next Paint도 개선됩니다. Google web.dev도 페이지 로드 중 iframe 지연 로딩을 INP 개선으로 설명합니다.

기본 지연 로딩과 JavaScript 방식 비교

몇 년 전 브라우저에 이미지·iframe용 기본 loading 속성이 생겨 JavaScript API를 직접 연결하지 않고 브라우저에 맡길 수 있게 됐습니다. Ahrefs의 JavaScript SEO 안내서에서도 처음 글을 쓴 뒤 지연 로딩이 대체로 JavaScript 방식에서 브라우저 처리 방식으로 이동했다고 설명했습니다. JS 방식도 여전히 보이며 이미지에는 보통 문제없습니다. 실제 콘텐츠까지 지연 로드하는지 확인해야 하는 이유는 그런 구현에서 콘텐츠가 올바르게 수집되지 않은 사례가 있기 때문입니다.

기본 구현은 다음과 같습니다.

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

지연 이미지에는 명시적인 width/height 또는 종횡비를 설정해 로드 전에 공간을 예약하세요. 이미지 지연으로 인한 가장 큰 레이아웃 이동 위험입니다. 다만 크기를 예약했다고 CLS가 절대 발생하지 않는 것은 아닙니다. 주변 레이아웃이나 반응형 자르기가 로드 뒤 바뀌면 이동할 수 있으므로 고정 크기만 믿지 말고 실제 레이아웃 이동 트레이스로 확인하세요.

iframe 지연 로딩에는 한 가지 구분이 더 필요합니다. <iframe>의 loading="lazy"는 임베드 가져오기와 생성 시점만 미룹니다. title, 포커스 동작, sandbox, allow/권한 정책, referrerpolicy, 동의 처리, 크기는 별도로 설정해야 합니다. 임베드가 로드 대상이 된 뒤에도 스크립트·추적 픽셀·레이아웃 작업을 계속할 수 있습니다. 또한 ‘첫 화면 아래’가 어디서나 같다고 가정하지 마세요. display: none 콘텐츠, 화면 밖 캐러셀 슬라이드, 변형된 요소, 중첩 스크롤 컨테이너는 일반 요소와 다르게 뷰포트와 교차할 수 있으므로 실제 레이아웃과 탐색 제어를 테스트하세요.

loading 속성 값

현재 중요한 값은 두 가지입니다.

• loading="lazy" — 리소스가 뷰포트 가까이 올 때까지 미룹니다.
• loading="eager" — 기본 동작대로 즉시 로드합니다. 첫 화면 이미지임을 명시할 때 사용하세요.

예전 문서에서 loading="auto"를 볼 수 있지만 Chrome에서는 폐기됐으므로 사용하지 마세요. 속성을 생략하면 이미 기본 eager 동작을 하므로 필요하지 않습니다.

‘가깝다’는 어느 정도일까요? loading="lazy"는 힌트이지 작성자가 통제하는 보장이 아닙니다. 사양은 실제 뷰포트 근접 판단을 브라우저에 맡깁니다. Chromium은 스크롤 시점에 준비되도록 미리 가져오려 하지만 트리거 거리는 브라우저·연결 속도·리소스 유형에 따라 달라지며 브라우저나 버전을 넘어 의존할 수 있는 고정 픽셀 값이 아닙니다. ‘뷰포트 전 N픽셀에서 로드’ 같은 수치를 게시하거나 믿지 말고 구현 정의된 창으로 취급해 대상 브라우저·연결의 Network 트레이스로 확인하세요.

기본 지연 로딩은 반응형 이미지와도 잘 작동합니다. 일반 src와 srcset/sizes 선택에 적용되므로 loading="lazy"를 추가해도 반응형 이미지 동작을 잃지 않습니다. 실제 URL을 data-* 속성에만 숨겨 스크립트가 나중에 바꾸게 하면 해당 스크립트에 로딩이 의존합니다. 렌더링 HTML과 스크립트 실패 시 동작을 테스트하세요(스크립트·문제 해결 탭 참조).

#1 실수: LCP / 첫 화면 이미지 지연 로딩

가장 자주 보는 실패이며 모든 출처가 같은 결론을 냅니다. 히어로 이미지나 LCP 요소일 가능성이 있는 이미지를 지연 로드하면 체감 로딩 속도에서 가장 중요한 픽셀을 기다리라고 브라우저에 알리는 셈입니다. 브라우저는 이미지가 페이지 어디에 놓일지 알아야 지연 로드할 수 있어 첫 화면 이미지는 eager 이미지보다 더 느려지기 쉽습니다. 이는 Google이 로드 후 첫 2,5초 안에 완료해야 한다고 설명한 Largest Contentful Paint를 직접 늦춥니다.

Splitt는 SOTR 에피소드에서 반대 상황도 분명히 설명했습니다. 필요한 곳에서 지연 로딩을 쓰지 않으면 Core Web Vitals의 일부, 대개 LCP가 나빠질 수 있습니다. 즉 양쪽 모두에 적용되는 규칙은 다음과 같습니다.

• 가능성이 높거나 관찰된 LCP 후보 → eager로 로드합니다(loading="lazy" 생략 또는 eager 설정). LCP 이미지에는 fetchpriority="high"도 고려하세요.
• 첫 화면 아래 → loading="lazy"를 사용합니다.

첫 화면의 모든 이미지가 LCP 후보는 아닙니다. Performance 트레이스나 PageSpeed Insights로 실제 후보를 찾고 요청 시점을 확인하세요. 이들은 하나의 설정이 아니라 별도 힌트입니다. loading="eager" 또는 loading 생략은 리소스 발견을 미루지 않는다는 뜻일 뿐 가져오기 우선순위를 높이지 않습니다. fetchpriority가 별도의 권고 힌트입니다. 같은 리소스에 <link rel="preload"> with loading="lazy"를 함께 쓰면 상충하는 의도를 전달하므로 조합이 기대대로 작동한다고 가정하지 말고 네트워크 폭포수를 확인하세요.

사이트 전체의 모든 이미지에 지연 로딩을 켜는 CMS 기본값이 대표적인 안티패턴입니다. Splitt가 지적했듯 모든 이미지를 지연 로드하면 즉시 보여야 하는 이미지까지 지연되므로 피해야 할 상황을 만듭니다.

Googlebot이 지연 로드 콘텐츠를 렌더링하는 방식

자주 놓치는 크롤링 현실은 Googlebot이 스크롤하거나 클릭하지 않는다는 것입니다. 헤드리스 브라우저로 페이지를 렌더링하지만 사용자 상호작용을 흉내 내지 않습니다. Google은 권장 방식이 스크롤·클릭 같은 사용자 동작에 의존하지 않는 이유를 Google 검색이 페이지와 상호작용하지 않기 때문이라고 직접 설명합니다.

따라서 구현 방식이 중요합니다. Google 문서는 이미지·iframe의 브라우저 내장 지연 로딩, 폴리필을 포함한 IntersectionObserver API, 데이터가 뷰포트에 들어올 때 로드하는 JavaScript 라이브러리의 세 안전한 방식을 제시합니다. 모두 Googlebot이 실행하지 않을 스크롤·클릭 이벤트가 아니라 뷰포트 교차를 기준으로 합니다.

위험이 큰 패턴은 맞춤형 또는 서드파티 JS 지연 로드 라이브러리입니다. 오작동해 이미지 URL이 src 속성에 들어가지 않으면 Google은 이미지를 수집하지 못합니다. Splitt도 SOTR에서 이 실패를 설명했습니다. URL이 없으면 색인할 것도 없습니다. JavaScript SEO 안내서에서도 이미지 지연 로딩은 보통 괜찮지만 지연 로드 콘텐츠에서 색인 문제가 생기므로 Google의 실제 렌더링 결과를 확인하라고 설명합니다.

무한 스크롤은 다른 문제

기본 이미지·iframe 지연 로딩과 무한 스크롤 또는 페이지 단위 로딩을 혼동하지 마세요. 이미지를 미루는 것과 사용자가 스크롤할 때 새 콘텐츠 묶음을 로드하는 것은 별개이며 자체 구조가 필요합니다. Google은 각 묶음에 지속적이고 고유한 URL을 주고 URL별 콘텐츠를 안정적으로 유지하며(?date=yesterday 같은 상대값이 아니라 ?page=12 같은 절대 페이지 번호), 각 묶음이 주로 보이는 콘텐츠가 될 때 History API로 표시 URL을 갱신해 새로고침·공유·링크가 가능하게 하라고 안내합니다. 이를 생략하면 끝없는 스크롤 뒤 콘텐츠가 안정적으로 크롤링·색인되지 않을 수 있습니다.

테스트 방법

Google 문서와 이 방법론의 검증 경로는 같습니다. Search Console URL 검사 도구에서 렌더링된 HTML을 확인하세요. 해당 HTML의 <img>/<video> 요소 src 속성에 이미지나 동영상 URL이 있으면 정상입니다. Google도 check the rendered HTML to make sure your content is in it (번역) 「렌더링된 HTML에 콘텐츠가 있는지 확인하세요」라고 명시합니다. src에서 URL이 빠졌다면 대개 스크롤·클릭 트리거나 고장 난 라이브러리가 원인입니다.

지연 로드 상품 그리드는 존재 여부 확인을 넘어야 합니다. 표준·높은 뷰포트, 새 탐색·로드 후 크기 조정, 무동작·점진 스크롤 실행, 고유 상품 링크 수, 접근성 트리 검사를 포함한 무한 스크롤 SEO 테스트 매트릭스를 실행하세요. 관찰자와 배치 계산이 시작 시에만 등록될 수 있으므로 초기화된 페이지 크기를 바꾸는 것은 최종 뷰포트 크기로 탐색하는 것과 같지 않습니다. Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: 2026-07-14 Google Search Central: Lazy-load content

웹 성능 도구도 활용할 수 있습니다. PageSpeed Insights는 지연해야 할 화면 밖 이미지를 표시합니다. Ahrefs PageSpeed Insights 안내서에서 ‘화면 밖 요소 지연’ 감사가 이미지 지연 로딩을 요청하는 것이라고 설명했듯 기존 진단을 해결책과 연결하기 좋습니다.

순위 신호에 대한 정직한 설명

지연 로딩의 역할을 명확히 하세요. 사용하는 것이 직접 순위 요소가 아니며 사용하지 않는다고 불이익을 받지도 않습니다. 순위와의 관계는 주로 LCP, iframe의 경우 INP 같은 Core Web Vitals와, 잘못된 구현이 콘텐츠를 숨길 때의 크롤링 가능성을 통해 간접적으로 생깁니다. Splitt는 Core Web Vitals를 통한 순위 효과가 대부분 매우 작다고 설명했습니다. 속성 하나로 순위가 오른다고 기대하지 말고 사용자 로딩 경험과 명확한 색인을 위해 최적화하세요.

관련 영역

지연 로딩은 더 넓은 웹 성능 도구 중 하나입니다. 일찍 필요한 리소스를 위한 preload/preconnect 같은 리소스 힌트, 글꼴 로딩 전략, 캐싱, CDN과 함께 사용하며 최종적으로 Core Web Vitals로 평가합니다. 첫 화면 위·아래 구분만 올바르게 해도 비용 대비 효과가 큰 개선입니다.

AI 요약

고급 버전을 압축하면 다음과 같습니다.

• 지연 로딩은 화면 밖 이미지와 iframe이 뷰포트 가까이 올 때까지 미뤄 초기 페이지 용량과 시작 작업을 줄입니다. JS 없는 기본 방식은 <img>·<iframe>의 loading="lazy"이며 대부분의 JS 라이브러리를 대체했습니다. 브라우저 힌트이지 거리·시점 보장이 아니므로 고정 픽셀 수에 의존하지 마세요.
• 값: lazy와 eager만 중요하며 Chrome에서 auto는 폐기됐습니다.
• Core Web Vitals 관계: 초기 바이트 감소는 LCP, iframe 지연은 시작 메인 스레드 작업을 줄여 INP를 돕습니다. 지연 이미지가 CLS를 만들지 않도록 width/height를 설정하되 주변 레이아웃이 바뀌면 예약 크기만으로 이동을 완전히 막을 수 없습니다.
• #1 실수: 단순히 첫 화면의 모든 이미지가 아니라 가능성이 높거나 관찰된 LCP 이미지를 지연 로드하는 것입니다. Google의 2,5s LCP 목표를 늦춥니다. eager나 loading 생략은 발견에만 영향을 주며 우선순위는 높이지 않습니다. fetchpriority는 별도 힌트이고 같은 리소스에 preload와 loading="lazy"를 함께 쓰면 충돌합니다. 사이트 전체 지연 로딩은 흔한 CMS 안티패턴입니다.
• iframe의 별도 계약: loading="lazy"는 가져오기·생성 시점만 미룹니다. title, sandbox, 권한·리퍼러 정책, 동의, 크기는 따로 설정해야 하며 숨김·캐러셀·변형 레이아웃은 일반적인 첫 화면 아래 요소와 다르게 교차할 수 있습니다.
• Googlebot은 스크롤하거나 클릭하지 않습니다. 스크롤·클릭 이벤트 뒤 콘텐츠는 보이지 않을 수 있습니다. Google의 안전한 방식인 기본 지연 로딩, IntersectionObserver, 정상 동작하는 JS 라이브러리는 모두 뷰포트 교차를 사용합니다.
• 가장 큰 위험: 맞춤형·서드파티 JS 라이브러리입니다. URL이 src에 들어가지 않으면 Martin Splitt 설명대로 Google이 이미지를 색인하지 않습니다.
• 무한 스크롤은 별개이며 고유한 페이지 URL과 History API가 필요합니다.
• Search Console URL 검사 → 렌더링 HTML → src 속성의 이미지 URL 순서로 검증하세요.
• 직접 순위 요소가 아닙니다. Core Web Vitals와 크롤링 가능성을 통한 간접 효과이며 Splitt는 CWV 순위 효과가 작다고 설명했습니다.

공식 문서

검색엔진과 Google web.dev의 1차 출처 안내입니다.

Google — Search Central

• 지연 로드 웹사이트 콘텐츠 수정 — 안전한 구현 방식, ‘Google은 페이지와 상호작용하지 않는다’는 규칙, 무한 스크롤·페이지 단위 로딩 요건, 렌더링 HTML 검증을 담은 공식 문서
• JavaScript SEO 기본 이해 — 대역폭·성능 모범 사례로 이미지 지연 로딩을 권장하고 전용 안내서 연결
• Core Web Vitals — LCP 요소 지연 로딩이 역효과인 이유와 2,5s LCP 목표

Google — web.dev(Learn Performance)

• 이미지와 <iframe> 요소 지연 로드 — 지연 시점과 iframe 지연의 INP 이점
• 웹의 브라우저 수준 이미지 지연 로딩 — 기본 속성과 뷰포트 내·LCP 이미지를 지연하지 말아야 하는 이유
• 화면 밖 iframe을 지연 로드할 때입니다 — 광고·위젯·지도 등 iframe 사례
• CMS용 브라우저 수준 지연 로딩 — CMS 플랫폼 안내

Google — 팟캐스트

• Search Off the Record — 98화, ‘지연 로딩 해부’(2025년 8월 21일) — John Mueller와 Martin Splitt가 설명하는 지연 로딩, 렌더링, 색인, Core Web Vitals. Google Search Off the Record 페이지에도 색인돼 있습니다.

개발자 참고 자료(API의 권위 있는 비 SEO 문서)

• MDN — 지연 로딩(성능 안내)
• MDN — HTMLImageElement: loading 속성
• caniuse — 이미지·iframe 속성 지연 로딩

Bing / Microsoft

• Bing은 지연 로딩 전용 문서를 제공하지 않습니다. 일반 웹마스터 가이드라인은 크롤링과 JS 렌더링을 폭넓게 다룹니다. Bingbot은 Chromium 기반 헤드리스 브라우저로 렌더링하고 Googlebot처럼 스크롤하거나 클릭하지 않으므로 Google을 충족하는 기본 loading="lazy" / IntersectionObserver 접근 방식이 Bing에도 맞을 가능성이 큽니다. 마지막 내용은 Bing의 일반 렌더링 동작에서 추론한 것이며 지연 로딩에 관한 Bing의 공식 발언은 아니므로 그렇게 취급하세요.

출처 인용

Google 공식 문서의 기록상 발언입니다. 각 링크는 출처 페이지의 인용 구절로 바로 이동합니다.

Google Search Central, “지연 로드 웹사이트 콘텐츠 수정”

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (번역) 「중요하지 않거나 보이지 않는 콘텐츠의 로드를 미루는 지연 로딩은 일반적인 성능·UX 모범 사례입니다.」 인용으로 이동
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (번역) 「잘못 구현하면 Google에 콘텐츠가 의도치 않게 숨겨질 수 있으며, 이 문서는 Google이 지연 로드 콘텐츠를 크롤링·색인하도록 확인하는 방법을 설명합니다.」 인용으로 이동
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (번역) 「Google 검색은 페이지와 상호작용하지 않으므로 이 방식들은 콘텐츠를 로드하기 위해 스크롤·클릭 같은 사용자 동작에 의존하지 않습니다.」 인용으로 이동
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (번역) 「페이지를 열 때 즉시 보일 가능성이 높은 콘텐츠에는 지연 로딩을 추가하지 마세요. 브라우저 표시가 늦어져 사용자에게 뚜렷이 느껴질 수 있습니다.」 인용으로 이동
• “Give each chunk its own persistent, unique URL.” (번역) 「각 콘텐츠 묶음에 지속적이고 고유한 URL을 부여하세요.」 — 무한 스크롤 / 페이지 단위 로딩 인용으로 이동

지연 로딩 체크리스트

지연 로딩 변경을 출시하기 전에 실행하세요.

• 히어로 / LCP 이미지는 지연 로드하지 않고 eager로 로드합니다(loading="lazy" 생략). 가능하면 fetchpriority="high"도 사용합니다.
• 첫 화면 아래 이미지와 iframe에 loading="lazy"를 적용합니다.
• 지연 이미지에 명시적인 width/height 또는 aspect-ratio가 있어 로드 시 레이아웃 이동(CLS)을 만들지 않습니다.
• 스크롤·클릭 이벤트 뒤에 콘텐츠를 두지 않습니다. Googlebot은 이를 실행하지 않으므로 기본 지연 로딩이나 IntersectionObserver를 사용합니다.
• 폐기된 loading="auto"를 사용하지 않고 lazy/eager만 사용합니다.
• 화면 밖 iframe(임베드·광고·지도·위젯)에 loading="lazy"를 사용해 시작 메인 스레드 작업을 줄입니다.
• 지연 iframe에도 자체 title, sandbox, allow/권한 정책, referrerpolicy, 명시적 크기가 있습니다. loading="lazy"는 가져오기 시점만 미룹니다.
• Search Console URL 검사 → 렌더링 HTML에서 이미지·동영상 URL이 src 속성에 있는지 확인했습니다.
• 서드파티 JS 지연 로드 라이브러리를 쓴다면 렌더링 HTML에서 src가 채워지는지 확인했습니다.
• 무한 스크롤의 각 묶음에 고유하고 지속적인 페이지 URL이 있고 History API가 표시 URL을 갱신합니다.
• PageSpeed Insights의 ‘화면 밖 이미지 지연’ 표시를 처리했습니다.

지연 로딩 안티패턴(오해와 실수)

흔한 믿음이나 습관이 왜 잘못됐고 무엇을 대신 해야 하는지 설명합니다.

“지연 로딩은 언제나 좋으니 모든 이미지에 적용한다.” 잘못된 이유: 사이트 전체 지연 로딩은 히어로/LCP 이미지까지 포함해 원하는 속도 개선과 반대로 Largest Contentful Paint를 늦춥니다. 대신: 첫 화면 아래만 지연 로드하고 첫 화면 이미지는 eager로 로드하세요.

“Google은 지연 로드 콘텐츠를 전혀 색인하지 않는다.” 잘못된 이유: 기본 지연 로딩, IntersectionObserver, 정상 라이브러리로 구현하면 Google은 문제없이 크롤링·색인합니다. Google 표현대로 “not implemented correctly” (번역) 「올바르게 구현되지 않은」 스크롤·클릭 의존 또는 고장 난 구현만 위험합니다. 대신: 뷰포트 교차 방식을 사용하고 렌더링 HTML에서 확인하세요.

“loading='auto'는 좋은 기본값이다.” 잘못된 이유: Chrome에서 auto는 폐기됐으므로 오래된 조언입니다. 대신: 화면 밖 리소스에는 lazy, 나머지에는 eager 또는 속성 생략을 사용하세요.

“지연 로딩과 무한 스크롤은 같은 해결책이다.” 잘못된 이유: 둘은 다릅니다. 무한 스크롤에는 고유한 페이지 URL과 History API 갱신도 필요하며 그렇지 않으면 깊은 콘텐츠가 안정적으로 크롤링되지 않을 수 있습니다. 대신: 묶음별 URL을 갖춘 별도 페이지·무한 로딩 구조로 취급하세요.

“loading='lazy'는 모든 요소에서 작동한다.” 잘못된 이유: <img>와 <iframe>에 규정된 속성입니다. 다른 요소 지원은 같은 방식의 핵심 사양에 속하지 않습니다. 대신: 이미지와 iframe에 사용하고 다른 미디어에는 적절한 방식을 쓰세요. 동영상은 포스터 이미지를 사용하고 뷰포트 진입 시 로드할 수 있습니다.

“지연 로딩은 SEO에 해롭다.” 잘못된 이유: 지연 로딩 자체는 불이익이 아닙니다. 순위 관련 효과는 작고 Core Web Vitals를 통해 생기며, 기법이 아니라 나쁜 구현이 문제입니다. 대신: 올바르게 구현하고 LCP 이미지를 제외하며 렌더링 결과를 확인하세요.

지연 로딩 요약표

loading 속성

지원 요소

• <img> — 지원
• <iframe> — 지원
• 다른 요소(동영상/오디오) — 같은 방식의 핵심 사양에는 포함되지 않습니다. 동영상에는 포스터 이미지 + 뷰포트 진입 시 로드 패턴을 사용하세요.

첫 화면 위와 아래

• 첫 화면 위 / LCP 가능성 높음 → eager(절대 lazy 금지). LCP 이미지에 fetchpriority="high"를 추가합니다.
• 첫 화면 아래 → lazy

Core Web Vitals 영향

• 화면 밖 이미지 지연 → 초기 네트워크 경합을 줄여 LCP 개선
• 화면 밖 iframe 지연 → 시작 메인 스레드 작업을 줄여 INP 개선
• 지연 이미지의 width/height 누락 → 로드 시 레이아웃 이동으로 CLS 악화 가능

Googlebot이 중요하게 보는 규칙

• Googlebot은 스크롤하거나 클릭하지 않으므로 그런 동작 뒤에 콘텐츠를 두지 않습니다.
• 안전한 방식: 기본 loading="lazy", IntersectionObserver, 정상 JS 라이브러리
• 검증: URL 검사 → 렌더링 HTML → src 속성의 이미지 URL
• 무한 스크롤 ≠ 이미지 지연 로딩. 고유 페이지 URL + History API 필요

변경 전 / 후

감사에서 발견하는 방식으로 구체적인 개선을 설명합니다.

1. 히어로 이미지가 지연 로드됨(LCP 지연)

변경 전:

<img src="hero.jpg" loading="lazy" alt="Product hero">

변경 후:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

이유: 히어로가 LCP 요소이므로 eager로 로드하고 우선 처리하면 더 빨리 그려집니다. 지연 로딩은 반대 효과를 냅니다.

2. CMS 기본값이 사이트 전체에 지연 로딩 적용

변경 전: 헤더 로고와 페이지 상단 대표 이미지를 포함해 템플릿의 모든 <img>에 loading="lazy"가 있습니다. 변경 후: 첫 화면 이미지는 eager로 로드하고 초기 뷰포트 아래 이미지에만 loading="lazy"를 적용합니다. 이유: 전체 지연 로딩은 즉시 보이는 이미지까지 늦춰 사용자가 처음 보는 내용과 LCP를 지연합니다.

3. 화면 밖 임베드를 페이지 로드 때 불러옴

변경 전:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

변경 후:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

이유: 지도가 첫 화면 아래에 있으므로 미루면 시작 비용을 없애고 임베드의 로드 중 메인 스레드 작업을 줄여 INP를 개선합니다.

4. 맞춤 JS 지연 로드가 Googlebot의 src를 비워 둠

변경 전: 라이브러리가 실제 URL을 data-src에 저장하고 스크롤 이벤트에서 src로 옮깁니다. Googlebot은 이벤트를 실행하지 않아 렌더링 HTML의 src가 비거나 자리표시자만 남습니다. 변경 후: 처음부터 실제 URL을 src에 둔 기본 loading="lazy" 또는 IntersectionObserver 기반 라이브러리를 사용하고 URL 검사에서 렌더링 src에 URL이 있는지 확인합니다. 이유: 렌더링 HTML의 src에 URL이 없으면 Google은 이미지를 수집할 수 없습니다.

지연 로드해야 하거나 하지 말아야 할 이미지 찾기

모든 페이지에서 loading 속성을 감사할 수 있는 DevTools Console 코드입니다. 이미지의 loading 값과 현재 뷰포트 포함 여부를 나열해 첫 화면인데 lazy인 이미지나 첫 화면 아래인데 지연되지 않는 이미지를 찾습니다.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

위험한 지연 로드 패턴을 소스에서 검색

템플릿과 빌드 출력에서 폐기된 auto 값과 Googlebot의 src를 비워 둘 수 있는 data-src 방식 JS 지연 로딩을 확인하세요.

macOS / Linux(bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows(PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

data-src 자체가 항상 문제인 것은 아닙니다. Search Console URL 검사에서 실제 URL이 렌더링된 src에 들어갔는지 확인하라는 신호입니다.

지연 로딩을 켠 뒤 히어로 이미지가 늦게 시작됨

증상: LCP가 느려지고 폭포수에서 히어로 요청이 늦게 시작됩니다.

가능한 원인: 전역 CMS 규칙이 첫 화면 또는 LCP 이미지에 loading="lazy"를 추가했습니다.

해결과 확인: 해당 이미지에서 lazy 속성을 제거하고 필요하면 fetchpriority="high"를 추가한 뒤 같은 조건의 트레이스에서 요청이 더 일찍 시작되는지 확인합니다.

지연 이미지가 나타나지만 페이지가 이동함

증상: 지연 이미지가 뷰포트에 들어올 때 콘텐츠가 움직입니다.

가능한 원인: 이미지에 명시적 크기나 예약 종횡비가 없습니다.

해결과 확인: width와 height 속성을 추가하거나 CSS에서 같은 종횡비를 예약합니다. 레이아웃 이동 영역 표시를 켜고 다시 로드해 주변 콘텐츠가 더 이상 움직이지 않는지 확인하세요.

Google이 지연 콘텐츠를 보지 못함

증상: 사람이 스크롤한 뒤 나타나는 이미지 URL이나 콘텐츠가 렌더링 검사에서 빠집니다.

가능한 원인: Googlebot에서 스크롤·클릭 핸들러가 실행되지 않거나 지연 라이브러리가 실제 URL을 렌더링 src가 아닌 data-src에 남겨 둡니다.

해결과 확인: 기본 지연 로딩 또는 IntersectionObserver 기반 구현을 사용한 뒤 렌더링 HTML에서 상호작용 없이 최종 URL과 콘텐츠가 있는지 확인합니다.

화면 밖 임베드가 여전히 즉시 로드됨

증상: 지연 로딩 변경 뒤에도 첫 화면 아래 iframe이 초기 폭포수에 나타납니다.

가능한 원인: 배포된 iframe에 속성이 없거나 래퍼가 eager로 만들거나 브라우저 로드 기준상 임베드가 뷰포트에 충분히 가깝습니다.

해결과 확인: 라이브 DOM과 요청 initiator를 확인하고 콜드 캐시의 긴 페이지에서 테스트해 브라우저의 뷰포트 근접 기준까지 요청이 지연되는지 확인합니다.

구현·입증 도구

• Chrome DevTools Elements·Network 패널: 배포된 loading 속성, iframe을 만든 스크립트, 변경 전후 요청 시작 시점을 확인합니다.
• Chrome DevTools Performance 패널: 로드를 기록해 임베드 지연이 LCP 이미지를 늦추지 않으면서 시작 메인 스레드 작업을 줄이는지 확인합니다.
• PageSpeed Insights: 화면 밖 이미지 진단을 출발점으로 사용한 뒤 실제 첫 화면 아래 후보와 히어로 등 즉시 콘텐츠를 구분합니다.
• Search Console URL 검사: 렌더링 HTML에서 지연 이미지 URL이 src에 들어가고 스크롤·클릭 없이 지연 콘텐츠가 존재하는지 확인합니다.
• 브라우저 뷰포트와 필름스트립: 여러 뷰포트 크기를 테스트합니다. 데스크톱의 첫 화면 아래 이미지가 더 작거나 모양이 다른 기기에서는 첫 화면 위일 수 있습니다.

첫 화면 아래 이미지 지연

실행할 테스트: 초기 뷰포트보다 한참 아래 이미지에 기본 지연 로딩을 추가하기 전후의 콜드 로드 Network 트레이스를 기록합니다.

예상 결과: 초기 중요 폭포수에 이미지 요청이 없고 뷰포트가 가까워질 때 시작됩니다.

실패 해석: 배포 마크업에 속성이 없거나 JavaScript가 이미지를 eager로 만들거나 가져오거나 테스트 이미지가 브라우저의 뷰포트 근접 기준 안에 있습니다.

모니터링 기간: 배포 직후 대표 모바일·데스크톱 뷰포트 크기에서 확인합니다.

롤백 조건: 초기 로드 때 보이는 이미지가 지연되거나 사용자가 도달하기 전에 이미지가 자주 나타나지 않으면 되돌립니다.

LCP 이미지 제외

실행할 테스트: 사이트 전체 지연 로딩을 제거한 뒤 페이지 LCP 이미지의 동일 조건 Performance 트레이스와 요청 폭포수를 비교합니다.

예상 결과: LCP 이미지가 eager로 로드되고 요청이 더 일찍 시작되며 LCP가 악화되지 않습니다.

실패 해석: 다른 템플릿·최적화 계층이 속성을 다시 추가하거나 CSS·JavaScript·마크업 때문에 발견이 여전히 늦습니다.

모니터링 기간: 반복 실험실 실행에서 즉시 확인한 뒤 다음 보고 기간 동안 필드 LCP를 관찰합니다.

롤백 조건: 변경이 다른 중요 리소스를 충분히 늦춰 반복 가능한 LCP 악화를 만들면 주변 출시를 되돌립니다.

렌더링 콘텐츠 노출

실행할 테스트: 페이지와 상호작용하지 않고 URL 검사에서 렌더링 HTML을 열어 지연 이미지 URL과 관련 콘텐츠를 검색합니다.

예상 결과: 최종 URL이 src에 나타나고 중요한 콘텐츠가 렌더링 HTML에 있습니다.

실패 해석: 구현이 스크롤·클릭 이벤트에 의존하거나 렌더링 중 지연 로드 스크립트가 실패했습니다.

모니터링 기간: 출시 후와 지연 라이브러리·CMS 이미지 파이프라인 변경 후 영향받는 모든 템플릿을 테스트합니다.

롤백 조건: 색인 가능한 콘텐츠나 이미지 URL이 렌더링 출력에서 사라지면 되돌립니다.

퀴즈: 지연 로딩

Core Web Vitals나 색인을 해치지 않고 이미지·iframe을 미루는 방법에 관한 짧은 문제 다섯 개입니다. 답을 고른 뒤 확인하세요.

볼 만한 자료

관련 글

• JavaScript SEO 문제와 모범 사례 — JS 방식에서 브라우저 기본 지연 로딩으로의 전환과 이미지가 아닌 지연 로드 콘텐츠가 색인 위험인 이유
• SEO·개발자를 위한 Google PageSpeed Insights — ‘화면 밖 이미지 지연’ 감사와 지연 로딩 및 PSI 보고서의 다른 항목 연결
• 기술 SEO 초보자 가이드 — 전체 기술 SEO에서 성능·렌더링의 위치

업계 자료

• 지연 로드 웹사이트 콘텐츠 수정(Google Search Central) — 구현·테스트 공식 문서
• 웹의 브라우저 수준 이미지 지연 로딩(web.dev) — Google 성능 팀의 기본 속성과 LCP 주의점
• 화면 밖 iframe을 지연 로드할 때입니다(web.dev) — iframe 사례와 시작/INP 이점
• 지연 로딩 해부 — Search Off the Record 98화(Google) — Mueller와 Splitt의 지연 로딩·렌더링·색인·Core Web Vitals 전체 에피소드
• 지연 로딩 설명: 사이트와 UX를 빠르게(Search Engine Land) — CMS별 설명이 있는 업계 안내서
• 지연 로딩(성능 안내)(MDN) — API 개발자 참고
• 크롤링·색인 성공을 위한 지연 로딩 입문(Oncrawl) — 크롤링·색인 관점 심층 안내

변경 내역