브라우저
성능 측정과 병목 검증
사용자 경험 지표와 원인 분석 트레이스를 연결하고, 동일한 측정 조건과 명확한 경계에서 개선 결과를 검증합니다.
이럴 때 필요해요
단순히 진단 도구 점수만 높이는 수정 대신 사용자가 실제로 겪는 로딩 지연·입력 멈춤·화면 밀림 문제를 정확히 해결합니다.
어떻게 동작하나요?
화면을 최적화할 때 '느낌상 빨라졌다'거나 개발 서버에서 한 번 잰 숫자로 판단하면 엉뚱한 코드를 고치기 쉽습니다. 먼저 어떤 사용자 과제를 개선할지 정하고, 실제 사용자 기기·네트워크 분포를 보여 주는 필드 데이터(RUM)와 통제된 조건에서 반복 비교하는 실험실 측정(Lab)을 구분합니다. 대표적인 사용자 경험 지표인 LCP는 주요 콘텐츠 표시 속도를, INP는 클릭·키 입력 후 다음 화면이 그려지기까지의 반응성을, CLS는 레이아웃이 갑자기 밀리는 정도를 각각 다른 단위와 기준으로 측정합니다.
Lighthouse는 정해진 시뮬레이션 조건에서 초기 로딩 진단과 점수를 요약해 주지만, 단일 점수 하나가 모든 사용자 상호작용 경험을 대변하지는 않습니다. 또한 측정할 때는 프로덕션 빌드 여부, CPU·네트워크 스로틀링, 캐시 상태를 고정해 여러 번 반복 측정하고 중앙값과 분포를 비교해야 합니다. 특히 50ms를 넘긴 Long Task 시간의 단순 합계를 Lighthouse의 TBT(Total Blocking Time)와 같은 값으로 부르거나, 자체 작성한 이벤트 지연 측정값을 공식 INP라고 섞어 부르지 않도록 측정 용어의 경계를 엄격히 지켜야 합니다.
지표에서 문제를 발견했다면 네트워크 Waterfall과 Performance 메인 스레드 트레이스, React Profiler를 열어 실제 원인을 찾습니다. 히어로 이미지 지연인지, 초기 JS 번들과 긴 작업 때문인지, 직렬화된 API 요청 때문인지 가설을 세워 한 번에 하나씩 수정하고 전후 지표를 다시 비교합니다. 코드 구간을 직접 재는 User Timing(performance.mark/measure)을 쓸 때도 측정 시작과 끝, 취소 상태의 경계를 명확히 기록하고 측정되지 않은 값을 임의로 0ms로 채우지 않습니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
performance.mark('filter:start');
const result = runFilter(items);
performance.mark('filter:end');
performance.measure('filter:compute', 'filter:start', 'filter:end');User Timing API로 동기 필터 함수의 실행 구간을 기록하는 예제입니다. 여기서 측정된 값의 단위는 ms이며 순수 JS 동기 계산 시간만 포함하므로, 브라우저 페인트 완료 시간이나 공식 INP 지표로 해석하면 안 됩니다.
이 개념으로 실습하기
자주 헷갈리는 포인트
- 개발 모드(dev build)에서 단 한 번 실행해 본 결과를 프로덕션 성능 개선의 근거로 삼지 않습니다.
- Lighthouse 초기 로딩 점수만 올리고 나서 페이지 내부의 모든 복잡한 상호작용 반응성까지 빨라졌다고 주장하지 않습니다.
내 말로 설명해 보기
배열 필터링 함수의 순수 계산 시간(ms)은 줄어들었는데도 사용자가 버튼을 눌렀을 때 화면 반응이 여전히 느리다면 어떤 추가 구간을 확인해야 할까요?
함께 읽으면 좋은 개념
관련 면접 질문 3개
웹 성능 최적화는 어떤 영역으로 나누어 진행하나요?
웹 성능 최적화는 먼저 사용자가 겪는 병목을 로딩 속도(LCP), 상호작용 반응성(INP), 시각적 안정성(CLS)으로 측정한 뒤, 원인을 네트워크·메인 스레드 실행·렌더링 세 영역으로 나누어 진행합니다. 네트워크 영역에서는 이미지 포맷/크기 최적화와 캐시·코드 분할·요청 병렬화를 다루고, 실행 영역에서는 초기 JS 번들 축소와 긴 작업(Long Task) 분할·불필요한 리렌더링 제거를 다루며, 렌더링 영역에서는 강제 동기 레이아웃 제거와 레이아웃 이동 방지를 적용합니다. 무엇보다 한 번에 하나씩 가설을 세워 적용하고, 동일한 환경 조건에서 전후 지표와 실제 사용자 데이터(RUM)를 비교해 검증하는 절차가 핵심입니다.
꼬리질문과 참고자료 →프론트엔드 애플리케이션 성능은 어떤 조건과 지표로 측정하나요?
성능 측정은 먼저 개선하려는 핵심 사용자 흐름과 시작·종료 경계를 명확히 정의한 뒤, 실제 사용자 환경의 분포를 보는 필드 데이터(RUM)와 통제된 환경에서 원인을 재현하는 실험실 데이터(Lab)를 함께 활용합니다. 주요 지표로는 초기 주요 콘텐츠 표시 시간을 보는 LCP, 사용자 입력 후 다음 프레임이 그려지기까지의 반응성을 보는 INP, 화면 요소의 예기치 않은 밀림을 보는 CLS를 확인하며, Performance 탭 트레이스와 User Timing(performance.mark/measure)으로 세부 구간을 좁힙니다. 이때 측정 단위(ms, score 등)와 빌드 모드(프로덕션 빌드), 기기·네트워크 스로틀링 조건을 동일하게 기록해야 하며, 자체 측정한 동기 계산 시간이나 Long Task 합계를 공식 INP나 TBT라는 이름으로 섞어 부르지 않도록 경계를 명확히 해야 합니다.
꼬리질문과 참고자료 →Lighthouse 성능 점수가 낮을 때 병목을 어떻게 좁히고 개선하나요?
Lighthouse 총점 숫자만 보는 대신 세부 지표(FCP, LCP, TBT, CLS) 중 어느 항목이 점수를 깎고 있는지 먼저 확인하고, 이어서 네트워크 Waterfall과 Performance 메인 스레드 트레이스를 열어 실제 원인을 좁힙니다. 예를 들어 LCP가 느리다면 히어로 이미지의 용량·발견 시점(preload)·서버 응답(TTFB)이나 렌더 블로킹 CSS/JS를 점검하고, TBT(긴 작업)가 높다면 초기 번들 분할과 불필요한 서드파티 스크립트·초기 렌더링 연산량을 줄입니다. 가설을 세워 한 가지씩 수정한 뒤에는 반드시 동일한 프로덕션 빌드와 스로틀링 조건에서 여러 번 재측정해 지표 개선과 기능 회귀 여부를 함께 검증합니다.
꼬리질문과 참고자료 →