LCP 2.5초가 검색 순위를 가르는 기준선
LCP(Largest Contentful Paint)는 사용자가 페이지를 열었을 때 가장 큰 요소(보통 메인 이미지나 제목)가 화면에 나타나기까지 걸린 시간을 말합니다. 구글은 이 시간을 검색 순위 신호로 직접 사용합니다.
- 2.5초 이하: Good (검색 순위 신호 긍정)
- 2.5~4초: Needs Improvement
- 4초 초과: Poor (검색 순위 신호 부정)
아임웹·카페24로 만든 사이트의 모바일 LCP 평균은 3.5~6초입니다. 대부분 Poor 등급이거나 그 직전입니다.
빌더 사이트가 굼뜬 4가지 이유
1. 공통 리소스 통째 로드: 빌더는 사이트의 모든 기능을 위한 CSS·JS를 한 번에 다운받게 합니다. 블로그 글 하나를 읽으려고 들어왔는데, 쇼핑몰 결제 모듈까지 함께 로드됩니다.
2. 원본 이미지 서빙: 4000×3000px 카메라 사진을 그대로 업로드해도 압축 없이 그대로 전송됩니다. 모바일 화면(390px 폭)에서는 1/10 크기로 줄어들지만, 다운로드 용량은 그대로입니다.
3. 폰트 풀세트 다운로드: 한글 폰트는 영문 대비 20~30배 무겁습니다. 빌더는 폰트 서브셋(사용 글자만 추출) 기능이 없어 전체 글리프를 다운로드합니다.
4. 렌더 블로킹 스크립트: 광고·채팅·트래킹 코드가 페이지 로딩을 막는 위치에 삽입되어 LCP 완료를 지연시킵니다.
풀스택의 LCP 최적화 기법
Next.js·Remix 환경에서는 다음 기법으로 LCP를 1초 이내로 만듭니다.
- SSR/ISR 사전 렌더링: HTML이 완성된 상태로 전송. 클라이언트는 렌더링 비용이 거의 없음
- 이미지 자동 변환: Next/Image가 사용자 화면 크기와 브라우저 지원에 따라 AVIF·WebP·JPG 중 가장 가벼운 포맷을 자동 선택
- Priority 힌트: LCP 후보 이미지에 fetchpriority="high" 자동 적용
- 폰트 서브셋: 페이지에서 실제로 쓰는 글자만 골라 다운로드. 한글 폰트 용량 1/8 감소
- 코드 스플리팅: 페이지별 JS 번들 분리. 평균 80% 용량 절감
비교 측정값
| 항목 | 빌더(아임웹) | 풀스택(Next.js) |
|---|---|---|
| LCP 평균 | 4.2초 | 1.3초 |
| 총 다운로드 | 2.3MB | 280KB |
| 이미지 포맷 | JPG 원본 | AVIF 자동 |
| 폰트 용량 | 1.8MB | 240KB |
| 트래킹 영향 | 렌더 블로킹 | 비동기 로드 |
1초 단축이 매월 매출을 바꾼다
구글 공식 데이터 기준 LCP가 1초 단축되면 이탈률이 32% 감소하고, 전환율이 평균 8~12% 상승합니다. 매월 광고비 100만원으로 200명이 들어오던 사이트가 같은 비용으로 226명을 받게 됩니다. 1년이면 312명, 광고비 156만원치를 더 받는 셈입니다.
치로웹디자인의 모든 사이트는 모바일 LCP 2초 이내를 기준으로 작업합니다. 풀스택 구조이기 때문에 가능한 수치입니다. 치로의 홈페이지 제작 서비스에서 실제 측정 사례를 확인할 수 있습니다. 사이트 속도 전반은 사이트 속도 최적화 가이드에서 더 다룹니다.
자주 묻는 질문
LCP를 줄이는 가장 빠른 방법이 있나요? 가장 효과가 큰 것은 메인 이미지의 포맷·크기 최적화입니다. AVIF 변환과 정확한 srcset만으로도 LCP를 1~2초 단축할 수 있습니다. 빌더에서는 이 작업이 제한적이라 한계가 명확합니다.
아임웹에서 이미지 최적화 플러그인을 쓰면 되지 않나요? 일부 압축은 가능하지만, AVIF 변환과 화면 크기별 자동 srcset 생성은 빌더 구조상 어렵습니다. 또한 플러그인이 늘어날수록 다른 영역의 속도가 더 느려지는 부작용이 생깁니다.
LCP가 2.5초만 되면 충분한가요? 검색 순위 기준점은 2.5초지만, 실제 사용자 이탈률은 1.5초 부근에서 의미 있게 줄어듭니다. 경쟁이 치열한 키워드에서는 1초대 LCP가 사실상의 기준선입니다.