홈페이지 로딩 속도 개선은 “빠르게 해 주세요”라는 말만으로는 시작하기 어려워요. 어느 숫자가 느린지, 그 숫자를 무엇이 끌어내리는지 알아야 고칠 곳이 정해져요.
이 글은 구글이 쓰는 속도 기준 세 가지를 풀어 보고, 느린 원인을 사진·외부 스크립트·글꼴·서버 응답·캐시로 나눠 확인하는 법과 고치는 순서를 정리했어요. 직접 고치지 않더라도 업체와 같은 말로 이야기할 수 있게 돼요.
속도 숫자는 두 종류예요
PageSpeed Insights 같은 측정 도구는 성격이 다른 숫자 두 가지를 함께 보여 줘요.
| 구분 | 어디서 온 숫자인가 | 특징 |
|---|---|---|
| 실제 사용자 데이터 | 최근 28일 동안 크롬 사용자가 실제로 겪은 속도 | 방문자의 기기와 인터넷이 그대로 반영돼요. 데이터가 모자라면 사이트 전체 값으로 대신하거나 비어 있어요. |
| 실험실 데이터 | Lighthouse가 정해진 환경에서 한 번 잰 값 | 원인을 찾기 좋지만, 잴 때마다 조금씩 달라져요. |
PageSpeed Insights는 실제 사용자 데이터를 75번째 백분위 값으로 보여 줘요. 방문 네 번 중 세 번은 그 값보다 빠르거나 같았다는 뜻이에요.
실험실 점수는 광고 교체, 인터넷 경로, 측정 기기, 브라우저 확장 프로그램, 백신 프로그램 같은 바깥 조건 때문에도 달라져요. Lighthouse 문서도 점수 변동의 상당 부분이 Lighthouse 탓이 아니라고 설명해요. 그래서 점수 한 번보다, 같은 조건에서 몇 번 잰 값과 실제 사용자 데이터를 함께 봐요. 방문자가 적어 실제 사용자 데이터가 비어 있다면, 실험실 숫자와 아래에 소개할 명령으로 대신 판단해요.
LCP·INP·CLS, 세 가지 기준
구글은 사용자 경험을 세 숫자(Core Web Vitals)로 봐요. 기준은 모두 75번째 백분위 값이에요.
| 지표 | 무엇을 재나요 | 좋음 | 나쁨 |
|---|---|---|---|
| LCP(Largest Contentful Paint) | 첫 화면에서 가장 큰 사진이나 글 덩어리가 뜨기까지 걸린 시간 | 2.5초 이하 | 4초 초과 |
| INP(Interaction to Next Paint) | 누르거나 입력한 뒤 화면이 반응하기까지 걸린 시간 | 200ms 이하 | 500ms 초과 |
| CLS(Cumulative Layout Shift) | 보는 도중 화면이 갑자기 밀리는 정도 | 0.1 이하 | 0.25 초과 |
두 기준 사이는 ‘개선 필요’예요. INP는 2024년에 정식 기준이 되면서 예전 FID의 자리를 이어받았어요(web.dev Web Vitals). 로딩 속도 개선에서 먼저 볼 숫자는 LCP예요. 첫 화면이 뜨는 시간을 직접 재는 숫자라서예요.
LCP를 네 구간으로 나눠 봐요
LCP가 느리다는 것만으로는 고칠 곳을 알 수 없어요. web.dev의 LCP 최적화 안내는 LCP를 네 구간으로 나눠 보라고 해요.
- 서버 첫 응답(TTFB): 주소를 연 뒤 HTML의 첫 바이트가 도착하기까지
- 불러오기 시작 지연: 첫 응답 뒤 첫 화면의 큰 사진을 불러오기 시작하기까지
- 불러오는 시간: 그 사진 파일 자체를 받는 시간
- 그리기 지연: 다 받은 뒤 화면에 실제로 그려지기까지
잘 다듬어진 페이지라면 서버 첫 응답과 불러오는 시간이 각각 40% 안팎, 나머지 두 구간은 각각 10% 미만이 기준이에요. 정해진 규칙이 아니라 길잡이예요. 어느 구간이 이 비율보다 크게 늘었는지 보면 원인이 좁혀져요.
예를 들어 LCP가 3.4초인데 서버 첫 응답은 0.4초이고 불러오기 시작 지연이 1.6초라면, 브라우저가 첫 화면 사진을 늦게 발견한 거예요. web.dev는 LCP 자원을 HTML 원본에서 바로 찾을 수 있게 하라고 해요. 자바스크립트로 나중에 끼워 넣은 사진이나 CSS 배경 사진은 브라우저가 스크립트나 스타일을 처리한 뒤에야 찾을 수 있어요. 바꾸기 어렵다면 그 사진을 미리 불러오도록(preload) 높은 우선순위로 지정해요. PageSpeed Insights의 ‘LCP 분석’ 인사이트에서 이 구간을 볼 수 있어요.
원인별로 확인하고 고치는 법
아래 작은따옴표 속 이름은 PageSpeed Insights 결과 화면의 인사이트 항목이에요. 도구 버전에 따라 이름이 조금 다를 수 있어요.
첫 화면의 큰 사진
‘LCP 분석’에서 불러오는 시간이 길거나 ‘이미지 전송 개선’ 인사이트가 뜨면 사진부터 봐요. WebP·AVIF 같은 새 형식은 대체로 JPEG·PNG보다 압축이 좋아서 바꿀 수 있으면 바꾸는 게 좋아요. 화면 크기에 맞춘 사진을 따로 보내는 것(반응형 이미지)도 권장돼요(web.dev 이미지 형식 안내).
첫 화면의 큰 사진에는 지연 로딩(lazy loading)을 걸지 않아요. web.dev는 LCP 사진을 지연 로딩하면 늘 불필요한 지연이 생긴다고 경고해요. 대신 그 사진에 fetchpriority="high"를 달아 먼저 받게 해요. 한두 장보다 많이 달면 효과가 줄어요.
외부 스크립트
‘서드 파티’나 ‘렌더링 차단 요청’ 인사이트가 뜨면 외부 스크립트를 봐요. 광고, 방문 분석, 소셜 버튼, 동영상 삽입처럼 다른 회사 서버에서 불러오는 코드예요. web.dev는 화면을 그리는 데 꼭 필요하지 않다면 async나 defer로 불러오라고 해요. 화면 아래쪽에 있는 것은 스크롤해서 닿을 때 불러오고, 뚜렷한 쓸모가 없으면 빼는 것도 방법이에요. 방문 분석 도구가 여러 개라면 비동기로 불러와도 느려질 수 있어요.
글꼴
글자가 늦게 나타나거나 ‘글꼴 표시’ 인사이트가 뜨면 글꼴을 봐요. web.dev 글꼴 안내에 따르면 WOFF2는 WOFF보다 약 30% 더 압축돼요. 쓰지 않는 글자를 뺀 부분 글꼴(서브셋)로 바꾸면 파일이 크게 줄 수 있어요. font-display: swap을 쓰면 글꼴을 받는 동안 기본 글꼴로 먼저 보여 줘요. 대신 글꼴이 바뀌는 순간 글자가 살짝 밀릴 수 있어서, CLS도 함께 봐요.
반응이 늦을 때(INP)
버튼을 눌러도 한참 뒤에 반응한다면 INP를 봐요. web.dev INP 최적화 안내에 따르면 화면을 맡은 흐름(메인 스레드)에서 오래 걸리는 작업이 돌고 있으면 브라우저가 손님의 입력에 바로 답하지 못해요. 누를 때 실행되는 코드는 최소한으로 줄이고, 긴 작업은 잘게 나누고, 화면 갱신과 상관없는 일은 뒤로 미루는 게 기본이에요. 화면 구조(DOM)가 너무 크면 반응할 때마다 다시 그리는 비용도 커져요.
화면이 밀릴 때(CLS)
읽던 글이 갑자기 아래로 밀린다면 CLS를 봐요. web.dev CLS 최적화 안내는 크기를 정하지 않은 사진, 크기를 정하지 않은 광고·삽입 영상·iframe, 나중에 끼워 넣는 내용, 웹 글꼴을 흔한 원인으로 꼽아요. 사진과 영상에는 width·height를 꼭 적고, 늦게 뜨는 배너는 처음부터 자리를 비워 두면 밀림을 막을 수 있어요.
서버 첫 응답
‘LCP 분석’에서 서버 첫 응답 구간이 길거나 ‘문서 요청 지연 시간’ 인사이트가 뜨면 서버 쪽이에요. 서버 첫 응답(TTFB)은 Core Web Vitals는 아니지만, web.dev는 대략 0.8초 이하를 목표로 삼으라고 안내해요. 서버 프로그램이나 데이터 조회를 손보는 일이라 업체가 볼 일이고, 호스팅 요금제를 올리는 건 원인을 확인한 뒤에 정해요.
캐시
다시 찾아온 손님이 같은 파일을 또 받는다면 캐시를 봐요. ‘효율적인 캐시 수명 사용’ 인사이트가 단서예요. web.dev 캐시 안내는 이름에 버전이 붙어 내용이 바뀌지 않는 파일에 Cache-Control: max-age=31536000(1년)을 주고, HTML처럼 이름이 그대로인 파일은 no-cache로 매번 새로 확인하게 하라고 해요. 캐시가 맞으면 다시 찾은 손님은 네트워크를 거치지 않고 저장된 파일을 써요.
명령으로 확인하는 법
개발 담당자가 있다면 터미널에서 두 가지를 바로 볼 수 있어요. 맥·리눅스 기준이에요.
curl -o /dev/null -s -w 'TTFB %{time_starttransfer}s / 전체 %{time_total}s\n' https://example.com첫 바이트가 도착하기까지(TTFB)와 전체 시간을 초 단위로 보여 줘요. 한 번 잰 값이라 몇 번 반복해서 대략 값을 봐요. 측정하는 컴퓨터의 위치와 인터넷에 따라서도 달라져요.
curl -sI https://example.com/images/main.jpg | grep -i cache-control사진 주소를 넣으면 캐시 설정이 한 줄로 나와요. max-age 숫자가 작거나 줄이 아예 없으면 캐시 설정을 다시 볼 만해요. 다만 이름이 바뀌지 않는 파일이라면 매번 확인하게 둔 것이 맞는 설정일 수 있어요.
브라우저로 보려면 크롬에서 개발자 도구(윈도 F12, 맥 Option+Command+I)를 열고 Lighthouse 탭에서 같은 실험실 측정을 할 수 있어요.
삼삼삼 홈페이지에 직접 돌려 본 결과
2026년 10월 21일 오후 8시 39분(한국 시간)에 이 글을 쓴 컴퓨터에서 잰 값이에요.
$ curl -o /dev/null -s -w 'TTFB …' https://333.tego-x.com (5번)
TTFB 0.075s / 전체 0.075s
TTFB 0.047s / 전체 0.055s
TTFB 0.053s / 전체 0.058s
TTFB 0.052s / 전체 0.053s
TTFB 0.046s / 전체 0.053s
$ curl -sI …/_next/static/…/chunk.js | grep -i cache-control
cache-control: public,max-age=31536000,immutable
$ curl -sI https://333.tego-x.com | grep -i cache-control
cache-control: public, max-age=0, must-revalidate- 서버 첫 응답이 0.05초 안팎이에요. web.dev가 목표로 드는 0.8초보다 한참 짧아요.
- 이름에 버전이 붙는 스크립트 파일은 1년 동안 저장해 쓰게 돼 있어요.
- HTML은 매번 새로 확인하게 돼 있어요. 위 캐시 안내와 같은 설정이에요.
재다가 고칠 거리도 하나 찾았어요. 첫 화면의 큰 그림이 1.1MB짜리 PNG 파일이었어요. 위 ‘첫 화면의 큰 사진’에서 먼저 보라고 한 바로 그 항목이에요. 같은 모양 그대로 WebP 형식으로 바꿔 51KB로 줄였어요.
첫 화면 그림 hero01.png 1,101,419 바이트
→ hero01.webp 51,372 바이트 (WebP 품질 90)서버 응답, 캐시, 파일 크기처럼 명령으로 보이는 부분은 이렇게 바로 확인할 수 있어요. LCP·INP·CLS는 PageSpeed Insights로 따로 재야 해요.
고치는 순서와 다시 재는 법
LCP 네 구간 중 기준보다 가장 크게 늘어난 구간부터 손대요. 순서를 정할 근거가 아직 없다면, 위험이 작고 효과를 재기 쉬운 것부터 해요.
- 지금 값을 기록해요. 휴대전화 기준 LCP·INP·CLS, 실험실 점수, 측정 날짜.
- 첫 화면의 큰 사진: 형식, 크기, 지연 로딩 해제, 우선순위.
- 외부 스크립트: 빼거나 늦게 불러오기.
- 글꼴: WOFF2, 서브셋, font-display.
- 서버 첫 응답과 캐시.
- 같은 페이지, 같은 조건(휴대전화)으로 다시 재요.
한 번에 한 가지씩 고치고 재는 게 좋아요. 여러 가지를 한꺼번에 바꾸면 무엇이 효과였는지, 무엇이 다른 숫자를 나쁘게 했는지 알기 어려워요. 예를 들어 글꼴을 swap으로 바꾸면 글자는 빨리 떠도, 글꼴이 바뀌는 순간 화면이 밀려 CLS가 나빠질 수 있어요.
실험실 점수는 고친 직후 바로 확인할 수 있어요. 하지만 실제 사용자 데이터는 최근 28일 값이라 개선이 다 반영되기까지 시간이 걸려요. 고친 날짜를 적어 두고 4주쯤 뒤에 다시 비교해요.
업체에 이렇게 전해요
측정값과 함께 전하면 무엇부터 볼지 바로 정할 수 있어요. 아래 틀을 채워 보내요.
페이지: https://example.com (첫 화면)
측정: PageSpeed Insights 휴대전화, 10월 21일, 3회
실제 사용자 데이터: LCP 3.4초 · INP 180ms · CLS 0.05
실험실 점수: 61 · 58 · 64
LCP 분석: 불러오는 시간이 가장 김
뜬 인사이트: 이미지 전송 개선, 렌더링 차단 요청
부탁: 첫 화면 큰 사진 형식·크기 정리, 외부 스크립트 늦게 불러오기 검토삼삼삼에서 할 수 있는 것
삼삼삼 무료 진단의 ‘속도’ 항목은 렌더링 방식, Core Web Vitals, 이미지 최적화를 함께 살펴봐요. 직접 재지 못한 항목은 ‘확인 중이에요’로 표시되고, 담당자가 확인한 뒤 내용이 보여요.
측정값을 들고 삼삼삼에 로그인해 상담에 남겨 주시면, 확인해서 필요한 조치와 진행 가능한 범위를 알려 드려요. 속도 개선은 원인에 따라 작업 범위가 크게 달라서, 별도 작업이 필요하면 범위와 비용을 먼저 확인해요(결제·환불 정책).
