웹사이트 속도 최적화 체크리스트 — LCP 2.5초 잡는 법

결론부터 말하면 이렇다. 웹사이트 속도를 잡는 작업은 대부분 이미지·폰트·스크립트 세 곳에서 끝난다. 코어 웹 바이탈의 핵심 지표인 LCP(최대 콘텐츠풀 페인트)는 2.5초 이내가 "좋음" 기준인데, 실제로 느린 사이트 대부분은 이 세 가지 중 하나 이상에서 발목을 잡힌다.

이미 코어 웹 바이탈이란 무엇인지 다룬 글에서 LCP·INP·CLS 세 지표의 정의와 기준값을 설명했다. 이 글은 정의를 다시 설명하기보다, "그래서 오늘 무엇부터 손대야 하는가"에 집중한 실전 체크리스트다. 무료 도구로 문제를 진단하는 법부터, 이미지·폰트·스크립트·서버별로 구체적으로 무엇을 고칠지 순서대로 정리했다.

이 글의 핵심만 먼저 추리면 이렇다.

• LCP는 2.5초 이내가 좋음 기준이며, 대부분의 지연은 이미지·폰트·스크립트 세 곳에서 발생한다
• 내 사이트 속도는 페이지스피드 인사이트(PageSpeed Insights)로 무료·즉시 확인할 수 있다
• 이미지는 차세대 포맷(WebP·AVIF) 전환과 지연 로딩(lazy loading) 만으로도 큰 폭으로 가벼워진다
• 폰트는 font-display: swap과 preload 설정으로 "텍스트가 안 보이는 시간"을 없앤다
• 광고·채팅위젯 같은 서드파티 스크립트는 지연 로딩시켜 초기 렌더링을 막지 않게 한다
• 위 네 가지를 다 손본 뒤에도 느리다면, 그때 서버·호스팅 응답 속도를 점검한다

웹사이트가 느리면 정말 검색 순위와 매출에 불리할까?

정확히 말하면, 속도는 순위를 뒤집을 만큼 크지는 않지만 방문자 이탈에는 직접 영향을 준다. 구글은 코어 웹 바이탈을 포함한 "페이지 경험" 신호를 순위 요소 중 하나로 쓴다고 밝혀 왔지만, 동시에 관련성 높은 콘텐츠의 품질이 여전히 더 큰 비중을 차지한다고 반복해서 설명해 왔다.

문제는 순위보다 이탈률이다. 로딩이 느리면 방문자는 화면이 다 뜨기도 전에 검색 결과로 돌아가 버린다. 그 페이지에 아무리 좋은 정보와 설득력 있는 문장이 담겨 있어도, 애초에 읽히지도 못한 채 기회를 잃는 셈이다.

속도 최적화의 진짜 이유는 "구글에게 잘 보이기 위해서"가 아니라 "손님이 참지 못하고 나가기 전에 화면을 보여주기 위해서"다. 순위 상승은 부수 효과일 뿐, 실제로는 문의·구매 전환이 걸린 문제로 접근하는 편이 맞다.

속도가 걸리는 지표는 세 가지다. LCP(화면이 다 뜨는 시간, 좋음 기준 2.5초 이내), INP(클릭에 반응하는 속도, 좋음 기준 200밀리초 이내), CLS(화면이 흔들리는 정도, 좋음 기준 0.1 이하)다. 세 지표 모두 방문자를 실제로 겪게 한 뒤 상위 75퍼센트 기준으로 판정하는 값이라, 개발자 혼자 빠르다고 느껴도 실제 손님 환경에서는 다르게 나올 수 있다.

이 글은 셋 중에서도 방문자가 가장 먼저, 가장 크게 체감하는 LCP 개선에 집중한다. 화면이 뜨기까지 걸리는 시간이 곧 첫인상이기 때문이다. 세 지표의 자세한 정의와 INP·CLS를 포함한 전체 기준은 코어 웹 바이탈 가이드에서 더 자세히 다뤘다.

어떤 요소가 LCP로 잡히는지 알아 두면 원인을 훨씬 빨리 찾을 수 있다. 화면에 가장 먼저, 가장 크게 그려지는 요소가 LCP 후보가 되는데, 보통은 상단 배너 이미지, 큰 제목 텍스트, 또는 배경 이미지가 여기에 해당한다. 크롬 개발자 도구의 성능(Performance) 탭이나 Lighthouse 보고서에서 "LCP 요소"를 직접 확인할 수 있는데, 이 요소가 정확히 무엇인지 알아야 이미지를 고칠지 폰트를 고칠지 방향을 제대로 잡을 수 있다.

LCP가 늦어지는 원인은 사이트마다 조금씩 다르지만, 실무에서 반복적으로 확인되는 원인은 놀라울 만큼 좁다. 이미지, 폰트, 스크립트, 그리고 서버 응답 속도 — 이 네 가지가 거의 전부다.

내 사이트가 얼마나 느린지, 어떻게 확인할까? 무료 도구 4가지

가장 먼저 할 일은 감이 아니라 숫자로 확인하는 것이다. 다행히 무료로 쓸 수 있는 도구만으로도 충분히 정확한 진단이 가능하다.

1. 페이지스피드 인사이트(PageSpeed Insights) — 구글이 공식 제공하는 무료 도구로, URL만 넣으면 모바일·데스크톱 점수와 함께 LCP·INP·CLS 수치를 바로 보여준다. 실제 방문자 데이터(필드 데이터)와 가상 측정 데이터(랩 데이터)를 함께 제공해, "실제로 느린가"와 "왜 느린가"를 동시에 확인할 수 있다.

