웹 성능을 위한 비례적 추론
병목 현상은 전체 시간 중 가장 큰 비중을 차지하는 단계입니다. 절대적 기준을 초과하는 단계가 아닙니다.
Lighthouse는 수치를 알려줍니다. 하지만 그 수치가 문제인지 여부는 알려주지 않습니다. 각 단계를 전체의 백분율로 변환하세요. 가장 큰 백분율이 여러분의 병목 현상입니다. 절대적인 임계값을 초과하는 단계가 아닙니다. 이는 어떤 수정 사항이 실제로 여러분의 Core Web Vitals를 개선할지 바꿔놓습니다.
최종 검토: Arjen Karel (2026년 3월)
Table of Contents!
절대적 임계값의 문제점
Lighthouse는 "Render Delay가 350ms입니다."라고 말합니다. 여러분은 그것으로 무엇을 하시겠습니까?
전체 LCP가 700ms라면, 예, 350ms의 Render Delay는 문제의 절반입니다. 수정하세요.
하지만 전체 LCP가 4,200ms이고 TTFB가 3,800ms라면, 350ms의 Render Delay는 전체의 8%입니다. 그것을 0으로 수정하면 350ms가 절약됩니다. 여러분은 여전히 실패하는 3,850ms의 LCP를 갖게 됩니다. 문제의 90%는 서버에 있습니다.
맥락이 없는 절대적인 수치는 헛수고로 이어집니다. 백분율로 변환하면 병목 현상이 명백해집니다.
가장 큰 백분율부터 수정하세요
LCP와 INP 모두 여러 단계로 나뉩니다. 각 단계는 전체의 일부를 차지합니다. 가장 큰 부분이 병목 현상입니다. 그것부터 수정하세요.
이것은 복잡하지 않습니다. 하지만 얼마나 많은 성능 도구들과 최근의 AI 에이전트들이 이 단계를 건너뛰고 고정된 임계값을 초과하는 것만 최적화하는지 놀라울 따름입니다.
LCP 예시
모바일 제품 페이지의 LCP: 3,820ms(나쁨). 실제 사용자로부터의 단계별 분석:
- TTFB: 420ms (11%)
- Load Delay: 2,100ms (55%)
- Load Time: 680ms (18%)
- Render Delay: 620ms (16%)
16%의 Render Delay를 0으로 고치면 620ms가 절약됩니다. 55%의 Load Delay 문제를 해결하면 2,000ms 이상이 절약됩니다. 둘 다 실제 문제입니다. 하지만 하나가 병목 현상입니다.
Load Delay가 55%라는 것은 브라우저가 HTML을 받았지만 2초 넘게 히어로 이미지를 요청하지 않았다는 의미입니다. 브라우저가 이미지를 찾을 수 없는 것입니다. preload scanner가 볼 수 있는 HTML 내에 이미지가 없습니다. preload 힌트를 추가하면 LCP를 거의 절반으로 줄일 수 있습니다.
INP 예시
결제 페이지의 INP: 350ms(개선 필요). 단계별 분석:
- Input Delay: 70ms (20%)
- Processing: 80ms (23%)
- Presentation: 200ms (57%)
백분율이 없다면, 70ms가 특정 임계값을 초과하기 때문에 에이전트는 Input Delay를 최적화할 것입니다. 에이전트에게 백분율을 보여주면 Presentation을 목표로 합니다. 57%가 바로 시간이 소요되는 곳입니다.
Presentation(거대한 DOM, CSS containment 누락, 비용이 많이 드는 repaint)을 수정하면 INP가 350ms에서 200ms 미만으로 이동합니다. 이는 "개선 필요"에서 "좋음"으로 바뀌는 것입니다. Input Delay를 70ms에서 0ms로 고치면(가능성은 낮지만, 가정해 보면) 70ms가 절약됩니다. 하지만 여러분은 여전히 280ms로 실패하게 됩니다. 같은 노력이지만 결과는 다릅니다.
에이전트가 이 과정을 건너뛸 때 일어나는 일
비례적 맥락이 없는 AI 에이전트는 도구가 알려주는 대로 행동합니다. Lighthouse가 긴 TBT를 지적합니다. 에이전트는 TBT를 최적화합니다. 그 변경 사항은 기술적으로 정확합니다. 하지만 TBT는 문제의 20%였고 57%의 병목 현상은 그대로 방치되었기 때문에 실제 미치는 영향은 미미합니다.
저는 AI가 생성한 성능 수정 사항에서 이 패턴을 끊임없이 발견합니다. 그 수정 사항은 증상만을 해결합니다. 병목 현상은 남아있습니다. 필드 데이터는 개선되지 않습니다. 개발자는 "올바른" 최적화가 왜 아무런 효과가 없었는지 의아해합니다.
한 가지 접근 방식은 시간을 낭비합니다. 다른 하나는 실제 문제를 해결합니다.
CWV Superpowers 없이 이를 수행하는 방법
이것을 수동으로 수행할 수 있습니다. LCP의 경우: Chrome DevTools를 열고, 성능 트레이스를 실행하고, 타임라인에서 LCP 마커를 찾아 네 단계를 측정하세요. 각각을 전체 LCP의 백분율로 변환합니다. 가장 높은 백분율부터 수정하세요.
INP의 경우: Web Vitals Chrome 확장 프로그램이나 event 엔트리 유형의 PerformanceObserver를 사용하세요. INP 상호 작용을 기록하고, 세 단계의 지속 시간을 얻어 백분율로 변환하세요.
또는 단일 랩 트레이스 대신 수천 개의 실제 세션에서 수집한 필드 데이터를 사용하여 CWV Superpowers가 자동으로 수행하도록 하세요.
