광고 랜딩페이지가 느릴 때 점검할 순서: 이미지·폰트·스크립트가 모바일 전환에 미치는 영향

에이달 발행 2026년 9월 17일 11분 분량

TL;DR

광고 랜딩페이지가 모바일에서 느리다면 이미지, 폰트, 스크립트를 한꺼번에 줄이기보다 첫 화면의 핵심 이미지가 제때 보이는지 → 텍스트가 즉시 읽히는지 → 화면을 막는 스크립트가 있는지 순서로 점검해야 합니다. 광고 클릭 뒤의 로딩 지연은 이탈을 늘릴 수 있으므로, 광고 문구나 폼을 고치기 전에 실제 모바일 조건에서 첫 화면이 언제 완성되는지 확인하는 편이 좋습니다. Google Ads는 랜딩페이지 속도 개선을 모바일 광고 성과를 높이는 효과적인 방법 중 하나로 안내합니다.

광고 랜딩페이지 속도는 ‘페이지 전체’보다 첫 화면부터 점검해야 합니다

광고 방문자는 페이지를 끝까지 탐색하기 전에 첫 화면에서 머물지 떠날지를 판단합니다. 따라서 느린 랜딩페이지를 진단할 때는 전체 콘텐츠의 완성 시간보다 다음 장면을 먼저 봐야 합니다.

광고 클릭 뒤 제목과 핵심 제안이 보이는가
첫 화면의 대표 이미지나 제품 이미지가 늦지 않게 나타나는가
폰트가 내려받아질 때까지 텍스트가 비어 있지 않은가
동의 배너, 태그, 채팅, 분석 도구가 화면 표시를 늦추지 않는가

더 빠른 모바일 랜딩페이지는 이탈과 반송을 낮추고 전환 및 광고 성과에 도움이 될 수 있습니다. Google Ads는 광고로 연결한 랜딩페이지 성능을 별도로 확인하도록 안내합니다. 즉, 유입량이 부족한지 판단하기 전에 유입 직후의 화면 경험부터 확인하는 것이 순서입니다.

첫 번째 점검 대상은 첫 화면의 LCP 이미지입니다

첫 화면에서 가장 크게 보이는 이미지가 늦게 나타난다면, 방문자는 랜딩페이지가 아직 준비되지 않았다고 느끼기 쉽습니다. 이때 핵심은 단순히 이미지 파일을 줄이는 데 그치지 않고, 브라우저가 그 이미지를 얼마나 빨리 발견하고 요청하는지 확인하는 것입니다.

우선 다음 항목을 확인합니다.

첫 화면 대표 이미지에 loading="lazy"가 붙어 있는가
대표 이미지가 HTML의 일반 <img> 태그에 있는가
이미지 주소를 data-src 같은 속성에 넣고 자바스크립트가 나중에 바꾸는 구조인가
CSS 배경 이미지로만 구성되어 브라우저가 늦게 발견하는가
모바일 표시 크기보다 지나치게 큰 원본 파일을 보내는가

LCP 후보 이미지에 지연 로딩을 적용하면 브라우저가 레이아웃 이후에야 이미지를 불러올 수 있어 로딩 시작이 늦어집니다. 그래서 첫 화면의 핵심 이미지는 지연 로딩 대상에서 제외해야 합니다. web.dev

또한 대표 이미지가 자바스크립트로 삽입되거나 CSS 배경으로 처리되면 브라우저의 이미지 발견 시점이 밀릴 수 있습니다. web.dev는 HTML 응답만으로 LCP 이미지를 발견하기 어려운 구조라면 preload와 높은 fetchpriority 설정을 검토하는 방식을 제시합니다. web.dev

이미지 용량은 모바일 표시 크기 기준으로 판단해야 합니다

이미지는 CSS나 자바스크립트처럼 기본적으로 렌더링을 직접 막는 리소스는 아닙니다. 그러나 모바일 네트워크에서 큰 이미지 전송이 길어지면 첫 화면 완성과 체감 속도에 영향을 줍니다. Chrome Lighthouse 문서는 이미지 전송이 FCP와 Speed Index 같은 로딩 지표에 영향을 줄 수 있다고 설명합니다.

특히 자주 놓치는 문제는 데스크톱용 원본을 모바일에도 그대로 보내는 경우입니다. 모바일에서 작은 크기로 표시되는 이미지에 훨씬 큰 파일을 전송하면, 사용하지 않는 화질을 내려받는 셈이 됩니다. 표시 크기에 맞춰 이미지를 제공하면 전송량을 줄이고 로딩 시간을 단축할 수 있습니다. Chrome DevTools 문서

이미지를 점검할 때는 다음 기준을 적용합니다.

