성능 개선 판별

성능 개선 판단 기준

느리다는 감각은 원인이 아닙니다. LCP, INP, CLS, long task, network waterfall 중 어디가 나쁜지 정하고, 변경 하나가 어떤 수치를 얼마나 바꿨는지 확인해야 다음 개선이 누적됩니다.

01

느림을 지표로 번역한다

첫 화면, 입력 지연, 흔들림, 스크롤 끊김을 각각 LCP, INP, CLS, long task 후보로 바꿉니다.

metric
02

같은 조건 기록

네트워크, CPU 제한, 캐시 상태, 기기를 고정해 측정 흔들림을 줄입니다.

baseline
03

병목 하나 선택

가장 큰 이미지, 긴 script task, 렌더 차단 CSS처럼 하나의 원인에 집중합니다.

bottleneck
04

예산에 반영한다

수치가 좋아졌다면 번들 크기나 Core Web Vitals 목표를 예산으로 남겨 회귀를 막습니다.

budget
Network
요청 수, 전송 크기, 캐시 정책 waterfall에서 늦게 시작하거나 오래 걸리는 요청을 먼저 봅니다.
load
Main thread
긴 JavaScript 작업과 layout 비용 50ms를 넘는 task가 입력 지연과 프레임 드롭을 만듭니다.
execute
Visual stability
이미지, 광고, 폰트로 인한 레이아웃 이동 공간 예약과 폰트 전략이 CLS를 좌우합니다.
stability

전후 비교 · 사용자 조건 · 부작용 점검

전후 비교 수치 없이 좋아졌다고 느끼는 변경은 성능 개선으로 기록하지 않습니다.
사용자 조건 개발자 장비가 아니라 목표 사용자 기기와 네트워크 조건에서 봅니다.
부작용 lazy loading이나 코드 분할이 다른 지연을 만들지 않았는지 확인합니다.

개선 기록 예시

병목: hero 이미지 2.8MB
변경: 1280w AVIF + preload
결과: LCP 4.1s -> 2.3s
예산: hero 이미지 250KB 이하