Core Web Vitals(LCP·INP·CLS) 초보 가이드
웹 성능의 핵심 지표인 LCP, INP, CLS를 초보자 관점에서 이해하고 기술 블로그에 적용하는 실무 점검 가이드입니다.
Core Web Vitals는 사용자가 웹페이지를 실제로 사용할 때 느끼는 성능을 측정하기 위한 핵심 지표입니다. 기술 블로그 운영자는 “내 사이트가 빠른가?”를 감으로 판단하기 쉽지만, 사용자는 첫 화면이 늦게 뜨거나, 버튼 반응이 둔하거나, 읽던 문단이 갑자기 밀리는 순간 바로 불편함을 느낍니다. Google은 이런 경험을 LCP, INP, CLS라는 세 가지 대표 지표로 설명합니다.
이 글은 성능 전문 용어에 익숙하지 않은 사람도 서민혁닷컴 같은 정적 블로그에서 바로 점검할 수 있도록 구성했습니다. 복잡한 최적화보다 먼저 각 지표의 의미, 나쁜 점수가 나오는 원인, 실무 체크리스트를 이해하는 것이 목표입니다.
세 지표 한눈에 보기
| 지표 | 전체 이름 | 무엇을 보는가 | 좋은 기준 |
|---|---|---|---|
| LCP | Largest Contentful Paint | 주요 콘텐츠가 보이는 속도 | 2.5초 이하 |
| INP | Interaction to Next Paint | 클릭, 탭, 키 입력 후 반응성 | 200ms 이하 |
| CLS | Cumulative Layout Shift | 화면 레이아웃이 갑자기 밀리는 정도 | 0.1 이하 |
LCP는 로딩 경험, INP는 상호작용 경험, CLS는 시각적 안정성을 대표합니다. 정적 블로그에서는 서버 처리보다 이미지, 폰트, CSS, JavaScript, 상업성 광고나 위젯 삽입 여부가 점수에 큰 영향을 줍니다. 이 글은 상업성 광고를 다루지 않으며, 콘텐츠 중심 사이트에서 필요한 기본 최적화에 집중합니다.
LCP: 가장 큰 콘텐츠가 빨리 보여야 한다
LCP는 화면에서 가장 큰 텍스트 블록이나 이미지가 표시되는 시점을 측정합니다. 블로그 글 상세 페이지라면 보통 제목 영역, 대표 이미지, 첫 문단 중 하나가 LCP 후보가 됩니다. 대표 이미지가 큰데 최적화되어 있지 않으면 LCP가 쉽게 나빠집니다.
LCP를 개선하려면 먼저 어떤 요소가 LCP인지 확인해야 합니다. PageSpeed Insights나 Chrome DevTools Performance 패널에서 LCP 요소를 볼 수 있습니다. 대표 이미지가 LCP라면 이미지 크기, 형식, preload 필요 여부, lazy loading 적용 여부를 점검합니다. 첫 화면 이미지에 loading="lazy"를 무조건 넣으면 오히려 늦게 로드될 수 있으므로 주의해야 합니다.
실무 체크리스트는 다음과 같습니다.
- 대표 이미지를 실제 표시 크기보다 지나치게 크게 만들지 않았는가?
- SVG, WebP, AVIF 등 적절한 형식을 사용하고 있는가?
- 첫 화면 핵심 이미지를 lazy loading으로 늦추고 있지 않은가?
- 외부 폰트가 렌더링을 오래 막고 있지 않은가?
- CSS 파일이 불필요하게 커져 초기 렌더링을 지연시키지 않는가?
- 서버 또는 CDN 응답 시간이 지나치게 길지 않은가?
정적 사이트라도 배포 위치와 캐시 전략이 나쁘면 LCP가 느려질 수 있습니다. Cloudflare Workers 같은 엣지 배포를 사용한다면 정적 사이트와 SSR 선택 기준과 함께 배포 방식을 점검해 보세요.
INP: 누른 뒤 바로 반응해야 한다
INP는 사용자의 상호작용 후 다음 화면 갱신까지 걸리는 시간을 봅니다. 예전에는 FID가 많이 언급되었지만, 현재는 더 넓은 상호작용을 보는 INP가 중요합니다. 블로그는 앱보다 상호작용이 적지만, 모바일 메뉴, 검색, 필터, 댓글 위젯, 코드 하이라이트, 무거운 스크립트가 있으면 INP가 나빠질 수 있습니다.
정적 블로그에서 INP 문제는 대부분 JavaScript가 너무 많거나, 초기 로딩 중 메인 스레드를 오래 점유하는 코드가 있을 때 발생합니다. 사용자가 메뉴 버튼을 눌렀는데 브라우저가 아직 큰 스크립트를 실행하느라 바쁘면 반응이 늦어집니다.
개선 방법은 단순합니다. 필요 없는 클라이언트 JavaScript를 줄이고, 꼭 필요한 기능만 부분적으로 활성화합니다. Astro 같은 프레임워크를 사용한다면 기본적으로 정적 HTML을 만들고, 상호작용이 필요한 컴포넌트만 hydration하는 전략이 좋습니다.
INP 점검에는 브라우저 DevTools Network 활용법이 도움이 됩니다. Network 탭에서 큰 JS 파일과 늦게 로드되는 리소스를 확인하고, Performance 탭에서 긴 작업을 찾아보세요.
CLS: 읽던 위치가 밀리지 않아야 한다
CLS는 페이지가 로드되는 동안 요소가 갑자기 움직이는 정도입니다. 글을 읽으려는 순간 대표 이미지가 뒤늦게 들어오며 문단을 밀거나, 폰트가 바뀌면서 줄바꿈이 달라지거나, 위쪽에 배너가 삽입되면 CLS가 올라갑니다. 블로그에서는 이미지 크기 미지정이 가장 흔한 원인입니다.
CLS를 줄이는 기본은 공간을 미리 확보하는 것입니다. 이미지에 width와 height를 지정하고, 동적으로 들어오는 영역에는 최소 높이를 부여합니다. 웹폰트를 사용할 때는 fallback 폰트와 크기 차이가 너무 크지 않게 조정합니다.
| 원인 | 증상 | 해결 |
|---|---|---|
| 이미지 크기 없음 | 이미지 로드 후 본문이 아래로 밀림 | width, height 또는 aspect-ratio 지정 |
| 웹폰트 지연 | 글자 폭이 바뀌며 줄바꿈 변화 | font-display 전략, fallback 조정 |
| 늦게 삽입되는 UI | 상단 메뉴나 안내 영역이 갑자기 등장 | 예약 공간 확보 |
| 동적 콘텐츠 | 관련 글, 댓글 영역이 뒤늦게 확장 | skeleton 또는 min-height 사용 |
측정 도구 선택하기
성능은 한 번 측정해서 끝나는 값이 아닙니다. 실험실 데이터와 실제 사용자 데이터가 다를 수 있습니다. PageSpeed Insights는 둘을 함께 보여 주지만, 트래픽이 적은 작은 블로그는 실제 사용자 데이터가 충분하지 않을 수 있습니다. 그럴 때는 Lighthouse, DevTools, WebPageTest 같은 도구로 반복 측정하고, 배포 후 Search Console의 Core Web Vitals 리포트를 관찰합니다.
측정할 때는 모바일 기준을 우선하세요. 데스크톱에서는 빠른 사이트도 모바일 네트워크와 저사양 기기에서는 느릴 수 있습니다. 특히 대표 이미지가 큰 기술 블로그는 모바일 LCP가 쉽게 나빠집니다.
접근성과 함께 개선하기
성능과 접근성은 따로 떨어진 주제가 아닙니다. 이미지 크기를 지정하면 CLS가 줄고, 의미 있는 alt를 넣으면 접근성이 좋아지며, 명확한 제목 구조는 사용자와 검색엔진 모두에게 도움이 됩니다. 자세한 내용은 웹 접근성 기본 — 제목·ALT·대비를 참고하세요.
실무 점검 순서
- PageSpeed Insights에서 모바일 URL을 측정합니다.
- LCP 요소가 무엇인지 확인합니다.
- 대표 이미지와 폰트, CSS 로딩을 점검합니다.
- DevTools Network에서 큰 JS 파일을 찾습니다.
- Performance 패널에서 긴 작업을 확인합니다.
- 이미지 width, height, aspect-ratio가 있는지 봅니다.
- 배포 후 Search Console Core Web Vitals 변화를 관찰합니다.
실무 주의점
점수만 보고 무리하게 최적화하면 유지보수가 나빠질 수 있습니다. 예를 들어 모든 CSS를 인라인으로 넣거나, 이미지를 과하게 압축해 품질을 해치거나, 필요한 스크립트를 무조건 제거하면 사용자 경험이 오히려 나빠질 수 있습니다. Core Web Vitals는 목표가 아니라 사용자 경험을 설명하는 신호입니다.
또한 단일 페이지 측정 결과를 전체 사이트 성능으로 착각하지 마세요. 홈, 카테고리, 글 상세, 긴 코드 블록이 있는 글은 병목이 다를 수 있습니다. 대표 템플릿별로 측정하고, 새 기능을 추가할 때마다 점검하는 습관이 중요합니다.
마지막으로 정적 블로그의 가장 큰 장점은 단순함입니다. 불필요한 클라이언트 기능을 줄이고, 이미지와 폰트를 정리하고, 안정적인 배포와 캐시 정책을 유지하면 복잡한 최적화 없이도 좋은 성능을 얻을 수 있습니다.