랜딩페이지 로딩 속도 개선: 광고비 새는 4구간 점검 순서

랜딩페이지 로딩 속도는 개발팀이 챙기는 기술 지표로만 보면 안 됩니다. 광고에서는 클릭 비용을 이미 낸 사람이 실제로 페이지를 보느냐를 가르는 첫 관문입니다.

광고 랜딩페이지 로딩 속도를 개선할 때 가장 중요한 것은 첫 화면이 몇 초 만에 보이느냐입니다. 페이지 전체가 다 열리는 시간은 그다음 문제입니다. 그래서 점수를 올리려고 이것저것 손대기 전에, 광고 유입이 실제로 기다리는 구간이 어디인지부터 찾아야 합니다.

아래에서 광고 관점의 속도 측정 기준, 로딩을 잡아먹는 4가지 구간, 효과 큰 순서대로 고치는 방법, 개선 후 광고 지표로 검증하는 법을 차례대로 설명합니다.

1. 랜딩페이지 로딩 속도, 광고에서는 무엇을 재야 하나

많은 분이 PageSpeed Insights 점수 하나만 보고 "우리 페이지 느리네" 또는 "괜찮네"로 결론을 냅니다.

그런데 광고 랜딩페이지에서는 점수보다 먼저 봐야 할 숫자가 따로 있습니다.

① 광고 관리자 안에서 이미 보이는 속도 신호

메타 광고에서는 링크 클릭과 랜딩페이지 조회의 차이가 가장 직접적인 신호입니다.

링크 클릭은 광고를 누른 횟수입니다. 랜딩페이지 조회는 그 사람이 페이지에 도착하고 픽셀이 실제로 실행된 횟수입니다.

그래서 이 둘의 간격이 크다면, 클릭은 했는데 페이지가 열리기 전에 나간 사람이 많다는 뜻일 수 있습니다.

물론 차이가 전부 속도 때문은 아닙니다. 픽셀 설치 위치, 리다이렉트 중 파라미터 유실, 중복 클릭 같은 측정 문제도 섞여 있습니다. 이 부분은 메타 랜딩페이지 조회: 링크 클릭과 차이 나는 원인과 진단 기준에서 원인별로 나눠 두었습니다.

실무에서 쓰기 좋은 기준은 이렇습니다.

• 같은 계정 안에서 랜딩페이지만 다른 광고 세트끼리 링크 클릭 대비 랜딩페이지 조회 비율을 비교합니다.

• 특정 랜딩만 비율이 눈에 띄게 낮다면 측정 문제보다 속도 문제일 가능성이 높습니다.

• 모든 랜딩이 똑같이 낮다면 픽셀이나 계정 단위 설정을 먼저 의심합니다.

-> 핵심: 절대값보다 같은 계정 안에서의 상대 비교가 속도 문제를 더 정확하게 가려냅니다.

② 구글이 쓰는 기준: 코어 웹 바이탈 3가지

속도를 기술적으로 판단할 때는 구글이 공개한 코어 웹 바이탈(Core Web Vitals) 기준을 쓰는 것이 가장 객관적입니다. 2024년 3월부터 반응성 지표가 FID에서 INP로 바뀌었고, 2026년 현재도 아래 3가지가 기준입니다.

(출처: Google web.dev Core Web Vitals 가이드. 판정은 실제 방문자의 75번째 백분위수 기준입니다)

광고 랜딩에서 가장 먼저 볼 지표는 LCP입니다.

광고로 들어온 사람은 스크롤하기 전에 첫 화면만 보고 머무를지를 정합니다. 상세페이지 하단 이미지가 늦게 뜨는 건 상대적으로 큰 문제가 아닙니다. 하지만 첫 화면의 메인 이미지가 늦게 뜨면 그 클릭은 그대로 버려집니다.

③ 실험실 데이터와 필드 데이터는 다릅니다

PageSpeed Insights 결과에는 두 종류의 데이터가 나옵니다.

• 필드 데이터: 실제 크롬 사용자의 최근 28일 기록입니다. 트래픽이 적은 페이지는 표시되지 않을 수 있습니다.

• 실험실 데이터: 측정 시점에 느린 모바일 네트워크를 가정해 한 번 돌린 결과입니다. 아래쪽 성능 점수가 이 값입니다.

광고 랜딩은 대부분 모바일 SNS 인앱 브라우저로 열립니다. 그래서 사무실 와이파이와 PC로 열어 보고 "빠른데요?"라고 판단하면 실제와 크게 어긋납니다.

