랜딩페이지를 아무리 잘 만들어도 이미지 하나 때문에 전환이 새는 경우가 생각보다 많습니다. 광고비를 태워서 사람을 데려왔는데 첫 화면이 늦게 뜨면, 그 사람은 버튼을 누르기도 전에 뒤로가기를 눌러버리거든요. 우리가 여러 계정을 굴리면서 가장 자주 마주친 누수 지점이 바로 이 이미지 영역이었어요. 오늘은 광고 대행사 입장에서 실제로 손대본 랜딩페이지 이미지 최적화 방법을, 2026년 기준 최신 가이드라인에 맞춰 정리해보려고 합니다.

랜딩페이지 이미지 최적화와 전환율 분석을 보여주는 대표 이미지

왜 지금 랜딩페이지 이미지가 전환을 좌우하는가

사실 몇 년 전만 해도 이미지 최적화는 개발자가 알아서 하는 영역으로 취급받았어요. 마케터는 카피와 오퍼만 신경 쓰면 됐죠. 근데 지금은 분위기가 완전히 달라졌습니다. 구글이 검색 순위와 광고 품질평가에 페이지 경험 신호를 본격적으로 반영하면서, 이미지가 무거운 페이지는 두 군데서 동시에 손해를 봐요. 하나는 검색 노출, 또 하나는 광고 단가.

실제로 모바일 환경에서 첫 화면이 1초 안에 그려지는 페이지와 3초가 걸리는 페이지를 비교해보면, 같은 트래픽을 넣어도 전환율 차이가 20~30% 가까이 벌어지더라고요. 첫인상이 늦으면 광고비가 그만큼 허공으로 날아가는 셈이죠. 이게 우리가 이미지를 단순한 ‘예쁜 장식’이 아니라 ‘전환 자산’으로 보기 시작한 이유입니다.

과거에는 화질 좋은 큰 이미지를 그냥 올리고 끝냈지만, 지금은 화질을 유지하면서도 용량을 줄이는 균형점을 찾는 게 진짜 실력 차이를 만듭니다. 무겁고 선명한 이미지는 누구나 올려요. 가볍고 선명하게 만드는 게 어렵죠.

2026년 코어 웹 바이탈과 이미지 – LCP가 거의 전부다

구글 공식 문서(support.google.com)에서 페이지 경험을 이야기할 때 빠지지 않는 게 코어 웹 바이탈입니다. 그중 랜딩페이지 이미지와 가장 직접적으로 엮이는 지표가 LCP, 그러니까 가장 큰 콘텐츠가 그려지는 시점이에요. 랜딩페이지에서 이 ‘가장 큰 콘텐츠’는 십중팔구 히어로 영역의 대표 이미지입니다.

구글 권장 기준은 LCP를 2.5초 이내로 맞추는 거예요. 우리가 진단을 들어가면 LCP가 4초를 넘기는 페이지의 90% 가까이가 히어로 이미지 용량 때문에 발목을 잡힙니다. 사진 한 장이 1MB를 넘기는 경우도 흔하거든요. 이걸 200~300KB 수준으로 줄이는 것만으로 LCP가 1초 이상 빨라지는 일이 부지기수예요.

빠른 점검 팁 – PageSpeed Insights에 랜딩페이지 주소를 넣고 ‘LCP element’가 무엇인지 먼저 확인하세요. 그 요소가 이미지라면, 최적화 1순위는 무조건 그 이미지 한 장입니다. 나머지 자잘한 건 그다음이에요.

한 가지 더. 2024년 이전에는 FID라는 반응성 지표를 봤는데, 지금은 INP로 바뀌었어요. 이미지 자체가 INP를 망치진 않지만, 무거운 이미지가 메인 스레드를 붙잡으면 간접적으로 사용자 입력 반응이 늦어질 수 있다는 점은 기억해두면 좋습니다.

코어 웹 바이탈 LCP 측정과 이미지 로딩 성능 분석 화면

이미지 포맷 – AVIF와 WebP 중 무엇을 쓸까

포맷 이야기를 안 하고 넘어갈 수가 없어요. 솔직히 아직도 JPG, PNG만 쓰는 랜딩페이지가 너무 많습니다. 2026년 기준으로 우리가 현장에서 권하는 1순위는 AVIF, 2순위는 WebP예요.

AVIF는 같은 화질을 유지하면서 JPG 대비 용량을 절반 가까이 줄여줍니다. 그라데이션이나 사진 톤이 많은 히어로 이미지에서 특히 강해요. 다만 아주 오래된 브라우저나 일부 구형 환경에서 호환이 안 될 때가 있어서, 우리는 보통 AVIF를 먼저 제공하고 WebP를 대체로, 그리고 최후의 안전장치로 JPG를 두는 3단 구조로 깝니다. picture 태그 안에서 source로 포맷을 분기하면 브라우저가 알아서 가능한 포맷을 골라가거든요.

