요소별로 어떤 문제를 푸는가
| 요소 | 해결하려는 병목 | 주의할 점 |
|---|---|---|
| 이미지 최적화 | 파일 크기 | 화질과 용량은 맞바꿈 관계라 품질 단계를 여러 개 시험해 봅니다. |
| 서버 응답 시간 | 첫 바이트까지의 지연 | 프런트엔드 최적화로는 해결되지 않습니다. |
| 캐싱 | 반복 다운로드 | 헤더를 비워 두어도 브라우저가 임의로 캐싱 정책을 추측합니다. 명시하는 편이 통제하기 쉽습니다. |
| CDN | 물리적 거리 | 외부 서비스 의존, 보안 대책(SRI 등) 필요. |
| 코드 압축 | CSS·JS 크기 | 동작은 같지만 디버깅이 어려워져 원본 소스를 따로 보관해야 합니다. |
| 지연 로딩 | 첫 화면 요청 수 | 첫 화면 이미지에는 쓰지 않고, width·height를 지정합니다. |
실제 개선 사례
사례 1. 보다폰: 서버 렌더링과 이미지 정리를 A/B 테스트로 비교
통신사 보다폰은 유료 광고 유입을 받는 랜딩 페이지를 대상으로 두 버전을 절반씩 나눠 보여 주는 A/B 테스트를 했습니다(web.dev 사례 연구 기준, 버전당 하루 약 3만 4천 방문). 개선 버전에서는 위젯 렌더링을 클라이언트에서 서버로 옮기고, 핵심 HTML을 서버에서 만들고, 히어로 이미지 크기를 줄이고 화면 밖 이미지는 불러오지 않게 했습니다. 그 결과 현장(필드) 측정 LCP가 31% 개선되어 8.3초에서 5.7초가 되었고, 판매가 8%, 방문 대비 리드 비율이 15%, 방문 대비 장바구니 비율이 11% 늘었다고 보고됐습니다. 흥미로운 점은 DOMContentLoaded 시간은 오히려 15% 늘었다는 것입니다. 한 숫자가 좋아졌다고 모든 숫자가 좋아지는 것은 아니며, 사용자가 체감하는 지표(LCP)를 기준으로 판단해야 한다는 교훈을 줍니다.
사례 2. 르노: 여러 기법을 묶고 상관관계로 효과를 추정
르노는 싱글 페이지 애플리케이션으로 만든 랜딩 페이지에 서버 렌더링, 코드 분할, Brotli 압축, HTTP/2, CDN 캐싱, 반응형·WebP·지연 로딩 이미지, 차단 스크립트 제거, 커스텀 글꼴 축소를 함께 적용했습니다(web.dev 사례 연구 기준). 2020년 초 이후 유럽 상위 5개 시장에서 LCP 2.5초 미만인 방문자 비율이 평균 51%에서 73%로 올랐습니다. 이것은 평균 LCP가 아니라 '빠른 방문자의 비율'입니다. 또 33개국 1천만 건 이상의 방문(2020년 12월~2021년 3월)을 분석해, LCP가 1초 줄 때 이탈률이 약 14%포인트 낮아지고 전환율이 약 13% 높아지는 것으로 추정했습니다. 다만 이 값은 선형 회귀로 구한 상관관계이므로 같은 개선이 다른 사이트에서 같은 결과를 낸다는 보장은 아닙니다.
가상 예시. 사진 12장짜리 소개 페이지 점검하기
아래는 실제 사이트가 아니라 설명을 위한 가상 예시입니다. 사진이 12장 있고 한 장이 400KB라면 이미지만 4,800KB(약 4.7MB)입니다. 첫 화면에는 사진 2장만 보이는데 12장을 한꺼번에 받고 있다면, 화면 밖 10장에 loading="lazy"를 주고 사진마다 width·height를 지정하는 것이 우선순위가 높은 조치가 됩니다. 반대로 첫 화면의 대표 사진(LCP 후보)에 lazy를 걸었다면 오히려 지연을 만들 수 있으니 제거해야 합니다. 실제 개선 폭은 측정해 봐야 알 수 있습니다.
직접 점검하는 순서
- 1단계 측정: 크롬 개발자 도구의 Lighthouse나 PageSpeed Insights 같은 무료 도구로 현재 LCP·INP·CLS를 확인합니다. 실사용자 데이터(필드)와 시험 환경(랩) 값은 다를 수 있습니다.
- 2단계 병목 판별: TTFB가 크면 서버·DNS·CDN, LCP만 크면 대표 이미지와 렌더링 차단 요소를 먼저 봅니다.
- 3단계 이미지: 불필요한 이미지를 제거하고, 포맷·크기를 줄이고, 첫 화면 밖 이미지에만 lazy를 적용합니다.
- 4단계 캐싱: 파일명에 버전을 붙여 오래 캐싱하고, 자주 바뀌는 HTML은 재검증(no-cache)을 씁니다.
- 5단계 재측정: 한 번에 하나씩 바꾸고 다시 측정해야 어떤 조치가 효과였는지 알 수 있습니다.
흔한 오해와 정정
- 오해: 캐시 헤더를 안 쓰면 캐싱이 꺼진다. 실제: web.dev는 Cache-Control 헤더를 생략해도 HTTP 캐싱이 꺼지지 않으며 브라우저가 정책을 추측한다고 설명합니다.
- 오해: 모든 이미지에 lazy를 걸면 무조건 빨라진다. 실제: 첫 화면에 보이는 이미지, 특히 LCP 이미지에는 쓰지 말라고 권장됩니다. 또 이미지 크기를 지정하지 않으면 레이아웃 이동이 늘 수 있습니다.
- 오해: CDN을 쓰면 항상 빨라진다. 실제: MDN은 제3자 연결로 DNS 조회 등이 늘어 오히려 성능이 떨어질 수 있다고 설명합니다. 지역과 구성에 따라 다릅니다.
- 오해: 압축하면 코드가 바뀐다. 실제: 공백·주석 제거는 동작을 바꾸지 않습니다. 다만 압축된 파일은 읽기 어려워 원본을 별도로 관리해야 합니다.
한계와 더 알아볼 점
이 글의 임계값(2.5초, 200밀리초, 0.1)은 web.dev가 현재 제시하는 기준이며 지표와 기준은 바뀔 수 있습니다. INP가 FID를 대체한 것이 그 예입니다. 사례 연구의 수치는 해당 회사의 트래픽·구조에서 나온 결과로, 특히 르노의 효과 추정은 상관관계입니다. 속도가 곧바로 순위나 매출을 결정한다고 단정할 근거는 이 글에서 확인한 자료에 없습니다.
이어서 읽어보세요
서버 성능이 사이트 속도에 미치는 영향이 궁금하다면 웹 호스팅 종류 완전정복도 확인해보세요. 전송 거리를 줄이는 방법은 CDN 기초 가이드, 이미지 포맷 선택은 이미지 파일 형식 가이드, 파일 용량 줄이기는 이미지 압축 가이드, 통신 방식의 변화는 HTTP 프로토콜 발전사에서 이어 볼 수 있습니다.
자주 묻는 질문
내 웹사이트 속도는 어떻게 확인하나요?
구글의 페이지스피드 인사이트 같은 무료 도구를 사용하면 웹사이트의 로딩 속도를 측정하고 개선할 점을 구체적으로 제안받을 수 있습니다. 크롬 개발자 도구의 Lighthouse로도 같은 종류의 진단을 할 수 있습니다.
CDN을 사용하면 정말 효과가 있나요?
방문자와 가까운 서버에서 사본을 내려주므로 지연 시간과 원본 서버 부담을 줄이는 데 도움이 됩니다. 다만 MDN이 지적하듯 외부 서비스에 의존하게 되고 상황에 따라 연결 단계가 늘 수도 있으니, 적용 전후를 측정해 비교하세요.
실험실 점수와 실제 사용자 데이터가 왜 다른가요?
랩 측정은 정해진 환경에서 한 번 재는 값이고, 필드 데이터는 다양한 기기·네트워크를 쓰는 실제 방문자의 값입니다. Core Web Vitals 통과 여부는 방문자의 75번째 백분위 기준으로 판단합니다.
캐시를 오래 잡으면 수정한 파일이 안 바뀌지 않나요?
파일 이름에 버전이나 해시를 넣으면 내용이 바뀔 때 주소가 달라지므로, 오래 캐싱해도 새 파일을 바로 받게 됩니다. 자주 바뀌는 HTML 문서는 재검증 방식(no-cache)을 쓰는 것이 일반적인 접근입니다.
TTFB가 높으면 무엇부터 봐야 하나요?
TTFB에는 리디렉션, DNS 조회, 연결·TLS 협상, 서버 처리가 모두 들어 있습니다. 어느 구간이 긴지 개발자 도구의 네트워크 타이밍으로 나눠 본 뒤 호스팅·CDN·서버 로직 순으로 좁혀 갑니다.