필드 데이터가 있으면 필드 데이터를 우선하고, 없으면 실험실 데이터의 모바일 탭 LCP를 기준으로 삼는 것이 안전합니다.

2. 랜딩페이지 로딩 속도를 잡아먹는 4가지 구간

느린 랜딩페이지를 뜯어보면 원인은 거의 4가지 구간 중 하나에 몰려 있습니다.

① 이미지: 가장 흔하고, 가장 효과가 큰 구간

국내 이커머스 랜딩, 특히 건기식·뷰티 상세페이지는 디자이너가 만든 세로로 긴 통이미지를 잘라 올리는 구조가 많습니다.

여기서 흔히 생기는 문제는 이렇습니다.

• 원본 PNG를 그대로 올려서 이미지 한 장이 수 MB에 달하는 경우

• 모바일 화면 폭은 400px 안팎인데 이미지 폭이 2,000px 이상인 경우

• 첫 화면 메인 이미지까지 지연 로딩(lazy loading)을 걸어 오히려 LCP가 늦어지는 경우

마지막 항목은 의외로 많이 놓칩니다. 지연 로딩은 화면 아래쪽 이미지에만 걸어야 합니다. 첫 화면 이미지에 걸면 브라우저가 그 이미지를 뒤로 미루기 때문에 LCP가 나빠집니다.

-> 핵심: 이미지는 "가볍게"보다 "첫 화면은 빨리, 나머지는 나중에"로 나눠 다뤄야 합니다.

② 스크립트와 태그: 광고 운영이 길수록 쌓이는 구간

광고를 오래 운영한 사이트일수록 페이지 안에 스크립트가 지층처럼 쌓여 있습니다.

메타 픽셀, 구글 태그, 카카오 픽셀, 네이버 분석 스크립트, 히트맵 툴, 채팅 상담 위젯, 리뷰 위젯, 팝업 툴까지. 하나하나는 가볍더라도 동시에 실행되면 첫 화면이 그려지는 시점을 늦춥니다.

특히 확인할 부분은 두 가지입니다.

• 이미 끝난 캠페인이나 해지한 툴의 스크립트가 그대로 남아 있는지

• 같은 픽셀이 사이트 코드와 GTM에 이중으로 심어져 있는지

두 번째는 속도뿐 아니라 전환 중복 집계로도 이어집니다. 진단 순서는 GTM 태그 중복 실행: 두 번 잡히는 원인 5가지와 진단 순서에 정리되어 있습니다.

③ 서버와 리다이렉트: 페이지가 그려지기 전의 대기 시간

이미지와 스크립트를 다 줄였는데도 느리다면 페이지가 그려지기 전 구간을 봐야 합니다.

• 리다이렉트 단계: 광고 URL → 단축 URL → http → https → www 붙은 주소처럼 여러 번 거쳐 가는 경우입니다. 단계마다 왕복 시간이 더해집니다.

• 서버 응답 시간(TTFB): 저가 호스팅이나 플러그인이 많은 워드프레스 사이트에서 자주 길어집니다.

• 해외 서버: 국내 방문자를 대상으로 하는데 서버가 해외에 있고 CDN이 없는 경우입니다.

광고 URL은 최종 도착 주소를 그대로 넣는 것이 기본입니다. 추적 때문에 리다이렉트를 꼭 거쳐야 한다면 최소 단계로 줄이고, 리다이렉트 과정에서 UTM이 사라지지 않는지도 함께 확인해야 합니다.

④ 폰트와 레이아웃: 숫자로는 작아 보여도 체감은 큰 구간

한글 웹폰트는 글자 수가 많아서, 서브셋 처리를 하지 않으면 파일 하나가 수 MB에 이르기도 합니다. 폰트가 늦게 받아지면 글자가 한동안 안 보이거나, 기본 폰트로 떴다가 바뀌면서 화면이 덜컥거립니다.

이 덜컥거림이 바로 CLS입니다. 상단 띠배너나 쿠폰 팝업이 뒤늦게 끼어들면서 본문을 아래로 밀어내는 것도 같은 문제입니다.

광고 랜딩에서 CLS가 높으면 사용자가 구매 버튼을 누르려는 순간 버튼이 밀려 엉뚱한 곳을 누르게 됩니다. 이탈로 바로 이어지는 구간입니다.

3. 랜딩페이지 로딩 속도 개선 순서: 효과 큰 것부터

4가지 구간을 다 알았다고 한꺼번에 손대면 안 됩니다. 무엇이 효과를 냈는지 알 수 없고, 스크립트를 잘못 건드리면 전환 추적이 깨질 수 있기 때문입니다.