PNG는 어떻게 하냐고요. 로고나 아이콘처럼 투명 배경이 필요한 경우가 아니라면 굳이 PNG를 고집할 이유가 없어요. 사진을 PNG로 올리면 용량이 몇 배로 불어나니까, 사진은 무조건 AVIF나 WebP로 돌리는 게 맞습니다. 근데 SVG가 가능한 단순 그래픽이라면 SVG가 가장 가볍고 선명하니 그쪽을 우선 고려하세요.

지금 운영 중인 랜딩페이지가 이미지 때문에 광고비를 새고 있는 건 아닌지, 한 번쯤 점검받고 싶지 않으세요?

terg.kr 무료 진단을 신청하시면 LCP element부터 포맷 구조까지 우리가 직접 들여다보고 어디서 손해 보는지 짚어드립니다. terg.kr 무료 진단 신청하기

반응형 이미지와 srcset 제대로 쓰기

여기서 의외로 많이들 놓치는 부분이 있어요. 데스크탑 기준으로 만든 1920px짜리 큰 이미지를, 화면이 작은 모바일에도 똑같이 내려보내는 겁니다. 모바일 사용자는 보지도 못할 해상도를 다운받느라 데이터와 시간을 낭비하는 거죠. 광고 트래픽의 상당수가 모바일인 걸 생각하면 이건 꽤 뼈아픈 손실이에요.

해법은 srcsetsizes 속성입니다. 같은 이미지를 여러 너비로 미리 만들어두고, 브라우저가 화면 크기와 픽셀 밀도에 맞춰 적당한 걸 골라가게 하는 방식이에요. 모바일에는 640px, 태블릿에는 1024px, 데스크탑에는 1600px 식으로 끊어두면 각 기기가 필요한 만큼만 받아갑니다.

우리가 한 패션 카테고리 랜딩에서 이걸 적용했더니 모바일 평균 이미지 전송량이 60% 넘게 줄었어요. 화면에 보이는 건 똑같은데 받아오는 양만 가벼워진 거죠. 이런 게 진짜 ‘체감 없는 개선’인데, 숫자로는 확실하게 잡힙니다. 참고로 너비와 높이 속성을 명시해두면 레이아웃이 밀리는 현상도 같이 잡혀서 CLS 점수까지 챙길 수 있어요.

반응형 이미지 srcset 적용으로 기기별 최적 해상도를 제공하는 구조 설명

지연 로딩과 우선순위 – 빠른 첫인상 만들기

이미지를 무조건 빨리 불러오는 게 능사는 아니에요. 핵심은 ‘순서’입니다. 첫 화면에 보이는 이미지는 최우선으로, 스크롤을 내려야 보이는 이미지는 나중에 불러오는 게 정석이거든요.

화면 아래쪽 이미지에는 loading="lazy"를 걸어서 사용자가 거기까지 내려올 때 로드되게 만들어요. 반대로 히어로 이미지처럼 처음부터 보여야 하는 건 fetchpriority="high"를 줘서 브라우저가 가장 먼저 가져오게 합니다. 이 둘을 헷갈려서 거꾸로 걸어두면 오히려 첫 화면이 더 느려지니 주의하세요.

한 가지 자주 하는 실수가 히어로 이미지에까지 lazy를 거는 겁니다. 좋은 의도로 한 건데, 결과적으로 LCP 요소가 늦게 뜨면서 점수가 더 떨어져요. 첫 화면 이미지는 절대 lazy로 두지 마세요. 이건 우리도 몇 번 데어보고 배운 부분이에요.

그리고 외부 이미지 호스트를 쓴다면 preconnect로 연결을 미리 터주는 것도 효과가 쏠쏠합니다. 도메인 연결에 드는 몇백 밀리초를 아껴주거든요. 자잘해 보여도 이런 게 쌓이면 LCP에서 0.5초씩 차이가 납니다.

이미지 SEO와 alt 텍스트, 그리고 AI 검색 시대

이미지 최적화를 속도 문제로만 보면 절반만 본 거예요. 나머지 절반은 검색이죠. 구글 공식 가이드는 모든 의미 있는 이미지에 alt 텍스트를 달라고 권합니다. 시각장애 사용자를 위한 접근성이기도 하고, 동시에 구글이 이미지 내용을 이해하는 단서이기도 하거든요.

alt를 쓸 때 키워드만 욱여넣으면 오히려 스팸으로 취급받아요. 사람이 그 이미지를 못 본다고 가정하고, 무엇이 담겼는지 자연스럽게 한 문장으로 설명하는 게 정석입니다. ‘랜딩페이지 최적화’를 다섯 번 반복하는 alt보다, ‘모바일 화면에서 빠르게 로딩되는 제품 상세 이미지’ 같은 묘사가 훨씬 낫습니다.