여기서 필드 데이터란 실제로 이 페이지를 방문한 구글 크롬 사용자들의 접속 기록을 모은 값(CrUX 데이터)이고, 랩 데이터란 도구가 가상의 환경에서 페이지를 직접 열어 측정한 시뮬레이션 값이다. 방문자가 아직 적은 신생 페이지는 필드 데이터가 아예 표시되지 않을 수 있는데, 이 경우 랩 데이터만으로도 어디가 느린지 원인을 찾는 데는 충분하다. 두 데이터가 서로 다르게 나온다면 필드 데이터 쪽을 더 신뢰하는 편이 맞다 — 실제 방문자가 겪은 값이기 때문이다.

2. 구글 서치 콘솔의 코어 웹 바이탈 보고서 — 페이지 하나가 아니라 사이트 전체를 한눈에 보고 싶을 때 쓴다. 모든 URL을 모바일·데스크톱으로 나눠 양호·개선 필요·불량 그룹으로 자동 분류해 준다. 비슷한 구조의 페이지는 한 그룹으로 묶이므로, 템플릿 하나만 고쳐도 여러 페이지가 한꺼번에 좋아지는 경우가 많다. 서치 콘솔 등록이 아직이라면 구글 서치 콘솔 사용법부터 확인하고 오는 편이 좋다.

3. 크롬 개발자 도구의 Lighthouse — 브라우저에서 F12를 눌러 개발자 도구를 열고 "Lighthouse" 탭에서 바로 실행할 수 있다. 배포 전 로컬 환경에서 빠르게 점검할 때 유용하며, 어떤 요소가 LCP 측정 대상인지, 어떤 리소스가 화면 그리기를 막는지 항목별로 구체적으로 짚어 준다.

4. GTmetrix·WebPageTest — 요청별로 무엇이 언제 로드됐는지 폭포수(waterfall) 차트로 보여주는 해외 무료 도구다. 이미지 하나, 스크립트 하나가 각각 몇 초에 로드를 시작해 몇 초에 끝났는지까지 확인할 수 있어, 페이지스피드 인사이트보다 더 세밀한 원인 추적에 유리하다.

도구	특징	이럴 때 쓴다
페이지스피드 인사이트	구글 공식, 실사용자 데이터 포함	페이지 하나를 빠르게 진단할 때
서치 콘솔 코어 웹 바이탈	사이트 전체 URL을 그룹으로 분류	어떤 템플릿이 문제인지 찾을 때
Lighthouse(개발자 도구)	로컬 환경, 상세 진단 항목	배포 전 미리 점검할 때
GTmetrix·WebPageTest	요청별 폭포수 차트	정확히 무엇이 느린지 추적할 때

네 도구 모두 무료이므로, 굳이 유료 도구부터 찾을 필요는 없다 — 페이지스피드 인사이트 하나만 제대로 읽어도 우선순위의 8할은 파악된다.

나쁜 예는 점수만 보고 넘어가는 것이다. "성능 점수 62점"이라는 숫자만 보고 막연히 불안해하거나, 반대로 "70점 넘었으니 괜찮다"고 안심하고 마는 경우가 많다. 좋은 예는 점수 아래 "개선할 수 있는 항목" 목록을 펼쳐, 어떤 리소스가 몇 초를 잡아먹는지 구체적인 원인부터 확인하는 것이다. 실제 개선은 점수가 아니라 그 목록에서 시작된다.

진단 결과, 구체적으로 어떻게 읽어야 할까?

점수 하나만 보지 말고, 화면 아래 "특히 영향이 큰 문제" 또는 "진단 결과" 목록을 펼쳐 원인부터 확인하는 것이 핵심이다. 예를 들어 페이지스피드 인사이트를 어느 서비스 소개 페이지에 돌렸더니 모바일 기준 LCP 4.6초(나쁨), INP 150밀리초(좋음), CLS 0.03(좋음)으로 나왔다고 하자.

이 경우 INP와 CLS는 이미 좋음 구간이므로 굳이 손댈 필요가 없다. 문제는 LCP 하나뿐이다. 진단 목록을 펼쳐 보니 "이미지 크기 적절하게 설정" 항목에서 약 2초를 절감할 수 있다고 나왔고, "렌더링을 차단하는 리소스 제거" 항목에서 추가로 약 0.8초를 절감할 수 있다고 나왔다면, 이 페이지의 병목은 이미지와 스크립트 두 곳이라는 뜻이다.

나쁜 예는 이 목록을 보지 않고 "느리다니까 일단 뭐라도 손대 보자"며 폰트부터 만지는 것이다. 이 페이지의 병목은 폰트가 아니므로, 폰트를 아무리 손봐도 LCP는 크게 좋아지지 않는다. 좋은 예는 진단 목록에서 예상 절감 시간이 큰 순서대로, 이 사례라면 이미지 → 스크립트 순서로 처리하는 것이다.

이 사례는 특정 사이트의 실제 측정값이 아니라, 진단 결과를 읽는 방법을 보여주기 위한 예시다. 실제 원인과 절감 폭은 페이지마다 다르므로, 반드시 본인 사이트를 직접 측정해 확인해야 한다.

이런 식으로 진단 목록을 먼저 읽으면, 이 글에 정리된 이미지·폰트·스크립트·서버 네 영역 중 실제로 내 사이트에 해당하는 영역만 골라 집중할 수 있다. 네 영역이 전부 문제로 나온다면, 이 글의 순서(이미지 → 폰트 → 스크립트 → 서버)대로 진행하는 것이 일반적으로 효율적이다.

이미지 때문에 느려지는 사이트, 무엇부터 고쳐야 할까?