실무에서는 효과는 크고 위험은 작은 것부터 순서대로 진행합니다.

① 1순위: 첫 화면 이미지 정리

• 첫 화면 메인 이미지를 WebP 또는 AVIF로 바꿉니다.

• 이미지 폭을 실제 노출 크기의 2배 이내로 줄입니다. 모바일 기준이면 보통 800~1,000px이면 충분합니다.

• 첫 화면 이미지에는 지연 로딩을 빼고, 가능하면 fetchpriority="high"로 우선 순위를 올립니다.

• 첫 화면에 자동재생 영상이 있다면, 영상 대신 정지 이미지를 먼저 보여주는 구조를 검토합니다.

이 단계는 디자인이 바뀌지 않고 추적에도 영향이 없습니다. 그러면서도 LCP 개선 폭이 가장 큰 경우가 많습니다.

② 2순위: 아래쪽 이미지와 통이미지 분할

• 첫 화면 아래 이미지에는 모두 지연 로딩을 겁니다.

• 한 장짜리 초대형 통이미지는 여러 장으로 나눕니다. 그래야 위에서부터 순서대로 보입니다.

• 텍스트가 들어간 영역은 가능하면 이미지가 아니라 HTML 텍스트로 바꿉니다. 용량이 줄고 검색 노출에도 유리합니다.

③ 3순위: 스크립트 정리

여기서부터는 주의가 필요합니다.

• 쓰지 않는 툴의 스크립트는 먼저 목록을 만들고, 담당자 확인을 거친 뒤 제거합니다.

• 채팅 위젯·리뷰 위젯처럼 첫 화면에 필요 없는 스크립트는 페이지 로드 이후나 스크롤 시점으로 미룹니다.

• 광고 픽셀은 늦추지 않습니다. 픽셀을 지연 로딩하면 빨리 나간 방문자가 랜딩페이지 조회에서 빠지고, 리타겟팅 모수와 전환 데이터가 함께 줄어듭니다.

-> 핵심: 속도를 위해 줄이는 대상은 부가 기능 스크립트입니다. 측정 스크립트는 아닙니다.

④ 4순위: 리다이렉트·서버·폰트

• 광고 URL의 리다이렉트를 1단계 이하로 줄입니다.

• 한글 웹폰트는 서브셋 버전을 쓰고, font-display: swap으로 글자가 먼저 보이게 합니다.

• 띠배너·팝업·이미지 영역에는 미리 높이를 지정해 레이아웃이 밀리지 않게 합니다.

• 서버 응답이 계속 느리면 CDN 적용이나 호스팅 변경을 검토합니다. 이건 비용과 일정이 드는 일이라 마지막 순서입니다.

실무에서 자주 보는 사례

건기식 카테고리에서 흔한 구조가 있습니다. 상세페이지 전체가 원본 PNG 통이미지로 되어 있고, 첫 장이 수 MB짜리 메인 비주얼인 경우입니다.

이런 페이지는 광고 관리자에서 링크 클릭 대비 랜딩페이지 조회 비율이 같은 계정 다른 랜딩보다 확연히 낮게 나오는 경우가 많습니다. 소재를 몇 번 교체해도 CPA가 안 내려가서 소재 탓을 하다가, 나중에야 랜딩 문제였다는 걸 알게 되는 패턴입니다.

이 경우 디자인은 그대로 두고 첫 화면 이미지 포맷과 크기만 바꿔도 모바일 LCP가 "나쁨" 구간에서 "양호" 구간으로 넘어가는 경우가 드물지 않습니다. 개선 폭은 원래 이미지가 얼마나 무거웠는지에 따라 다릅니다. 다만 1순위 작업만으로 체감 차이가 나는 경우가 대부분입니다.

반대로 실패하는 경우도 있습니다.

속도 점수를 올리겠다고 GTM 컨테이너 전체를 지연 실행으로 바꿨다가 메타·카카오 전환이 함께 줄어든 경우입니다. 점수는 올랐지만 광고 학습 데이터가 끊겨 오히려 성과가 떨어졌습니다. 점수보다 광고 데이터가 먼저라는 원칙을 지켜야 하는 이유입니다.

플랫폼별로 손댈 수 있는 범위

스마트스토어처럼 서버와 코드를 건드릴 수 없는 환경에서는 이미지 용량과 분할이 사실상 유일한 레버입니다. 그만큼 이미지 작업의 비중이 더 커집니다.

4. 로딩 속도 개선 후 광고 지표로 효과 검증하는 법