첫 화면의 핵심 이미지를 먼저 구분합니다. 히어로 배너, 제품 대표 컷, 서비스 설명의 중심 시각 요소가 대상입니다.
첫 화면 밖의 이미지와 핵심 이미지를 분리합니다. 화면 아래 이미지에는 지연 로딩을 적용할 수 있지만, 첫 화면 대표 이미지에는 적용하지 않습니다.
모바일에서 실제로 표시되는 폭을 확인합니다. 이미지 원본의 크기만 볼 것이 아니라, 작은 화면에서 얼마나 작게 보이는지를 함께 봅니다.
슬라이드의 숨은 이미지도 확인합니다. 첫 장만 필요한데 여러 장의 대형 이미지를 초기부터 불러오면 첫 화면 경쟁 리소스가 늘어납니다.

폰트 문제는 ‘예쁜 글자’보다 텍스트가 보이는 시점을 늦춥니다

광고 랜딩페이지에서 제목, 혜택, 가격 조건, CTA 문구는 이미지보다 먼저 읽혀야 할 정보입니다. 그런데 웹폰트 로딩 방식이 비효율적이면 텍스트가 한동안 보이지 않을 수 있습니다. Chrome Lighthouse 문서는 폰트 때문에 텍스트가 보이지 않는 현상이 FCP에 영향을 줄 수 있다고 설명합니다.

점검의 핵심은 폰트 파일 수와 로딩 우선순위입니다.

서로 다른 굵기와 스타일을 첫 화면에서 과도하게 불러오는가
첫 화면에 쓰지 않는 폰트까지 초기 요청에 포함하는가
아이콘 폰트가 필요한 아이콘보다 훨씬 많은 글리프를 내려받게 하는가
폰트가 도착하기 전 텍스트 표시를 막는 설정인가

font-display를 auto 또는 block 이외의 값으로 설정하면 폰트가 완전히 내려받아지기 전에도 텍스트를 표시할 수 있고, LCP가 추가 폰트 요청에 막히는 일을 줄일 수 있습니다. web.dev

중요한 것은 폰트를 무조건 인라인으로 넣는 방식이 해답은 아니라는 점입니다. 여러 CSS와 폰트를 HTML에 크게 인라인하면 브라우저의 preload scanner가 핵심 이미지 요청을 발견하는 시점을 늦출 수 있습니다. web.dev의 사례에서는 인라인 리소스가 많아진 구조가 LCP 악화와 연결됐습니다. 필요한지 확인되기 전부터 내려받게 되는 base64 인라인 폰트 역시 신중하게 다뤄야 합니다. web.dev

스크립트는 다운로드 크기뿐 아니라 실행 시간까지 확인해야 합니다

이미지가 이미 내려받아졌는데도 첫 화면이 늦게 보인다면 자바스크립트를 의심해야 합니다. CSS와 자바스크립트 요청은 기본적으로 렌더링을 차단할 수 있어, 다운로드와 처리가 끝날 때까지 브라우저가 콘텐츠를 그리지 못하는 상황이 생길 수 있습니다. Chrome Lighthouse 문서

특히 <head> 안에 async나 defer 없이 동기식 스크립트를 넣으면 HTML 해석과 화면 표시가 멈출 수 있습니다. web.dev는 이런 동기식 스크립트 추가가 대체로 성능에 부정적인 영향을 준다고 설명합니다.

스크립트 점검은 다음 순서가 실무적입니다.

첫 화면을 만드는 데 꼭 필요한 스크립트인지 구분합니다.
분석 태그, 광고 전환 태그, 채팅, 히트맵, 개인화 도구처럼 여러 서드파티 스크립트가 동시에 실행되는지 확인합니다.
초기 진입에 필요 없는 기능은 첫 화면 이후에 불러올 수 있는지 검토합니다.
사용하지 않는 코드가 번들에 포함됐는지 확인합니다.
스크립트가 DOM을 만든 뒤에야 대표 이미지나 핵심 문구가 나타나는 구조인지 확인합니다.

큰 자바스크립트 파일은 다운로드 이후에도 파싱과 실행을 위해 메인 스레드를 점유할 수 있습니다. 이때 이미지 파일이 도착했더라도 렌더링이 늦어질 수 있습니다. web.dev는 메인 스레드를 막는 작업이 LCP의 렌더링 지연으로 이어질 수 있다고 설명합니다.

또한 사용하지 않는 자바스크립트도 다운로드, 파싱, 컴파일 비용을 발생시킵니다. Chrome은 서드파티 및 광고 관련 스크립트가 과도한 스크립트 활동의 원인이 될 수 있다고 안내합니다. Chrome

수정 우선순위는 이미지·폰트·스크립트의 ‘첫 화면 경쟁’을 줄이는 일입니다

세 요소를 각각 최적화해도, 모두가 첫 화면 시작과 동시에 네트워크와 메인 스레드를 경쟁하면 개선 폭이 작을 수 있습니다. 그래서 수정 항목은 다음 우선순위로 정리하는 편이 효율적입니다.