대부분의 LCP 지연은 이미지 한 장에서 시작된다. 특히 화면 상단에 걸리는 큰 배너나 대표 사진이 LCP 측정 대상이 되는 경우가 많은데, 이 이미지가 무겁고 늦게 도착하면 LCP 전체가 그만큼 늦어진다.

가장 먼저 할 일은 포맷 전환이다. JPG·PNG 대신 WebP나 AVIF 같은 차세대 포맷을 쓰면 같은 화질에서도 파일 용량이 크게 줄어든다. 대부분의 최신 브라우저가 두 포맷을 지원하므로, 지금 당장 적용해도 호환성 문제가 거의 없다.

포맷	특징	언제 쓰면 좋은가
JPG	오래된 표준, 호환성 가장 좋음	구형 브라우저까지 폭넓게 지원해야 할 때
PNG	무손실, 투명 배경 지원	로고·아이콘처럼 배경이 투명해야 할 때
WebP	JPG·PNG보다 용량 작음, 폭넓은 지원	대부분의 일반 사진·배너에 기본값으로
AVIF	가장 높은 압축률, 비교적 최신 포맷	용량을 최대한 줄이고 싶은 대표 이미지에

실무에서는 WebP를 기본값으로 쓰고, 압축률을 한 단계 더 끌어올리고 싶은 핵심 이미지에만 AVIF를 추가로 검토하는 방식이 무난하다. 두 포맷 모두 원본 이미지를 변환 도구에 넣기만 하면 되므로, 사진을 새로 찍거나 디자인을 다시 만들 필요는 없다.

두 번째는 크기 최적화다. 실제 화면에 보이는 크기보다 훨씬 큰 원본 이미지를 그대로 올리는 실수가 흔하다. 모바일 화면 폭이 400픽셀 안팎인데 2000픽셀짜리 원본을 그대로 쓰면, 방문자는 화면에 보이지도 않는 여분의 화질까지 다운로드하며 기다려야 한다.

나쁜 예는 카메라로 찍은 4000픽셀짜리 원본 사진을 압축 없이 그대로 웹사이트에 올리는 것이다. 파일 하나가 수 메가바이트에 달해, 이 이미지 하나 때문에 페이지 전체 로딩이 몇 초씩 늦어진다. 좋은 예는 화면에 실제로 필요한 크기로 리사이즈하고, WebP로 변환하고, 압축까지 마친 이미지를 올리는 것이다. srcset 속성을 함께 쓰면 기기 화면 크기에 맞는 버전을 브라우저가 알아서 골라 받는다.

<img
  src="banner-800.webp"
  srcset="banner-400.webp 400w, banner-800.webp 800w, banner-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, 800px"
  width="1200" height="630"
  alt="상담 신청을 안내하는 대표 배너"
/>

세 번째는 지연 로딩(lazy loading) 이다. 화면 아래쪽, 스크롤해야 보이는 이미지에는 loading="lazy" 속성을 붙여 처음부터 불러오지 않게 한다. 단, LCP 대상이 되는 화면 상단 이미지에는 반대로 lazy loading을 걸면 안 된다 — 오히려 우선순위가 낮아져 LCP가 더 늦어지는 역효과가 난다.

화면 상단 대표 이미지는 지연 로딩 대신 fetchpriority="high" 속성을 붙여 우선적으로 받도록 지정하는 편이 안전하다. "위에는 빨리, 아래는 늦게"가 이미지 로딩의 핵심 원칙이다.

네 번째는 width·height 속성 명시다. 이미지 크기를 미리 지정해 두면 브라우저가 로딩 전에 자리를 미리 확보해, 이미지가 나중에 뜨면서 화면이 밀리는 현상(CLS 악화)을 막아 준다. 속도뿐 아니라 안정성까지 함께 잡는 설정이라 손해 볼 것이 없다.

마지막으로 CDN(콘텐츠 전송 네트워크) 을 쓰면 이미지가 방문자와 물리적으로 가까운 서버에서 전달돼 응답 속도가 빨라진다. 최근에는 대부분의 호스팅·빌더 서비스가 이미지 CDN을 기본 제공하므로, 별도 설정 없이도 이미 적용돼 있는 경우가 많다 — 관리자 화면에서 켜져 있는지 확인만 해 두면 된다.

이미지 압축, 구체적으로 어떤 도구를 쓰면 될까?

포맷 전환과 압축은 개발 지식이 없어도 무료 웹 도구만으로 충분히 할 수 있다. 굳이 유료 프로그램을 새로 설치하거나 개발자에게 매번 요청할 필요가 없다.

스퀴시(Squoosh) 는 구글이 만든 무료 이미지 압축 도구로, 브라우저에 이미지를 올리기만 하면 JPG를 WebP·AVIF로 바꾸면서 압축률까지 슬라이더로 직접 조절할 수 있다. 변환 전후 화질을 화면 좌우로 나란히 비교하며 눈으로 직접 확인할 수 있다는 점이 특히 유용하다.

TinyPNG는 PNG·JPG 파일을 드래그 앤 드롭만으로 압축해 주는 무료 도구다. 로고나 아이콘처럼 투명 배경이 필요한 PNG 이미지를 다룰 때 특히 자주 쓰인다.

빌더·CMS 자체 최적화 기능도 확인해 볼 만하다. 워드프레스의 이미지 최적화 플러그인, Next.js의 이미지 컴포넌트, 국내 홈페이지 빌더들의 자동 압축 기능처럼, 플랫폼이 업로드 시점에 자동으로 WebP 변환·리사이즈까지 처리해 주는 경우도 많다. 이 경우에는 별도 도구 없이 관리자 화면에서 설정만 켜 두면 된다.

