Core Web Vitals는 “PageSpeed 100점 만들기” 요령이 아니라 실제 사용자가 로딩, 입력 반응, 화면 안정성을 어떻게 경험했는지 보는 지표다. 최적화 전에는 먼저 같은 URL과 같은 조건에서 데이터를 모아야 한다.
현재 기준과 해석
Google의 Core Web Vitals 기준 설명에 따르면 좋은 범주의 경계는 다음과 같다.
| 지표 | 무엇을 보는가 | 좋은 범주 | 현장 데이터 판단 |
|---|---|---|---|
| LCP | 가장 큰 콘텐츠가 보인 시점 | 2.5초 이하 | 페이지 방문의 75번째 백분위수 |
| INP | 상호작용 후 다음 화면 갱신까지 | 200ms 이하 | 페이지 방문의 75번째 백분위수 |
| CLS | 예상하지 못한 레이아웃 이동 누적 | 0.1 이하 | 페이지 방문의 75번째 백분위수 |
한 번 실행한 Lighthouse 점수는 실험실 데이터다. 실제 사용자의 INP와 네트워크 분포를 그대로 재현하지 못한다. Google도 Web Vitals 측정 도구 안내에서 현장 데이터와 실험실 도구의 역할을 구분한다.
이 저장소에서 확인한 성능 관련 코드
2026년 7월 23일 기준으로 다음 구현을 확인했다.
| 파일 | 구현 | 확인할 위험 |
|---|---|---|
| quartz/components/Head.tsx | 핵심 CSS와 beforeDOMReady 스크립트를 preload | 실제 LCP 자원과 일치하는지 확인 필요 |
| quartz/components/Head.tsx | Google Fonts preconnect와 stylesheet | 폰트 요청이 첫 렌더링을 늦추는지 확인 필요 |
| quartz/components/Head.tsx | 외부 광고 스크립트를 async로 로드 | 네트워크·메인 스레드 영향은 별도 측정 필요 |
| quartz/components/frames/DefaultFrame.tsx | 외부 방문자 배지 이미지 표시 | 고정 너비가 없어 응답 크기에 따라 이동 가능 |
| quartz.config.yaml | SPA 전환과 popover 활성화 | 초기 JavaScript와 상호작용 비용 확인 필요 |
preload가 있다고 해서 자동으로 빨라지는 것은 아니다. 사용하지 않는 자원을 높은 우선순위로 받으면 오히려 중요한 요청과 경쟁할 수 있다.
재현 가능한 측정 순서
1. 같은 커밋을 빌드한다
이 프로젝트는 Node.js 22 이상을 요구한다.
git rev-parse --short HEAD
.\.tools\node-v22.16.0-win-x64\node.exe .\quartz\bootstrap-cli.mjs build --bundleInfo
public 폴더가 이전 빌드 결과를 포함할 수 있으므로, 측정 기록에는 빌드 시각과 커밋을 반드시 적는다.
2. 큰 정적 자산을 찾는다
PowerShell에서는 다음 명령으로 생성 파일을 크기순으로 볼 수 있다.
Get-ChildItem public -Recurse -File |
Sort-Object Length -Descending |
Select-Object -First 20 FullName, Length
파일이 크다는 사실만으로 LCP 원인이라고 결론 내리면 안 된다. 해당 페이지가 실제로 요청하는지, 초기 렌더링 전에 필요한지 Network waterfall에서 확인한다.
3. 로컬 서버에서 같은 페이지를 여러 번 측정한다
python -m http.server 8080 --bind 127.0.0.1 --directory public
그다음 Chrome DevTools Performance 패널 또는 Lighthouse에서 같은 뷰포트와 throttling 조건으로 최소 여러 번 실행한다. 첫 실행과 캐시된 실행을 섞지 않는다. 중앙값과 범위를 함께 기록한다.
4. 배포 URL의 현장 데이터를 확인한다
PageSpeed Insights와 Search Console의 Core Web Vitals 보고서는 배포된 URL의 CrUX 데이터가 충분할 때 현장 지표를 보여준다. 트래픽이 적은 페이지는 URL 단위 데이터가 없거나 origin 단위로 묶일 수 있다.
지표별 원인 추적
LCP
- Performance 패널에서 LCP 요소가 제목인지 이미지인지 찾는다.
- 그 자원의 요청 시작, TTFB, 다운로드 시간을 분리한다.
- 첫 화면 이미지라면 실제 표시 크기보다 과도하게 큰 원본인지 확인한다.
- 서버 응답이 느리면 이미지 포맷보다 캐시와 배포 경로를 먼저 본다.
WebP의 특성과 압축 도구는 Google WebP 공식 문서에서 확인할 수 있다. “항상 몇 퍼센트 감소”라는 수치는 이미지 종류와 품질 조건 없이 재사용하면 안 된다.
CLS
- 이미지, iframe, 광고, 외부 배지가 처음부터 공간을 예약하는지 본다.
- width와 height 또는 aspect-ratio를 지정한다.
- 폰트 교체 전후 글자 폭 변화가 큰지 확인한다.
- 사용자 입력 없이 위쪽에 콘텐츠를 삽입하지 않는다.
현재 방문자 배지는 height만 인라인으로 지정한다. 실제 응답 이미지의 가로 길이가 바뀌는지 측정한 뒤 width 또는 aspect-ratio를 정하는 것이 안전하다.
INP
- 느린 상호작용을 Performance 패널로 기록한다.
- 이벤트 처리, 스타일 계산, 레이아웃, 페인트 중 긴 구간을 찾는다.
- 도구 계산기가 모든 입력 이벤트마다 큰 DOM을 다시 만드는지 확인한다.
- 필요하면 작업을 나누되, 고정 300ms debounce를 만능값처럼 적용하지 않는다.
Long Task API의 현재 표준화 상태와 50ms 기준은 W3C Long Tasks 문서에서 확인할 수 있다.
비교 기록 템플릿
| 필드 | 변경 전 | 변경 후 |
|---|---|---|
| 커밋 | ||
| URL | ||
| 장치·뷰포트 | ||
| throttling | ||
| LCP 중앙값·범위 | ||
| CLS 중앙값·범위 | ||
| 실험실 TBT | ||
| LCP 요소 | ||
| 전송 바이트 |
INP는 실제 상호작용이 없는 Lighthouse 실행에서 직접 측정할 수 없다. 실험실에서는 TBT 같은 보조 지표를 보고, 최종 판단은 현장 INP로 한다.
한계
- 이번 콘텐츠 수정에서는 PageSpeed Insights나 CrUX의 최신 현장 값을 수집하지 않았다.
- 따라서 이 사이트가 세 지표를 통과한다고 주장하지 않는다.
- 기존 public 폴더의 파일 수와 크기는 이전 빌드가 섞일 수 있어 성능 결과로 인용하지 않았다.
- preload, lazy loading, Web Worker는 원인을 확인한 뒤 적용해야 한다.
- 광고·분석·방문자 배지 같은 제3자 자원은 응답 시간이 운영자 통제 밖에 있다.
- Core Web Vitals 개선은 검색 순위나 광고 성과를 보장하지 않는다.
성능 글의 결론은 팁 목록이 아니라 “어떤 커밋을 어떤 조건에서 측정했고 무엇이 얼마나 바뀌었는가”여야 한다. 측정값이 없으면 개선 가능성만 말하고 결과는 보류하는 편이 정확하다.