3초가 기준이다
구글의 2018년 모바일 속도 연구 결과는 지금도 유효합니다. 모바일 페이지가 3초 이내에 로딩되지 않으면 53%의 사용자가 페이지를 떠납니다. 5초가 걸리면 이탈률이 90%에 달합니다.
2026년 평균 인터넷 속도가 크게 향상되었음에도 이 수치가 크게 변하지 않는 이유는 사용자 기대치도 함께 높아졌기 때문입니다. 빠른 인터넷에 익숙해질수록 조금의 지연도 참을 수 없게 됩니다.
속도는 더 이상 개발자만의 관심사가 아닙니다. 비즈니스 전환율, 구글 검색 순위, 광고 비용 효율 모두 페이지 속도에 직접 연결됩니다.
속도가 비즈니스에 미치는 영향 — 수치로 본 사실
전환율
Google의 연구에 따르면 모바일 페이지 로딩이 1초 지연될 때마다 전환율이 7% 감소합니다. 월 1,000만 원의 매출을 내는 사이트가 로딩 속도를 3초에서 1초로 줄이면, 이론적으로 14% 이상의 매출 증가를 기대할 수 있습니다.
Deloitte의 2020년 연구는 모바일 사이트 속도를 0.1초 개선했을 때 소매업종에서 전환율이 8.4% 향상되었음을 보고했습니다. 0.1초의 차이가 의미 있는 매출 변화를 만들어냅니다.
이탈률
Pingdom의 분석에 따르면 로딩 시간 2초인 페이지의 이탈률은 9%지만, 5초인 페이지의 이탈률은 38%입니다. 속도가 2배 느려지면 이탈률이 4배 높아집니다.
SEO 순위
구글은 2021년 Core Web Vitals를 공식 순위 신호로 채택했습니다. LCP(Largest Contentful Paint) 2.5초 이하, CLS(Cumulative Layout Shift) 0.1 이하, INP(Interaction to Next Paint) 200ms 이하가 Good 등급 기준입니다. 이 기준을 충족하지 못하면 같은 키워드에서 경쟁 사이트에 밀릴 수 있습니다.
광고 효율
구글 애즈의 품질 점수(Quality Score)는 랜딩 페이지 경험을 포함합니다. 랜딩 페이지가 느리면 품질 점수가 낮아지고, 동일한 키워드에서 더 높은 입찰가를 내야 합니다. 속도 개선은 광고비 절감으로도 이어집니다.
속도 저하의 주요 원인
최적화되지 않은 이미지
대부분의 사이트에서 속도 저하의 주범은 이미지입니다. 1MB 이상의 JPG 파일을 그대로 사용하는 경우, WebP나 AVIF로 변환하면 파일 크기를 40~60% 줄일 수 있습니다.
이미지 최적화의 핵심 세 가지는 포맷 변환(WebP/AVIF), 크기 조정(실제 표시 크기에 맞게), **압축(품질 80% 수준)**입니다. 가로 1920px로 표시되는 이미지를 4000px 원본으로 서빙하는 것은 불필요한 대역폭 낭비입니다.
렌더링 차단 스크립트
<head> 태그에 위치한 JavaScript 파일은 브라우저가 HTML 파싱을 멈추고 스크립트를 먼저 실행하게 합니다. async 또는 defer 속성을 추가하거나, 스크립트를 <body> 태그 하단으로 이동하면 초기 렌더링 속도가 크게 향상됩니다.
서드파티 스크립트(채팅 위젯, 분석 도구, 마케팅 태그)가 많을수록 로딩 속도는 느려집니다. Google Tag Manager에 불필요한 태그가 쌓인 사이트는 GTM만 정리해도 속도가 개선됩니다.
과도한 CSS
빌더 플랫폼은 모든 사이트에 동일한 CSS 번들을 로드합니다. 내 사이트에서 사용하지 않는 컴포넌트의 스타일도 함께 로딩됩니다. 커스텀 개발에서는 사용하는 스타일만 빌드에 포함하도록 Tree Shaking을 적용합니다.
느린 서버 응답 (TTFB)
TTFB(Time to First Byte)는 브라우저가 첫 번째 바이트를 받기까지의 시간입니다. 서버가 멀거나, DB 쿼리가 복잡하거나, 캐싱이 없으면 TTFB가 높아집니다. CDN 사용, 서버 캐싱 설정, 데이터베이스 쿼리 최적화로 개선합니다.
기술적 최적화 방법
이미지 최적화
<!-- 나쁜 예 -->
<img src="hero.jpg" />
<!-- 좋은 예 -->
<img
src="hero.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 50vw"
width="1200"
height="600"
loading="lazy"
alt="치로웹디자인 히어로 이미지"
/>
Next.js의 <Image> 컴포넌트는 이 최적화를 자동으로 처리합니다. WebP 변환, 적절한 srcset 생성, lazy loading이 기본 적용됩니다.
코드 분할 (Code Splitting)
모든 페이지의 JavaScript를 하나의 파일로 번들링하면 첫 페이지 로딩 시 모든 코드를 다운로드해야 합니다. 코드 분할은 현재 페이지에 필요한 코드만 로딩하고, 나머지는 필요할 때 비동기로 로딩합니다.
Next.js는 라우트 기반 코드 분할을 기본 적용합니다. /services 페이지에 접근할 때 /blog 페이지 코드를 미리 로딩하지 않습니다.
CDN(Content Delivery Network)
CDN은 전 세계 여러 서버에 사이트 파일을 분산 저장합니다. 서울에서 접속하면 서울에 가장 가까운 CDN 서버에서 파일을 받습니다. 미국 서버에서 직접 받는 것보다 응답 속도가 2~5배 빠릅니다.
Vercel과 Netlify는 CDN을 기본 제공합니다. 아임웹과 카페24도 CDN을 사용하지만, 세부 캐시 전략 제어는 불가능합니다.
폰트 최적화
웹 폰트는 초기 로딩 속도에 큰 영향을 미칩니다. Pretendard 전체 폰트를 로딩하면 수 MB가 됩니다. 사용하는 굵기(weight)만 선택적으로 로딩하고, font-display: swap을 설정해 폰트 로딩 중에도 텍스트가 표시되도록 합니다.
<link rel="preload" as="font"> 태그로 중요 폰트를 미리 로딩하면 LCP가 개선됩니다.
Lazy Loading
화면에 보이지 않는 이미지는 즉시 로딩할 필요가 없습니다. loading="lazy" 속성만 추가하면 스크롤 위치에 따라 이미지를 순차적으로 로딩합니다. 히어로 이미지처럼 즉시 보이는 요소에는 loading="eager"를 사용합니다.
빌더 vs 커스텀 — 실제 속도 비교
| 항목 | 아임웹/카페24 | 커스텀 (Next.js) |
|---|---|---|
| Lighthouse 모바일 | 평균 35~55점 | 85~98점 |
| LCP | 4~8초 | 1~2.5초 |
| CLS | 0.1~0.5 | 0~0.05 |
| JavaScript 번들 | 제어 불가 | 라우트별 분할 |
| 이미지 최적화 | 제한적 | 자동 WebP 변환 |
| 캐시 제어 | 불가 | 세밀한 설정 가능 |
치로웹디자인이 아임웹에서 Next.js로 마이그레이션한 사이트의 경우, 평균 모바일 LCP가 6.2초에서 1.8초로 단축되었습니다. Lighthouse 점수는 42점에서 96점으로 상승했습니다.
속도 차이는 단순히 기술의 차이가 아닙니다. 빌더는 범용 코드를 사용하기 때문에 불필요한 기능의 코드가 항상 로딩됩니다. 커스텀 개발은 해당 사이트에 필요한 코드만 포함합니다.
속도 측정 도구
Google PageSpeed Insights: pagespeed.web.dev에서 URL을 입력하면 모바일/데스크톱 Lighthouse 점수와 Core Web Vitals 실제 데이터를 확인할 수 있습니다.
GTmetrix: 로딩 타임라인을 시각적으로 보여주며, 각 리소스의 로딩 순서와 크기를 분석할 수 있습니다.
WebPageTest: 다양한 지역과 브라우저에서 로딩 속도를 테스트합니다. 한국 사용자 기준 속도를 정확히 측정하려면 서울 서버로 테스트를 실행합니다.
FAQ
Q. 속도 개선을 위해 이미지를 다 줄이면 품질이 나빠지지 않나요?
WebP 포맷은 JPEG와 시각적으로 동일한 품질을 유지하면서 파일 크기를 2535% 줄입니다. 표시 크기에 맞게 이미지를 조정하는 것도 품질 손실 없이 파일 크기를 줄이는 방법입니다. 품질 8085% 수준으로 압축하면 육안으로 차이를 거의 알 수 없습니다.
Q. Lighthouse 점수가 높으면 실제 사용자도 빠르게 느끼나요?
Lighthouse는 표준 환경(중간 사양 기기, 4G 네트워크)을 기준으로 측정합니다. 실제 사용자 경험과 완전히 일치하지는 않지만 강한 상관관계가 있습니다. Google Search Console의 Core Web Vitals 리포트는 실제 Chrome 사용자 데이터를 기반으로 하므로 더 정확한 현실 지표입니다.
Q. 지금 사이트가 느린지 빠른지 어떻게 알 수 있나요?
치로웹디자인의 무료 사이트 진단을 신청하면 현재 사이트의 Core Web Vitals 점수, Lighthouse 점수, 주요 속도 저하 원인을 분석한 리포트를 받을 수 있습니다. 3일 이내 결과를 전달합니다.
Q. 현재 아임웹 사이트를 유지하면서 속도를 개선할 수 있나요?
이미지 최적화(업로드 전 압축, WebP 변환), 불필요한 앱/플러그인 제거 등 일부 개선은 가능합니다. 하지만 JavaScript 번들 최적화, 렌더링 전략 변경, 세밀한 캐시 제어는 빌더 구조상 불가능합니다. 근본적인 속도 개선은 사이트 리뉴얼을 통해 커스텀 코드로 재구축하는 것이 유일한 방법입니다.