예를 들어 화면 상단 배너 사진이 원본 JPG 3메가바이트짜리라고 하자. 이 이미지를 실제 표시 크기(가로 1200픽셀 안팎)에 맞게 리사이즈하고 WebP로 변환해 압축하면, 같은 화질을 유지하면서도 파일 용량이 수백 킬로바이트 수준까지 줄어드는 경우가 흔하다. 방문자의 회선 속도에 따라 체감 폭은 다르지만, 이 정도 용량 차이만으로도 이미지 로딩 시간이 눈에 띄게 짧아진다.

위 수치는 특정 사례가 아니라 일반적인 경향을 보여주는 예시다. 실제 절감 폭은 원본 이미지의 내용(사진인지 일러스트인지), 압축 설정, 방문자의 네트워크 환경에 따라 사이트마다 다르게 나타난다.

나쁜 예는 압축 도구를 한 번 써 보고 "다음에 또 하기 귀찮다"며 새로 올리는 이미지는 그냥 원본 그대로 두는 것이다. 좋은 예는 이미지 업로드 전 압축을 아예 작업 루틴으로 고정해 두거나, 업로드 시 자동 최적화되는 플랫폼으로 옮겨 반복 작업 자체를 없애는 것이다.

웹폰트가 화면을 늦게 만드는 이유는 무엇일까?

웹폰트를 잘못 불러오면 텍스트가 이미 있는데도 화면이 하얗게 비어 있는 시간이 생긴다. 이 현상을 "보이지 않는 텍스트 깜빡임"(FOIT, Flash of Invisible Text)이라고 부르는데, 폰트 파일이 다 받아질 때까지 브라우저가 글자 자체를 화면에서 숨겨 버리기 때문에 생긴다.

해결책은 CSS의 font-display 속성이다. 값을 swap으로 설정하면, 폰트가 아직 로드되지 않았을 때 일단 기본 시스템 폰트로 텍스트를 먼저 보여주고, 웹폰트가 도착하면 그때 화면 위에서 바꿔 끼운다. 텍스트가 아예 안 보이는 시간을 없애는 가장 간단하고 확실한 방법이다.

@font-face {
  font-family: "Pretendard";
  src: url("/fonts/pretendard.woff2") format("woff2");
  font-display: swap;
}

두 번째는 preload다. 본문에서 가장 먼저, 가장 크게 쓰이는 폰트 파일은 <link rel="preload">로 미리 우선순위를 높여 둔다. 브라우저가 CSS를 다 해석하기 전부터 폰트를 미리 받기 시작하므로, 텍스트가 시스템 폰트에서 웹폰트로 바뀌는 시점도 그만큼 앞당겨진다.

<link rel="preload" href="/fonts/pretendard.woff2" as="font" type="font/woff2" crossorigin />

세 번째는 폰트 서브셋(subset) 이다. 한글 폰트 파일은 영문 폰트보다 용량이 훨씬 큰 경우가 많은데, 실제 페이지에서 쓰이는 글자만 골라 담은 서브셋 폰트를 쓰면 파일 용량을 크게 줄일 수 있다. 브랜드 폰트를 전체 음절 다 포함해서 통째로 불러오는 대신, 유니코드 범위를 나눠 필요한 부분만 불러오게 하는 방식(unicode-range 분할)도 같은 원리에서 나온 방법이다.

나쁜 예는 폰트 파일 여러 개(Regular, Medium, Bold, ExtraBold 등)를 전부 페이지 로딩 초반에 한꺼번에 불러오는 것이다. 좋은 예는 실제 화면에서 쓰는 굵기 2–3종만 먼저 불러오고, 나머지 굵기는 필요할 때 추가로 불러오게 하는 것이다.

예를 들어 로고 옆에 굳이 얇은 굵기(Thin, ExtraLight)까지 다섯 종류를 다 불러오는 사이트가 있다면, 실제 본문·제목에 쓰는 두세 굵기만 남기고 나머지는 과감히 빼는 것만으로도 폰트 관련 로딩 용량이 절반 가까이 줄어드는 경우가 흔하다. 굵기 하나를 추가할 때마다 파일 하나가 그대로 늘어난다는 점을 기억해 두면 된다.

속도가 급하다면 웹폰트를 아예 포기하고 시스템 폰트를 쓰는 것도 정당한 선택지다. 브랜드 정체성보다 로딩 속도가 더 중요한 페이지, 예를 들어 결제 페이지나 상담 신청 폼이라면 이 선택이 오히려 전환율에 유리할 수 있다.

자바스크립트가 화면을 막고 있다면 어떻게 풀어야 할까?

스크립트 문제의 핵심은 "언제, 어떤 순서로 불러오느냐"에 있다. <head> 안에 아무 속성 없이 넣은 <script> 태그는 브라우저가 그 파일을 전부 받아 실행할 때까지 나머지 화면 그리기를 멈춘다. 이를 "렌더링 차단(render-blocking)"이라고 한다.

가장 기본적인 해결책은 defer와 async 속성이다. defer는 HTML 파싱이 끝난 뒤 문서에 적힌 순서대로 스크립트를 실행하고, async는 다운로드가 끝나는 대로 순서와 무관하게 바로 실행한다. 화면 표시에 꼭 필요하지 않은 스크립트라면 대부분 이 둘 중 하나로 처리할 수 있다.

<script src="/js/analytics.js" defer></script>
<script src="/js/chat-widget.js" async></script>

나쁜 예는 페이지 최상단에 광고 스크립트, 채팅 위젯, 방문자 분석 도구를 속성 없이 줄줄이 나열하는 것이다. 이 경우 방문자는 정작 보고 싶은 콘텐츠보다 광고나 채팅 위젯이 먼저 뜨는 것을 기다리게 되는 역전 현상이 벌어진다.

