이미지를 전부 lazy loading으로 바꾸면 빨라질까요? 첫 화면에 보이는 이미지는 일반 로딩을 유지하고, 화면 아래 이미지만 지연 로딩하는 것부터 시작하세요. 모든 이미지에는 맞는 가로·세로 비율의 공간을 미리 확보합니다. 대표 이미지가 늦게 나타나는 문제와 글이 밀리는 문제는 따로 점검해야 합니다.
AI에게 “이미지 최적화해 줘”라고만 맡기면 속성 하나를 전체 이미지에 붙이는 수정으로 끝나기 쉽습니다. 이 글은 공개 기술 문서를 바탕으로 만든 검수용 가이드입니다. 특정 서비스에서 속도를 개선했다는 작업 일지나 성과 보고가 아닙니다. 문서는 2026년 10월 10일에 확인했습니다.
1. 먼저 이미지 세 장의 역할을 정한다
대표 이미지 한 장, 첫 화면의 작은 이미지 한 장, 충분히 아래쪽에 있는 본문 이미지 한 장을 골라 기록하세요. 페이지를 새로 연 직후 스크롤하지 않고 각각 보이는지 확인합니다. “본문 이미지”라는 이름만으로 lazy 여부를 결정하지 마세요. 짧은 제목 아래의 본문 그림은 작은 화면에서도 처음부터 보일 수 있습니다.
- 처음부터 보임: loading="lazy"를 붙이지 않는다. 기존 도구가 자동으로 붙이면 eager로 명시해 제외할 수 있다.
- 처음에는 화면 밖에 있음: loading="lazy" 후보로 분류한다. 브라우저는 화면에 닿기 전부터 가져올 수 있으므로 “보이는 순간에만 다운로드”라고 설명하지 않는다.
- 현재 숨겨져 있고 나중에 열림: 탭·슬라이드의 실제 전환까지 확인한다. 단순히 아래쪽 이미지와 같은 조건이라고 가정하지 않는다.
근거: web.dev의 브라우저 기본 이미지 지연 로딩 안내 ↗
2. loading과 fetchpriority를 한 가지 스위치로 생각하지 않는다
loading은 이미지를 미룰지 결정하는 속성이고, fetchpriority는 가져오기 우선순위에 대한 힌트입니다. eager를 썼다고 다른 이미지보다 무조건 먼저 내려받는 것은 아닙니다. 첫 화면에서 가장 크게 보이는 요소인 LCP가 이미지인지부터 확인한 다음, 그 이미지에 high가 필요한지 판단하세요. 로고나 모든 카드에 high를 일괄로 붙이는 방식은 피합니다.
LCP는 화면 안의 가장 큰 이미지나 텍스트 블록이 표시되는 시점과 관련된 지표입니다. 무조건 페이지의 첫 번째 img가 LCP인 것은 아닙니다. 이미지 파일을 줄여도 서버 응답이나 렌더링 대기 때문에 결과가 거의 달라지지 않을 수 있습니다.
근거: web.dev의 LCP 진단과 리소스 우선순위 설명 ↗
3. 용량을 줄이기 전에 이미지 자리를 예약한다
이미지를 읽은 뒤 높이가 생기면 아래 문단이나 버튼이 움직일 수 있습니다. width와 height에 원본 비율과 맞는 값을 넣고 CSS로 화면에 맞춰 줄이는 방식이 출발점입니다. 예를 들어 1200×800 그림이라면 3:2 비율을 유지합니다. 아래 예제의 숫자와 경로는 설명용이므로 실제 파일에 맞춰 바꾸세요.
<!-- 첫 화면의 대표 이미지: lazy를 사용하지 않는다 -->
<img src="/images/hero.webp"
width="1200" height="800"
alt="작업 노트와 펜이 놓인 책상">
<!-- 첫 화면 밖에 있는 본문 이미지 -->
<img src="/images/detail.webp"
width="1200" height="800"
loading="lazy"
alt="노트에 적은 세 가지 확인 항목">
<style>
img { max-width: 100%; height: auto; }
</style>이 예제는 이미지 두 장의 최소 패턴입니다. 카드에서 일부러 잘라 보여주는 디자인이나 모바일에서 다른 비율의 파일을 쓰는 picture 구성에는 그대로 적용하지 말고 실제 컨테이너 비율도 확인하세요. width·height를 넣었다는 사실보다 로딩 전후에 같은 공간을 차지하는지가 중요합니다.
근거: MDN img 요소의 width·height·loading 속성 ↗
이미지 공간을 확보해도 광고, 웹폰트, 늦게 삽입되는 콘텐츠가 다른 레이아웃 이동을 만들 수 있습니다. 그래서 “width와 height를 넣으면 CLS가 0이 된다”는 완료 조건은 적절하지 않습니다. 이미지가 원인인 이동이 없어졌는지와 페이지 전체의 이동을 나눠 봅니다.
근거: web.dev의 CLS 원인과 이미지 공간 확보 방법 ↗
4. AI에게 전달할 수정 요청 양식
대상 URL: [주소]
대상 화면: [모바일 너비] / [데스크톱 너비]
1) 현재 img 목록과 첫 화면 노출 여부를 먼저 정리해 주세요.
2) 첫 화면 이미지, 특히 실제 LCP 후보는 lazy에서 제외하세요.
3) 화면 아래 이미지에만 기본 loading="lazy"를 적용하세요.
4) 실제 파일 비율에 맞는 width와 height를 확보하세요.
5) high 우선순위는 확인한 핵심 이미지에 한해 검토하세요.
6) alt, 링크, 잘림 방식, 반응형 디자인을 보존하세요.
7) 새 라이브러리 없이 가능한 범위부터 수정하세요.
8) 변경 파일, 전후 조건, 측정값, 미확인 항목을 보고하세요.
금지: 모든 이미지 일괄 lazy / 모든 이미지 high /
측정하지 않은 속도 개선율 주장 / 디자인 비율 임의 변경양식의 빈칸을 먼저 채우면 검토 범위가 작아집니다. 예컨대 상품 상세 페이지라면 대표 사진의 빠른 표시와 설명 이미지의 지연 로딩을 별도 목표로 두세요. AI가 제안한 패키지 설치부터 진행하기보다 HTML만으로 해결되는지 먼저 묻는 편이 변경 원인을 추적하기 쉽습니다.
5. 같은 조건으로 세 번 확인한다
아래 세 번은 반복 횟수에 대한 성능 규칙이 아니라 서로 다른 사용자 행동을 빠뜨리지 않기 위한 검수 순서입니다. 개발자 도구의 캐시·네트워크 조건을 변경했다면 전후 기록에 그대로 적습니다. 실험실 측정 한 번을 실제 이용자 전체의 체감 속도로 바꿔 말하지 않습니다.
- 새로 열기: 스크롤 없이 대표 이미지가 나타나는지, 제목·본문·버튼이 밀리는지 본다.
- 끝까지 스크롤하기: 아래 이미지가 빈칸으로 남지 않는지, 링크와 캡션이 유지되는지 본다.
- 화면 바꾸기: 모바일과 데스크톱에서 다시 새로 열어 첫 화면 대상이 달라지는지 확인한다.
이미지 검수 기록
URL / 빌드:
브라우저 / 화면 너비 / 네트워크 / 캐시:
대표 이미지 경로 / 실제 LCP 요소:
첫 화면 lazy 여부 전 → 후:
예약한 비율 / 실제 표시 비율:
로딩 전후 문단 이동:
아래 이미지 로드·클릭·캡션 확인:
LCP 전 → 후 (측정하지 않았으면 미측정):
CLS 전 → 후 (측정하지 않았으면 미측정):
남은 문제 / 되돌릴 변경:완료 기준은 “속성을 붙였다”보다 구체적으로
- 첫 화면 대표 이미지가 지연 로딩에서 제외돼 있다.
- 화면 아래 이미지가 실제로 로드되고 내용이 누락되지 않는다.
- 이미지 자리가 확보되며 의도하지 않은 비율 변경·잘림이 없다.
- 모바일과 데스크톱 검수 기록이 각각 있다.
- 수치가 없으면 “개선율 미측정”이라고 남긴다. 수치가 악화되면 변경을 분리해 다시 확인한다.
이미지 로딩 검수가 끝났다면 다음에는 키보드로 같은 페이지의 링크와 버튼을 끝까지 써 보세요. 빠르게 보이는 화면과 실제로 조작할 수 있는 화면을 함께 확인해야 배포 전 점검이 마무리됩니다.