첫 화면 LCP 이미지를 늦게 불러오는 구조 제거 - 지연 로딩 제외 - HTML에서 빠르게 발견되도록 구조 조정 - 필요하면 preload와 우선순위 설정 검토
모바일에 과한 이미지 전송량 축소 - 표시 크기에 맞는 이미지 제공 - 첫 화면 밖 대형 이미지의 초기 요청 축소 - 초기 슬라이드·갤러리의 불필요한 이미지 요청 점검
텍스트가 폰트 때문에 비어 있는 상태 제거 - 첫 화면에 필요한 폰트 굵기와 스타일만 우선 사용 - 텍스트 표시를 막는 폰트 로딩 방식 점검 - 큰 인라인 폰트와 불필요한 폰트 요청 최소화
화면 표시를 막는 스크립트 축소 또는 지연 - 동기식 스크립트 위치와 필요성 확인 - 서드파티 태그별 초기 실행 필요성 검토 - 사용하지 않는 코드 제거
수정 후 광고용 실제 URL을 다시 측정 - 개발 환경이나 홈 화면이 아니라 광고가 연결된 최종 URL을 확인 - 로그인 상태, 지역 분기, 쿠키 동의 배너 등 실제 방문 조건을 반영

모바일 전환 관점에서는 빠른 조건보다 느린 조건에서 확인해야 합니다

사무실 와이파이와 최신 스마트폰에서 빠르게 열린다고 해서 광고 유입 환경에서도 문제가 없다는 뜻은 아닙니다. 모바일 사용자는 네트워크 상태와 기기 성능이 제각각이며, 광고 클릭 직후에는 이동 중이거나 다른 앱을 오간 상태일 수 있습니다.

Chrome DevTools는 모바일 환경을 가정한 분석에서 느린 3G 네트워크와 CPU 감속 설정을 사용해 볼 수 있다고 안내합니다. Chrome DevTools 이 조건에서 다음을 직접 확인하면 좋습니다.

흰 화면 또는 빈 배경이 오래 유지되는가
제목보다 이미지가 먼저, 혹은 너무 늦게 나타나는가
폰트가 로딩될 때 문구가 사라지거나 크게 바뀌는가
쿠키 동의, 채팅 버튼, 팝업이 핵심 CTA를 가리는가
스크롤과 버튼 반응이 첫 진입 직후 늦는가

Google Ads의 Landing pages 화면에서는 광고로 연결한 페이지의 성능을 확인하고, 모바일 친화성 테스트를 안정적으로 통과하지 못한 랜딩페이지를 식별할 수 있습니다. Google Ads 페이지 속도 진단은 한 번의 점수 확인으로 끝내기보다, 광고별 실제 도착 URL과 모바일 화면을 함께 보는 방식이 적합합니다.

속도 개선 뒤에는 전환 요소가 더 빨리 읽히는지 확인해야 합니다

속도 개선의 목적은 기술 점수를 높이는 일이 아니라 광고의 약속과 다음 행동을 더 빨리 전달하는 데 있습니다. 따라서 수정 후에는 LCP나 요청 수만 보지 말고 다음을 함께 확인해야 합니다.

광고 문구와 연결되는 첫 화면 제목이 바로 읽히는가
대표 이미지가 제안 이해를 돕는가, 아니면 로딩 부담만 큰가
문의·구매·예약 등 핵심 CTA가 첫 화면에서 자연스럽게 보이는가
폼, 상품 옵션, 가격 조건 같은 전환 요소가 스크립트 실행 뒤에 늦게 나타나지 않는가
전환 태그를 유지하면서도 불필요한 태그 실행을 줄였는가

속도는 메시지와 폼을 대체하지 않습니다. 다만 방문자가 메시지를 읽고 CTA에 도달할 기회를 확보하는 전제 조건입니다. 특히 광고 랜딩페이지에서는 이미지, 폰트, 스크립트가 첫 화면에서 서로 경쟁하지 않도록 정리하는 것이 모바일 전환 점검의 출발점입니다.

마무리

광고 랜딩페이지가 느릴 때는 첫 화면의 LCP 이미지, 텍스트를 늦추는 폰트, 렌더링과 반응을 막는 스크립트 순으로 점검해야 합니다. 모바일 표시 크기에 맞는 이미지를 보내고, 핵심 이미지를 늦게 발견하는 구조를 피하며, 텍스트와 CTA가 스크립트·폰트 로딩을 기다리지 않게 만들면 광고 클릭 후 이탈이 발생하기 쉬운 구간을 줄일 수 있습니다.

이 운영을 맡기고 싶다면

문의

랜딩페이지는 짧아서 좋은 것이 아니라, 방문자가 행동을 결정하는 데 필요한 정보를 방해 없이 찾을 수 있을 때 좋습니다. 반복 문구와 목적 없는 ...

감사 페이지를 전환 측정과 다음 행동에 활용하는 법: 제출 완료 화면에서 놓치기 쉬운 5가지

감사 페이지는 단순한 “제출 완료” 안내가 아니라, 실제 완료 전환을 측정하고 사용자의 다음 행동을 설계하는 화면입니다. 다만 감사 페이지 조회 ...

신제품 바이럴 캠페인 목표는 어떻게 한 줄로 정할까: 도달·검색·후기 중 하나를 고르는 법

신제품 바이럴 캠페인의 목표는 “누구에게 무엇을 얼마나 남길 것인가”가 아니라, 이번 배포에서 가장 먼저 만들어야 할 변화 하나로 정해야 합니다 ...