2026년 들어 달라진 점이라면, 생성형 AI 검색과 멀티모달 검색이 본격화되면서 이미지 주변 맥락이 더 중요해졌다는 거예요. 파일명, alt, 캡션, 그리고 이미지를 둘러싼 본문 텍스트가 하나의 묶음으로 평가받습니다. 그래서 파일명도 ‘IMG_8821.jpg’ 대신 ‘landing-page-hero-mobile.avif’처럼 내용을 담아 짓는 걸 권해요. 작은 디테일인데 누적되면 노출에서 차이가 나더라고요.

이미지 SEO와 alt 텍스트 작성으로 검색 노출을 높이는 전략 시각화

우리가 현장에서 굴려본 최적화 체크리스트

이론은 이쯤 하고, 실제로 랜딩페이지 하나를 받으면 우리가 순서대로 밟는 흐름을 풀어볼게요. 거창한 도구 없이도 절반은 잡힙니다.

먼저 PageSpeed Insights로 현 상태를 찍어요. LCP element가 이미지인지부터 봅니다. 맞으면 그 이미지의 실제 전송 용량을 확인하고, 300KB를 넘으면 AVIF로 변환해서 다시 압축해요. 그다음 히어로에 fetchpriority를 주고, 화면 아래 이미지엔 lazy를 겁니다. srcset으로 모바일용 작은 버전을 깔아주고, 너비와 높이를 명시해 레이아웃 밀림을 막아요.

마지막으로 alt와 파일명을 정리하고, 다시 한 번 측정해서 전후를 비교합니다. 이 흐름만 한 바퀴 돌려도 LCP가 2초 안쪽으로 들어오는 경우가 대부분이에요. 솔직히 마법 같은 비법이 따로 있는 게 아니라, 기본을 빠짐없이 지키느냐 마느냐의 싸움입니다.

근데 여기서 한 가지 강조하고 싶은 게 있어요. 이미지를 줄인다고 화질을 너무 깎으면 안 됩니다. 특히 제품을 파는 랜딩이라면 사진 품질이 곧 신뢰거든요. 용량과 화질 사이에서 ‘사람 눈에 차이가 안 느껴지는 지점’을 찾는 게 핵심이고, 그 감각은 결국 여러 번 돌려보며 익히게 됩니다.

랜딩페이지 이미지 하나가 광고 성과 전체를 끌어내리는 경우, 막상 안에서는 잘 안 보입니다. 우리가 여러 업종에서 이 문제를 잡아온 경험으로, 어디서 속도가 새고 어디서 전환이 빠지는지 함께 진단해드릴게요.

terg.kr 상담 신청하고 우리 랜딩페이지 진단받기

자주 묻는 질문

랜딩페이지 이미지는 어느 정도 용량까지 줄여야 하나요

히어로 같은 대표 이미지는 200~300KB 안쪽을 목표로 잡으시면 좋아요. 본문 보조 이미지는 100KB 이하로도 충분한 경우가 많습니다. 다만 무조건 작게보다, 사람 눈에 화질 저하가 안 느껴지는 선에서 최대한 줄이는 게 맞아요.

AVIF를 썼는데 일부 환경에서 이미지가 안 보이면 어떡하죠

그래서 picture 태그로 AVIF, WebP, JPG를 순서대로 제공하는 구조를 권합니다. 브라우저가 자기가 지원하는 포맷을 알아서 골라가니까, AVIF가 안 되는 환경에서도 자동으로 대체 이미지가 떠요. 안전장치를 깔아두면 호환성 걱정은 거의 없습니다.

모바일과 데스크탑 이미지를 따로 만들어야 하나요

같은 이미지를 여러 너비로 뽑아서 srcset에 넣어두면 브라우저가 기기에 맞게 골라갑니다. 굳이 디자인을 다르게 안 해도 돼요. 모바일에 큰 이미지를 그대로 내려보내는 것만 피하면 전송량이 크게 줄어듭니다.

lazy loading을 모든 이미지에 걸면 안 되나요

첫 화면에 보이는 이미지, 특히 LCP 요소에는 lazy를 걸면 안 돼요. 오히려 첫인상이 늦어져 점수가 떨어집니다. 스크롤을 내려야 보이는 이미지에만 lazy를 적용하고, 히어로에는 fetchpriority를 높게 주는 게 맞는 조합이에요.

alt 텍스트에 키워드를 많이 넣으면 SEO에 좋은가요

오히려 역효과예요. 키워드를 반복해 욱여넣으면 스팸으로 취급될 수 있습니다. 이미지를 못 보는 사람에게 설명하듯 내용을 자연스럽게 한 문장으로 적는 게 정석이고, 그게 결과적으로 검색에도 더 유리합니다.

Google Ads Article