좋은 예는 콘텐츠와 직접 관련 없는 서드파티 스크립트를 지연 로딩시키는 것이다. 방문자가 스크롤을 시작하거나, 페이지 로딩이 어느 정도 끝난 뒤(예: 3초 후, 또는 사용자의 첫 상호작용 시점)에 채팅 위젯이나 광고를 불러오도록 지연시키면, 초기 화면이 뜨는 속도에는 아무런 영향을 주지 않는다.

채팅 상담 위젯, 리뷰 위젯, 방문자 추적 스크립트는 대부분 화면이 다 뜬 뒤에 나타나도 사용성에 문제가 없다. "이 스크립트가 지금 당장 필요한가?"를 기준으로 순서를 다시 짜는 것만으로도 체감 속도가 눈에 띄게 좋아진다.

코드 스플리팅(code splitting) 도 함께 고려할 만하다. 페이지 전체에서 쓰는 자바스크립트를 하나의 거대한 파일로 묶지 않고, 화면별·기능별로 나눠 필요한 부분만 불러오는 방식이다. Next.js 같은 최신 프레임워크는 이 기능을 기본으로 지원하는 경우가 많아, 프레임워크 차원의 설정만 확인해도 되는 경우가 대부분이다.

서드파티 스크립트는 성격에 따라 지연 우선순위를 다르게 두는 편이 실전에서 도움이 된다. 결제·로그인처럼 화면이 뜨자마자 바로 작동해야 하는 스크립트는 지연시키면 오히려 사용성이 나빠진다. 반면 채팅 위젯, 리뷰 위젯, 광고, 방문자 추적 스크립트처럼 방문자가 페이지를 읽는 동안에는 굳이 먼저 켜져 있을 필요가 없는 스크립트는 지연 로딩의 최우선 대상이다.

스크립트 종류	지연해도 되는가	이유
결제·로그인 기능 스크립트	아니오	화면 진입 즉시 정상 작동해야 함
채팅 상담 위젯	예	화면이 뜬 뒤에 나타나도 무방
광고·배너 스크립트	예	콘텐츠보다 먼저 뜰 이유가 없음
방문자 분석(GA 등)	예	데이터 수집은 몇 초 늦어도 무방

스크립트 최적화에서 가장 큰 효과는 대개 "지우는 것"에서 나온다. 더 이상 쓰지 않는 옛날 추적 코드, 중복 설치된 분석 도구, 테스트용으로 넣고 잊어버린 스크립트를 찾아 지우는 것만으로도 페이지가 눈에 띄게 가벼워지는 경우가 흔하다. 사이트를 오래 운영할수록 이런 "죽은 스크립트"가 쌓이기 쉬우므로, 정기적으로 브라우저 개발자 도구의 네트워크 탭을 열어 실제로 어떤 요청이 오가는지 점검해 보는 편이 좋다.

서버·호스팅도 체감 속도에 영향을 줄까?

영향을 준다 — 다만 이미지·폰트·스크립트를 다 손본 뒤에 확인해도 늦지 않은 영역이다. 서버가 첫 응답을 보내는 데 걸리는 시간을 TTFB(Time To First Byte)라고 하는데, 이 시간이 길면 그 뒤에 아무리 이미지·폰트를 최적화해도 전체 로딩은 늦어질 수밖에 없다.

TTFB에 영향을 주는 요소는 크게 세 가지다. 호스팅 서버의 물리적 위치(방문자와 가까울수록 빠르다), 서버 성능 등급(공유 호스팅보다 VPS·클라우드 쪽이 대체로 여유롭다), 그리고 캐싱 설정(같은 페이지를 매번 새로 만들지 않고, 미리 만들어 둔 결과를 재사용하는 것)이다.

캐싱을 설정할 때 확인할 항목은 크게 두 갈래로 나뉜다. 브라우저 캐싱은 방문자가 한 번 받은 이미지·CSS·자바스크립트 파일을 재방문 시 다시 받지 않고 저장해 둔 파일을 그대로 쓰게 하는 설정이다. Cache-Control 헤더에 적절한 유효 기간을 지정해 두면 두 번째 방문부터는 로딩 속도가 크게 빨라진다. 서버측 캐싱은 페이지를 방문자가 요청할 때마다 새로 만드는 대신, 한 번 만들어 둔 결과를 저장해 뒀다가 다음 방문자에게 그대로 내려주는 방식이다. 콘텐츠가 자주 바뀌지 않는 블로그 글·서비스 소개 페이지에 특히 효과적이다.

압축 전송도 TTFB 이후의 전송 속도에 영향을 준다. 서버가 HTML·CSS·자바스크립트를 gzip이나 그보다 압축률이 높은 브로틀리(Brotli)로 압축해 보내면, 같은 내용이라도 전송 용량이 크게 줄어든다. 대부분의 최신 호스팅·CDN은 이 압축을 기본으로 켜 두지만, 오래된 호스팅 환경이라면 꺼져 있는 경우도 있으므로 한 번쯤 확인해 볼 만하다.

통신 프로토콜도 속도에 영향을 준다. 예전 방식인 HTTP/1.1은 한 번에 처리할 수 있는 요청 수가 제한적이지만, HTTP/2나 HTTP/3는 여러 파일을 동시에 주고받을 수 있어 이미지·폰트·스크립트가 많은 페이지일수록 유리하다. 대부분의 최신 호스팅과 CDN은 이미 HTTP/2 이상을 기본 지원하므로, 직접 설정할 일은 드물지만 오래된 서버를 그대로 쓰고 있다면 호스팅사에 지원 여부를 확인해 볼 만하다.

