홈페이지 로딩 속도가 곧 매출 — 이미지·폰트·스크립트 최적화 실전

핵심 요약 — 로딩이 1초 늦어질 때마다 이탈률은 계단식으로 오르고, 느린 페이지는 구글 검색 순위에서도 뒤로 밀린다. 이미지 포맷·지연 로딩, 웹폰트 서브셋, 스크립트 다이어트 이 세 가지만 손봐도 대부분의 국내 중소 홈페이지는 체감 속도가 눈에 띄게 빨라진다. 속도는 감이 아니라 코어 웹 바이탈이라는 공개 지표로 측정하고 개선하는 영역이다.

느린 사이트가 실제로 잃는 것

속도 문제는 “조금 답답하다”로 끝나지 않는다. 페이지가 뜨기 전에 사용자가 뒤로가기를 누르면 그 방문은 광고비를 태워 데려온 트래픽이든 검색으로 유입된 잠재고객이든 그대로 0원이 된다. 구글은 2021년부터 코어 웹 바이탈(Core Web Vitals)을 검색 랭킹 신호로 공식 반영하고 있고, 이 지표들의 정의와 목표치는 web.dev에서 그대로 공개한다. 즉 속도는 UX와 검색 노출을 동시에 건드리는 몇 안 되는 레버다.

핵심 지표는 세 개다. LCP(가장 큰 콘텐츠가 그려지는 시점)는 2.5초 이내, INP(사용자 입력에 대한 반응성)는 200ms 이내, CLS(레이아웃이 밀리는 정도)는 0.1 이하가 web.dev 기준의 ‘양호’ 구간이다(2026년 7월 기준). 이 세 숫자를 모르고 “우리 사이트 좀 느린 것 같아요”라고 말하는 건 매출 진단을 감으로 하는 것과 같다.

이미지: 가장 크고 가장 쉬운 먹잇감

대부분의 국내 홈페이지에서 페이지 용량의 절반 이상은 이미지다. 그리고 열에 아홉은 최적화가 전혀 안 되어 있다. 순서는 이렇다.

첫째, 포맷을 바꾼다. JPG·PNG를 WebP 또는 AVIF로 교체하면 화질을 유지하면서 용량을 30~70% 줄일 수 있다. 둘째, 실제 표시 크기에 맞춰 리사이즈한다. 화면에서 400px로 보이는 썸네일을 원본 3000px 그대로 올리는 건 회선을 낭비하는 대표적 실수다. 셋째, 화면 밖 이미지는 지연 로딩(loading="lazy")으로 처음 화면에 필요한 것만 먼저 내려받게 한다.

한 가지 함정. 첫 화면에 보이는 대표 이미지(LCP 후보)에는 lazy를 걸면 안 된다. 오히려 늦어진다. “위로는 즉시, 아래로는 지연”이 원칙이다. 또 이미지마다 width·height를 명시해 브라우저가 자리를 미리 잡게 하면 CLS(레이아웃 밀림)를 함께 잡는다.

웹폰트: 예쁜 글꼴이 잡아먹는 초

한글 웹폰트는 무겁다. 한 벌에 수천 개의 글자가 들어 있어 영문 폰트보다 파일이 훨씬 크고, 이게 로딩 중 텍스트가 안 보이거나 뒤늦게 툭 바뀌는 현상의 주범이다. 대응은 세 갈래다.

• 서브셋: 실제로 쓰는 글자만 추린다. 본문용이라면 KS 완성형 한글에 필요한 문장부호 정도로 줄여도 대부분 무리 없다.
• font-display: swap: 폰트가 늦게 와도 시스템 폰트로 먼저 보여준다. 빈 화면 대신 글이 읽힌다.
• 폰트 종류 절제: Regular·Bold 두 굵기면 충분한 사이트가 대부분이다. 굵기·이탤릭을 다 부르면 그만큼 파일이 늘어난다.

폰트는 ‘디자인 취향’으로 접근하기 쉽지만, 로딩 관점에서는 냉정하게 무게를 재야 한다. 시각적 완성도와 접근성의 균형은 정부 디지털서비스 표준인 KRDS와 WCAG 같은 공개 가이드라인에서 이미 정리해 둔 원칙(충분한 대비, 읽기 쉬운 크기)을 참고하면 취향 다툼을 줄일 수 있다.

스크립트 다이어트: 안 쓰는데 실행되는 코드

세 번째 무게추는 자바스크립트다. 채팅 위젯, 히트맵, 여러 개의 분석 태그, 슬라이더 플러그인이 겹치면 브라우저는 화면을 그리다 말고 코드부터 실행하느라 INP(반응성)가 무너진다. 사용자가 버튼을 눌러도 반응이 없는 그 답답함의 정체가 대개 이것이다.

문제	흔한 원인	처방
초기 로딩 지연	모든 스크립트를 head에서 동기 실행	defer/async로 미루기
반응성 저하(INP)	무거운 서드파티 위젯 다수	꼭 필요한 것만 남기기
중복 태그	분석·픽셀 태그 난립	태그매니저로 정리·통합

원칙은 단순하다. 첫 화면을 그리는 데 필요 없는 스크립트는 뒤로 미루거나 지운다. 특히 “언젠가 쓸지 몰라서” 붙여둔 태그와 위젯이 매 방문마다 속도를 갉아먹는지 점검한다. 홈페이지가 검색 결과와 AI 답변에서 제대로 읽히려면 우선 브라우저가 빠르게 완성된 화면을 그릴 수 있어야 한다. 이 구조적 토대는 AI가 읽기 좋은 홈페이지 구조 관점과도 직결된다.

속도는 ‘한 번 손보고 끝’이 아니다

최적화의 함정은 배포 직후엔 빨랐다가 콘텐츠가 쌓이고 배너가 붙으며 슬금슬금 느려진다는 점이다. 그래서 속도는 프로젝트가 아니라 운영 지표로 다뤄야 한다. 위너브라더스가 검색 점유율을 다룰 때 순위와 노출을 데이터로 추적하듯, 코어 웹 바이탈도 월 단위로 측정해 회귀를 잡는 게 맞다. 참고로 블로그·카페 상위노출은 결과를 보장하는 영역이지만, 검색 순위와 AI 인용은 이렇게 측정 가능한 개선 과정과 데이터로 증명하는 영역이다 — 속도 최적화가 바로 그 증명의 출발점이다.

실행 체크리스트

• 대표 페이지 3~5개의 LCP·INP·CLS를 web.dev 기준으로 측정하고 현재 숫자를 기록한다(2026년 7월 시점).
• 모든 이미지를 WebP/AVIF로 전환하고 표시 크기에 맞게 리사이즈한다.
• 첫 화면 밖 이미지에만 loading="lazy"를 걸고, 대표 이미지에는 걸지 않는다.
• 모든 이미지에 width·height를 명시해 레이아웃 밀림(CLS)을 없앤다.
• 한글 웹폰트를 서브셋하고 font-display: swap을 적용하며 굵기를 2종 이내로 줄인다.
• 첫 화면에 불필요한 스크립트는 defer/async 처리하거나 제거하고 중복 태그를 통합한다.
• 개선 후 수치를 다시 측정해 전후를 비교하고, 월 단위 재점검을 운영 루틴에 넣는다.