속도 개선은 PageSpeed 점수가 올랐을 때 끝나는 작업이 아닙니다. 광고 지표가 움직였는지 확인해야 끝납니다.

① 비교 구간을 먼저 고정합니다

• 개선 전 7일과 후 7일을 같은 요일 구성으로 비교합니다.

• 비교 기간에는 소재·타겟·예산을 바꾸지 않습니다. 여러 변수를 같이 바꾸면 속도의 효과를 따로 떼어 볼 수 없습니다.

• 프로모션 시작이나 종료처럼 외부 변수가 낀 주는 비교 구간에서 뺍니다.

② 보는 지표는 3가지입니다

1번이 움직였는데 3번이 안 움직였다면, 속도 문제는 해결됐고 다음 병목은 메시지나 상품 쪽이라는 뜻입니다. 이때는 소재와 랜딩의 메시지가 맞는지 보는 단계로 넘어가야 합니다.

GA4에서 광고 유입별 랜딩 성과를 나눠 보는 방법은 GA4 랜딩페이지 보고서 보는 법: 광고 유입별로 읽는 4단계 기준을 참고하시면 됩니다.

③ 이런 경우는 속도 개선으로 해결되지 않습니다

• 랜딩페이지 조회는 정상인데 전환이 0건인 경우 → 결제 구간이나 전환 추적 문제일 가능성이 높습니다.

• 모바일 LCP가 이미 "양호"인데도 이탈이 높은 경우 → 속도가 아니라 첫 화면 메시지 문제입니다.

• 특정 매체에서만 이탈이 높은 경우 → 매체별 타겟 품질 차이일 수 있습니다.

이 경우 클릭 이후 구간을 나눠서 다시 진단해야 합니다. 순서는 광고 클릭은 많은데 전환이 없을때: 0건 원인 가르는 3구간 진단에 정리되어 있습니다.

-> 핵심: 속도는 클릭을 방문으로 바꾸는 단계까지만 책임집니다. 방문을 구매로 바꾸는 건 그다음 단계의 일입니다.

자주 묻는 질문

랜딩페이지 로딩 속도는 몇 초까지가 괜찮나요?
구글 기준으로는 첫 화면의 가장 큰 요소가 보이는 LCP가 2.5초 이하면 "양호"입니다. 4초를 넘으면 "나쁨"으로 분류됩니다. 광고 랜딩은 모바일 인앱 브라우저로 열리는 경우가 많으니, 반드시 모바일 측정값을 기준으로 판단해야 합니다.

PageSpeed Insights 점수가 낮으면 광고 성과도 무조건 나쁜가요?
그렇지 않습니다. 점수는 실험실 환경에서 한 번 돌린 결과라 실제 방문자 경험과 다를 수 있습니다. 광고 관리자의 링크 클릭 대비 랜딩페이지 조회 비율이 정상이라면 점수만 보고 큰 공사를 할 필요는 없습니다.

이미지를 줄이면 상세페이지 화질이 떨어지지 않나요?
WebP나 AVIF로 변환하고 폭을 모바일 노출 크기에 맞추면, 눈으로 구분하기 어려운 수준에서 용량을 크게 줄일 수 있습니다. 화질 저하가 걱정된다면 첫 화면 이미지만 먼저 바꿔 보고 비교하는 방식이 안전합니다.

속도 개선하려고 픽셀을 늦게 불러와도 되나요?
권장하지 않습니다. 픽셀을 지연시키면 빨리 이탈한 방문자가 측정에서 빠지고, 전환 데이터와 리타겟팅 모수가 함께 줄어듭니다. 지연 대상은 채팅·리뷰 위젯 같은 부가 스크립트로 한정하는 것이 원칙입니다.

마무리

랜딩페이지 로딩 속도 개선은 점수를 올리는 작업이 아닙니다. 이미 돈을 낸 클릭을 방문으로 살려내는 작업입니다.

그래서 순서가 중요합니다. 광고 관리자에서 링크 클릭 대비 랜딩페이지 조회 비율로 문제 랜딩을 찾고, 모바일 LCP로 원인 구간을 좁힙니다. 그다음 첫 화면 이미지 → 아래쪽 이미지 → 부가 스크립트 → 리다이렉트·폰트·서버 순서로 고칩니다.

그리고 고친 뒤에는 꼭 같은 조건의 7일을 비교해 광고 지표가 실제로 움직였는지 확인하세요.

소재를 몇 번 바꿔도 성과가 그대로라면, 소재보다 먼저 랜딩 첫 화면이 몇 초 만에 뜨는지부터 재 보시길 권합니다.