실무에서는 이미지·폰트·스크립트 최적화만으로 체감 속도의 상당 부분이 해결되는 경우가 많다. 그래도 그 이후에도 속도가 개선되지 않는다면, 다음 단계로 호스팅 등급이나 캐싱·압축 설정을 점검해 볼 차례다. 새로 홈페이지를 준비 중이라면 애초에 캐싱과 속도를 고려해 설계된 구조로 시작하는 편이, 이미 만든 사이트를 나중에 손보는 것보다 훨씬 수월하다.

모바일 속도부터 먼저 확인해야 하는 이유는 무엇일까?

구글은 데스크톱이 아니라 모바일 버전을 기준으로 사이트를 색인하고 평가한다(모바일 우선 색인). 코어 웹 바이탈의 필드 데이터 역시, 실제 방문자 중 모바일 비중이 높은 사이트일수록 모바일 환경의 데이터가 전체 판정에 더 크게 반영된다.

모바일 환경은 데스크톱보다 조건이 대체로 불리하다. 화면은 작지만 이동통신망을 쓸 때는 회선 속도가 더 느리고 불안정한 경우가 많으며, 기기 성능도 최신 플래그십부터 저가형까지 천차만별이다. 데스크톱 와이파이 환경에서는 빠르게 뜨던 페이지가 모바일에서는 개선 필요·불량 구간에 머무는 경우가 드물지 않다.

속도를 점검할 때는 항상 모바일 결과부터 먼저 확인하는 습관을 들이는 편이 안전하다. 페이지스피드 인사이트도 기본으로 모바일 탭을 먼저 보여주는 것이 이런 이유에서다. 데스크톱 점수가 좋다고 안심했다가 정작 모바일 방문자 대다수가 겪는 지연을 놓치는 경우를 실무에서 자주 보게 된다.

업종별로 속도 최적화, 무엇부터 손대야 효과적일까?

모든 업종에 같은 우선순위를 적용할 필요는 없다. 사이트 유형에 따라 가장 무거운 병목이 다르기 때문에, 아래 기준으로 우선순위를 조정하는 편이 효율적이다.

쇼핑몰·커머스라면 상품 이미지 개수 자체가 많아 이미지 최적화의 효과가 가장 크다. 상품 목록 페이지의 썸네일부터 WebP 전환과 지연 로딩을 우선 적용하고, 상세 페이지의 확대 이미지는 별도로 압축률을 더 높이는 것이 효율적이다.

블로그·콘텐츠 사이트라면 폰트와 서드파티 스크립트(광고, 방문자 분석, 댓글 위젯)의 영향이 상대적으로 크다. 글자가 많은 사이트일수록 폰트 로딩 방식이 체감 속도를 크게 좌우하기 때문이다.

랜딩페이지·상담 신청 페이지라면 전환이 걸린 페이지이므로 서드파티 스크립트(채팅 위젯, 광고 추적 픽셀)를 지연 로딩시키는 작업의 우선순위가 가장 높다. 상담 신청 버튼이 뜨는 순간이 늦어지면 늦어지는 만큼 이탈도 함께 늘어난다.

업종	가장 큰 병목	우선 조치
쇼핑몰·커머스	상품 이미지 다수	WebP 전환 + 지연 로딩
블로그·콘텐츠	웹폰트, 광고 스크립트	font-display: swap + 스크립트 지연
랜딩페이지·상담 페이지	서드파티 추적 스크립트	채팅·픽셀 지연 로딩
기업 소개·서비스 사이트	폰트, 히어로 이미지	font-display: swap + 대표 이미지 압축

기업 소개 사이트나 서비스 랜딩 화면처럼 첫 화면에 큰 배경 이미지와 브랜드 폰트를 함께 쓰는 구조라면, 이미지 최적화와 폰트 로딩 최적화를 동시에 진행해야 효과가 난다. 둘 중 하나만 손보면 나머지 하나가 여전히 LCP를 붙잡고 있는 경우가 많다.

나쁜 예는 업종과 무관하게 모두에게 같은 체크리스트를 똑같은 순서로 적용하는 것이다. 좋은 예는 페이지스피드 인사이트가 짚어 주는 "예상 절감 시간"이 가장 큰 항목부터, 업종별 우선순위를 참고해 순서를 조정하는 것이다.

카페24·아임웹·워드프레스 같은 환경에서는 무엇을 확인해야 할까?

직접 서버를 만지기 어려운 빌더·CMS 환경이라면, 설정 메뉴 안에서 이미 제공하는 최적화 기능부터 확인하는 것이 먼저다. 카페24·아임웹 같은 국내 홈페이지 빌더는 이미지 자동 압축, CDN 적용 같은 기능을 관리자 화면 설정 메뉴 안에 이미 갖춰 둔 경우가 많다. 직접 코드를 만질 필요 없이, 이 기능이 켜져 있는지 확인하고 꺼져 있다면 켜는 것만으로 상당 부분이 해결된다.

워드프레스를 쓴다면 이미지 최적화, 캐싱, 스크립트 지연 로딩을 각각 담당하는 플러그인을 따로 설치해야 하는 경우가 많다. 다만 플러그인을 지나치게 여러 개 설치하면 오히려 플러그인 자체가 새로운 스크립트를 추가해 속도를 갉아먹는 역설이 생길 수 있으므로, 기능이 겹치는 플러그인은 하나로 정리하는 편이 안전하다.

나쁜 예는 빌더가 이미 제공하는 최적화 기능을 모른 채 방치해 두고, 애먼 외부 플러그인부터 여러 개 설치하는 것이다. 좋은 예는 관리자 화면의 "성능" 또는 "속도" 관련 설정 메뉴부터 한 번 훑어보고, 부족한 부분만 추가로 보완하는 것이다.

디자인이 화려하면 속도는 항상 희생해야 할까?

꼭 그렇지는 않다 — 대부분의 속도 문제는 디자인의 화려함 자체가 아니라, 그 화려함을 구현하는 방식이 무거워서 생긴다. 같은 결과물을 훨씬 가벼운 방식으로 만들 수 있는 경우가 많다.

나쁜 예는 상단 배경을 고화질 동영상으로 깔아 두는 것이다. 동영상 파일은 이미지보다 훨씬 무거워서, 압축을 아무리 잘해도 LCP에 큰 부담을 준다. 좋은 예는 같은 분위기를 정지 이미지나 가벼운 CSS 그라디언트·애니메이션으로 재현하는 것이다. 방문자 대부분은 배경이 동영상인지 정지 이미지인지 신경 쓰지 않지만, 로딩이 늦어지는 것은 확실히 체감한다.

무거운 애니메이션 라이브러리도 비슷한 문제를 일으킨다. 화면 전환 효과 하나를 위해 수백 킬로바이트짜리 라이브러리를 통째로 불러오는 대신, 꼭 필요한 상호작용에만 가벼운 CSS 애니메이션을 쓰는 편이 체감 속도와 디자인 완성도를 동시에 지키는 길이다.

디자인의 완성도와 속도는 서로 다른 축이며, 방법만 바꾸면 대부분 함께 잡을 수 있다. 다만 굳이 하나를 포기해야 하는 순간이 온다면, 방문자가 아예 이탈해 버리는 속도 쪽을 먼저 지키는 편이 안전하다.

무료 도구로 스스로 하기 어려운 부분은 언제 전문가에게 맡겨야 할까?

진단 목록에 나온 항목을 하나씩 고쳐 봐도 수치가 그대로거나, 원인이 프레임워크·서버 구조 자체에 있는 경우라면 직접 손대기보다 전문가의 진단이 효율적이다. 특히 다음과 같은 상황이라면 혼자 붙잡고 있기보다 개발자나 에이전시의 도움을 받는 편이 시간을 아낄 수 있다.

첫째, 진단 목록의 항목을 다 고쳤는데도 LCP가 좀처럼 개선되지 않는 경우다. 이때는 화면에 보이지 않는 서버 응답 구조나 코드 자체의 문제일 가능성이 크다. 둘째, 이미지·폰트·스크립트를 손볼 개발 인력이나 시간이 아예 없는 경우다. 이 경우 하나씩 배워 가며 고치기보다, 처음부터 속도를 고려해 설계하는 편이 결과적으로 더 빠르고 저렴하다.

셋째, 사이트 구조 자체가 오래돼 최신 최적화 기법을 적용하기 어려운 경우다. 예전 방식으로 만들어진 사이트는 이미지 하나 바꾸는 데도 여러 페이지를 일일이 손봐야 하는 경우가 많은데, 이런 상황이라면 부분 수정보다 새로 설계하는 편이 장기적으로 유리할 수 있다.

속도가 빨라지면 SEO 말고 무엇이 더 좋아질까?

가장 직접적인 효과는 전환율이다. 로딩이 빠른 페이지일수록 방문자가 끝까지 머물러 상담 신청이나 구매 버튼까지 도달할 확률이 높아진다. 검색 순위가 그대로라도, 같은 방문자 수로 더 많은 문의를 받을 수 있다는 뜻이다.

광고를 함께 운영한다면 속도는 광고 비용에도 영향을 준다. 랜딩페이지 로딩이 느리면 광고 플랫폼이 매기는 페이지 품질 점수가 낮아져, 같은 클릭 한 번에 더 많은 비용을 지불하게 되는 경우가 흔하다. 반대로 페이지가 빠르면 같은 예산으로 더 많은 방문자를 데려올 여지가 생긴다.

서버 비용 측면에서도 이점이 있다. 이미지 용량을 줄이고 불필요한 스크립트를 정리하면 서버가 처리해야 할 트래픽 총량 자체가 줄어, 방문자가 늘어나도 서버 부담이 상대적으로 덜 커진다.

속도 최적화는 검색 노출을 위한 작업처럼 보이지만, 실제로는 이미 들어온 방문자를 놓치지 않기 위한 작업에 더 가깝다. 순위와 무관하게 투자할 가치가 있는 이유다.

오늘 바로 실행하는 속도 최적화 체크리스트

아래 항목을 순서대로 점검하면, 지금 시점에서 손댈 수 있는 대부분의 개선을 끝낼 수 있다. 이 글에서 다룬 네 영역을 우선순위와 확인 도구까지 한눈에 정리하면 아래와 같다.

영역	대부분의 경우 우선순위	확인 도구
이미지 최적화	1순위(가장 흔한 병목)	페이지스피드 인사이트, 스퀴시
폰트 로딩	2순위	개발자 도구 네트워크 탭
스크립트 지연	3순위	Lighthouse 진단 목록
서버·캐싱	4순위(위 세 가지 이후)	GTmetrix 폭포수 차트

물론 이 순서가 절대적이지는 않다. 앞서 설명한 "진단 결과 읽는 법"을 따라 본인 사이트의 실제 병목을 먼저 확인한 뒤, 이 표를 참고 순서로만 활용하는 것이 정확하다.

• 페이지스피드 인사이트로 현재 LCP·INP·CLS 수치부터 확인한다
• 화면 상단 대표 이미지를 WebP·AVIF로 변환하고 실제 표시 크기에 맞게 리사이즈한다
• 화면 아래쪽 이미지에는 loading="lazy", 상단 대표 이미지에는 fetchpriority="high" 를 붙인다
• 모든 이미지에 width·height를 명시해 레이아웃 밀림을 막는다
• 웹폰트에 font-display: swap을 적용하고, 핵심 폰트는 preload로 우선순위를 높인다
• 실제 쓰지 않는 폰트 굵기·서체를 정리해 폰트 파일 개수를 줄인다
• 콘텐츠와 무관한 스크립트(채팅, 광고, 추적 픽셀)에 defer·async를 적용하거나 지연 로딩시킨다
• 더 이상 쓰지 않는 옛날 스크립트·중복 분석 도구를 찾아 제거한다
• 서치 콘솔의 코어 웹 바이탈 보고서로 사이트 전체 URL의 양호·불량 그룹을 확인한다
• 개선 작업 후에는 반드시 다시 측정해 수치가 실제로 좋아졌는지 확인한다

한 번 최적화했다고 끝나는 작업이 아니다. 새 이미지를 올리거나 새 스크립트(예: 새 마케팅 도구)를 추가할 때마다 같은 문제가 재발할 수 있으므로, 큰 콘텐츠나 기능을 추가한 뒤에는 이 체크리스트를 다시 한번 훑어보는 습관을 들이는 편이 안전하다.

속도 점검은 홈페이지를 한 번 만들고 끝나는 일이 아니라, 새 콘텐츠를 올릴 때마다 함께 챙겨야 하는 유지보수의 일부에 가깝다. 정기적인 점검 루틴을 어떻게 잡으면 좋을지는 홈페이지 유지보수로 SEO 순위 지키는 법에서 더 폭넓게 다뤘다.

자주 묻는 질문

LCP를 2.5초 안에 못 맞추면 큰일 나나요?

당장 순위가 급락하지는 않는다. 다만 개선 필요·불량 구간에 머무는 시간이 길어질수록 이탈률이 함께 올라가는 경향이 있으므로, 완벽한 2.5초보다는 꾸준히 좋음 구간에 가깝게 개선해 나가는 방향이 현실적이다.

이미지·폰트·스크립트 중 무엇을 가장 먼저 손봐야 하나요?

페이지스피드 인사이트의 "개선할 수 있는 항목" 목록에서 예상 절감 시간이 가장 큰 항목부터 처리하는 것이 정답이다. 다만 일반적인 경향으로는 화면 상단 대표 이미지의 최적화가 가장 즉각적인 효과를 내는 경우가 많다.

WebP·AVIF로 바꾸면 화질이 나빠지지 않나요?

같은 파일 용량 기준으로는 오히려 WebP·AVIF가 JPG보다 화질을 더 잘 보존하는 경우가 많다. 압축률을 지나치게 높이지만 않으면 육안으로 차이를 느끼기 어려운 수준에서 용량만 크게 줄일 수 있다.

스크립트를 지연 로딩시키면 광고 수익이나 방문자 통계가 부정확해지지 않나요?

지연 시점을 몇 초 정도로 짧게 설정하면 대부분의 방문자 행동을 놓치지 않는다. 다만 지연 시간을 너무 길게 잡으면 일부 짧은 체류 방문자의 데이터가 누락될 수 있으므로, 적용 후 분석 도구의 수집량 변화를 한 번 확인해 보는 것이 안전하다.

속도 최적화를 직접 하기 어려운데, 처음부터 빠르게 만들 수는 없나요?

가능하다. 처음 홈페이지를 설계하는 단계에서부터 이미지 최적화·폰트 로딩·스크립트 우선순위를 고려해 만들면, 완성된 사이트를 나중에 하나씩 고치는 것보다 훨씬 적은 노력으로 더 좋은 결과를 얻을 수 있다.

이미지만 최적화해도 충분한가요?

이미지가 가장 큰 비중을 차지하는 경우가 많지만, 폰트와 스크립트 문제가 함께 있으면 이미지만 손봐서는 목표 수치에 도달하지 못할 수 있다. 페이지스피드 인사이트의 진단 목록에서 이미지 외에 다른 병목이 남아 있는지 함께 확인하는 것이 정확하다.

새로 만드는 사이트는 처음부터 100점을 목표로 잡아야 하나요?

점수 자체보다 LCP·INP·CLS 세 지표가 모두 "좋음" 구간에 들어오는지를 목표로 삼는 편이 더 현실적이다. 100점을 받아도 특정 항목이 좋음 구간에 못 미칠 수 있고, 반대로 점수가 90점대에 못 미쳐도 세 지표가 모두 좋음이면 방문자가 체감하기에는 충분히 빠른 사이트다.

속도 개선 작업은 보통 얼마나 걸리나요?

이미지 포맷 전환이나 스크립트 지연 로딩처럼 설정 변경만으로 끝나는 작업은 하루 이틀 안에도 적용할 수 있다. 다만 사이트 구조 자체를 다시 설계해야 하는 경우라면, 페이지 수와 이미지 개수에 따라 며칠에서 몇 주까지 걸릴 수 있다. 속도는 처음 설계 단계부터 고려하는 편이 나중에 손보는 것보다 훨씬 수월하다.

웹사이트 속도 최적화는 한 번에 완벽하게 끝내는 작업이 아니라, 이미지·폰트·스크립트를 순서대로 점검하고 꾸준히 유지하는 루틴에 가깝습니다. 처음부터 속도를 고려해 설계된 구조로 시작하고 싶으시다면, 이루웹이 SEO 최적화 홈페이지 제작을 통해 코어 웹 바이탈까지 고려한 사이트를 만들어 드리고 있습니다. 이루웹의 서비스를 살펴보시고, 지금 우리 사이트의 속도가 궁금하시다면 지금 상담을 신청해 주시기 바랍니다.