퍼스트 인풋 딜레이편집자 확인
문서의 각 단락이 어느 리비전에서 마지막으로 수정되었는지 확인할 수 있습니다. 왼쪽의 정보 칩을 통해 작성자와 수정 시점을 파악하세요.
r1
unisquads
2026.02.24
기여도
unisquads
100%
퍼스트 인풋 딜레이 | |
정의 | 사용자의 입력(예: 마우스 클릭, 키보드 입력)이 발생한 시점부터 브라우저가 해당 이벤트에 대한 콜백 함수를 실행하기 시작할 때까지의 시간 |
측정 지표 | 웹 성능 핵심 지표(Core Web Vitals) 중 하나 |
관련 분야 | 프론트엔드 개발 웹 성능 최적화 사용자 경험 |
개발자/제안 기관 | 구글 |
최초 등장 | 2020년 5월 |
상세 정보 | |
측정 목적 | 페이지의 상호작용성과 응답성을 수치화하여 평가 |
권장 기준 | 좋음: 100밀리초 미만 개선 필요: 100밀리초 이상 300밀리초 미만 나쁨: 300밀리초 이상 |
측정 도구 | Chrome DevTools Lighthouse PageSpeed Insights CrUX 리포트 |
주요 영향 요인 | 장시간 실행되는 자바스크립트 메인 스레드 차단 큰 작업 분할 부재 |
개선 방법 | 자바스크립트 번들 크기 최소화 긴 작업을 작은 작업으로 분할 웹 워커 활용 타사 스크립트 로드 최적화 |
r1
unisquads
2026.02.24
기여도
unisquads
100%
1. 개요
1. 개요
퍼스트 인풋 딜레이는 사용자가 웹 페이지와 처음 상호작용(예: 링크 클릭, 버튼 탭, 커스텀 자바스크립트 컨트롤 사용)을 시도한 순간부터 브라우저가 실제로 그 이벤트에 대한 응답 처리를 시작할 때까지 걸리는 시간을 측정한다. 이는 페이지의 반응성을 직접적으로 나타내는 지표로, 긴 지연 시간은 사용자에게 페이지가 멈췄거나 느리다고 인식되게 만든다. 구글이 제안한 웹 성능 핵심 지표 중 하나로, 2020년 5월에 공식적으로 도입되었다.
이 지표는 주로 프론트엔드 개발과 웹 성능 최적화 분야에서 중요하게 다루어진다. 사용자가 버튼을 눌렀을 때 즉각적인 피드백(예: 로딩 아이콘 표시, 색상 변경)을 받지 못하면, 이는 낮은 사용자 경험으로 이어져 이탈률을 높일 수 있다. 따라서 개발자는 퍼스트 인풋 딜레이를 모니터링하고 개선하는 것이 필수적이다.
퍼스트 인풋 딜레이의 값은 일반적으로 밀리초 단위로 측정된다. 좋은 사용자 경험을 제공하기 위해서는 이 수치가 100밀리초 미만으로 유지되는 것이 권장된다. 이 지연 시간은 페이지 로드 초기에 발생하는 무거운 자바스크립트 실행, 메인 스레드의 정체, 또는 큰 웹 폰트 파일 로딩과 같은 요인에 크게 영향을 받는다.
r1
unisquads
2026.02.24
기여도
unisquads
100%
2. 측정 방법
2. 측정 방법
퍼스트 인풋 딜레이는 사용자가 페이지와 처음 상호작용(예: 링크 클릭, 버튼 탭, 사용자 정의 자바스크립트 컨트롤 사용)을 시작한 순간부터 브라우저가 실제로 그 이벤트에 대한 응답 처리를 시작할 때까지 걸리는 시간을 측정한다. 이는 웹 성능 핵심 지표의 일부로, 사용자 경험의 반응성을 직접적으로 반영하는 중요한 지표이다.
이 지표는 자바스크립트를 통해 실제 사용자의 상호작용 데이터를 수집하여 측정한다. 구글은 퍼스트 인풋 딜레이를 공식 웹 성능 핵심 지표로 채택하면서, 모든 실제 사용자 측정 데이터의 75번째 백분위수 값을 기준으로 평가할 것을 권장한다. 즉, 페이지 방문자의 75%가 경험한 지연 시간이 특정 임계값(현재 권장 기준은 100밀리초 미만) 내에 들어와야 좋은 점수를 받는다.
주요 측정 도구로는 실제 사용자 데이터를 수집하는 구글 애널리틱스의 Core Web Vitals 리포트와 개발 단계에서 실험실 환경에서 시뮬레이션하여 측정할 수 있는 구글 라이트하우스, Chrome DevTools의 성능 패널 등이 있다. 또한 PageSpeed Insights나 Search Console의 핵심 웹 바이탈 리포트를 통해서도 확인할 수 있다.
r1
unisquads
2026.02.24
기여도
unisquads
100%
3. 영향 요인
3. 영향 요인
3.1. 자바스크립트 실행 시간
3.1. 자바스크립트 실행 시간
자바스크립트 실행 시간은 퍼스트 인풋 딜레이에 영향을 미치는 주요 요인 중 하나이다. 브라우저의 메인 스레드가 복잡한 자바스크립트 코드를 오랜 시간 실행하고 있으면, 사용자의 입력(예: 클릭이나 키보드 타이핑)을 처리하기 위한 이벤트 콜백의 실행이 지연될 수 있다. 이는 특히 페이지 로드 초기에 많은 양의 자바스크립트를 동기적으로 실행하거나, 긴 태스크를 수행하는 경우에 두드러진다.
자바스크립트 실행으로 인한 지연을 완화하기 위한 일반적인 접근법은 코드를 최적화하는 것이다. 여기에는 불필요한 코드를 제거하고, 긴 실행 시간을 차지하는 함수를 더 작은 단위로 분할하며, 효율적인 알고리즘을 사용하는 것이 포함된다. 또한, 리액트나 뷰와 같은 현대 자바스크립트 프레임워크를 사용할 때는 가상 DOM 업데이트 및 컴포넌트 렌더링 로직이 메인 스레드 부하에 기여할 수 있으므로 주의가 필요하다.
성능 모니터링 도구인 구글 라이트하우스나 크롬 개발자 도구의 Performance 패널을 사용하면, 메인 스레드에서 실행되는 각 자바스크립트 태스크의 정확한 소요 시간과 호출 스택을 분석할 수 있다. 이를 통해 병목 현상을 일으키는 특정 스크립트나 함수를 식별하고, 최적화 작업의 우선순위를 정하는 데 도움이 된다.
3.2. 렌더링 차단 리소스
3.2. 렌더링 차단 리소스
렌더링 차단 리소스는 HTML 문서를 파싱하고 DOM 트리를 구축하는 과정을 중단시키는 외부 파일을 의미한다. 주로 <head> 섹션에 위치한 CSS 스타일시트와 <script> 태그(별도의 속성이 없는 경우)가 이에 해당한다. 브라우저는 이러한 리소스를 다운로드하고 완전히 처리하기 전까지 페이지의 렌더링을 차단하거나 지연시킨다.
이러한 차단은 퍼스트 인풋 딜레이에 직접적인 영향을 미친다. 렌더링이 차단되는 동안 브라우저의 메인 스레드는 다른 작업을 수행할 수 없게 된다. 사용자가 이 시점에 상호작용을 시도하면, 브라우저는 렌더링 차단 작업을 먼저 완료해야 하기 때문에 입력 이벤트에 대한 처리를 즉시 시작할 수 없고, 이로 인해 FID 값이 증가하게 된다.
따라서 FID를 개선하기 위해서는 렌더링 차단 리소스를 최적화하는 것이 중요하다. 주요 방법으로는 CSS를 최소화하고, 중요하지 않은 스타일은 비동기적으로 로드하거나, <link> 태그에 media 속성을 활용하는 것이 있다. 또한, 자바스크립트의 경우 async나 defer 속성을 사용하여 파싱을 차단하지 않도록 하거나, 문서 하단에 배치하여 초기 렌더링 후에 실행되게 할 수 있다.
3.3. 메인 스레드 작업량
3.3. 메인 스레드 작업량
메인 스레드 작업량은 퍼스트 인풋 딜레이에 직접적인 영향을 미치는 핵심 요인이다. 브라우저의 메인 스레드는 자바스크립트 실행, 레이아웃 계산, 스타일 재계산, 페인팅 등 페이지의 상호작용을 처리하는 대부분의 작업을 담당한다. 사용자의 입력이 발생했을 때 메인 스레드가 이미 긴 태스크를 실행 중이거나 과도하게 바쁜 상태라면, 브라우저는 해당 입력 이벤트의 처리를 즉시 시작할 수 없고 대기해야 한다. 이 대기 시간이 바로 퍼스트 인풋 딜레이로 나타난다.
메인 스레드의 작업량을 증가시키는 주요 원인은 복잡하거나 긴 실행 시간을 가진 자바스크립트 코드이다. 예를 들어, 초기 페이지 로드 시 많은 양의 데이터를 처리하거나, 복잡한 DOM 조작을 수행하는 스크립트는 메인 스레드를 장시간 독점하게 된다. 또한, 타사 스크립트나 광고 스크립트가 과도하게 로드되어 실행되는 경우도 메인 스레드의 부하를 크게 증가시킬 수 있다.
이러한 문제를 완화하기 위해서는 메인 스레드의 작업을 분석하고 최적화하는 것이 중요하다. 크롬 개발자 도구의 Performance 패널을 사용하면 메인 스레드에서 실행되는 각 태스크의 상세한 타임라인을 확인할 수 있다. 이를 통해 실행 시간이 긴 태스크를 식별하고, 해당 코드를 더 작은 단위로 분할하거나, 웹 워커를 활용하여 메인 스레드 외부로 작업을 오프로드하는 등의 최적화를 수행할 수 있다. 메인 스레드의 작업량을 관리하고 입력 응답성을 보장하는 것은 웹 성능 최적화와 우수한 사용자 경험을 제공하는 데 필수적이다.
r1
unisquads
2026.02.24
기여도
unisquads
100%
4. 개선 방법
4. 개선 방법
4.1. 코드 분할 및 지연 로딩
4.1. 코드 분할 및 지연 로딩
코드 분할은 애플리케이션의 자바스크립트 번들을 여러 개의 작은 청크로 나누는 기법이다. 이를 통해 페이지 초기 로드 시 필요한 최소한의 코드만 다운로드하고, 나머지 코드는 사용자가 특정 경로로 이동하거나 기능을 필요로 할 때 지연 로딩 방식으로 필요에 따라 가져올 수 있다. 이는 초기 페이지 로드 시 메인 스레드에서 실행되어야 하는 자바스크립트의 양을 줄여, 사용자 상호작용에 대한 응답성을 높이는 데 기여한다.
지연 로딩은 이미지, 비디오, 스크립트 등 리소스를 페이지 로드 시점이 아니라 실제로 필요해질 때까지 로딩을 미루는 전략이다. 특히, 뷰포트 밖에 있는 이미지나 사용 빈도가 낮은 컴포넌트의 코드에 적용하면 초기 로드 시간을 단축할 수 있다. 이는 메인 스레드의 부담을 줄여, 사용자의 첫 입력(예: 버튼 클릭)이 발생했을 때 브라우저가 다른 무거운 작업을 처리하는 대신 입력 이벤트에 빠르게 반응할 수 있도록 한다.
현대 프론트엔드 개발 도구와 프레임워크는 이러한 최적화를 내장 지원한다. 예를 들어, 웹팩 같은 모듈 번들러는 동적 import() 문법을 통해 코드 분할을 자동화하며, 리액트는 React.lazy()와 Suspense 컴포넌트를 활용한 컴포넌트 단위의 지연 로딩을 제공한다. 이러한 기법들은 웹 성능 최적화의 핵심 요소로, 궁극적으로 개선된 사용자 경험을 제공하는 것을 목표로 한다.
4.2. 불필요한 자바스크립트 최소화
4.2. 불필요한 자바스크립트 최소화
불필요한 자바스크립트를 최소화하는 것은 퍼스트 인풋 딜레이를 줄이는 핵심적인 방법 중 하나이다. 브라우저의 메인 스레드는 자바스크립트를 파싱, 컴파일, 실행하는 작업으로 인해 종종 바쁘게 유지된다. 사용자의 입력이 발생했을 때 메인 스레드가 이러한 자바스크립트 작업을 처리 중이라면, 입력 이벤트에 대한 콜백 함수의 실행은 그 작업이 끝날 때까지 차단되어 지연이 발생하게 된다. 따라서, 페이지 로드 초기에 실행되는 자바스크립트의 양과 복잡성을 줄이는 것이 중요하다.
불필요한 자바스크립트를 줄이기 위한 구체적인 방법으로는 사용하지 않는 코드를 제거하는 것이 있다. 번들러나 빌드 도구를 사용하여 트리 쉐이킹 기법을 적용하면, 실제로 사용되지 않는 함수나 모듈을 최종 번들 파일에서 제거할 수 있다. 또한, 타사 라이브러리나 위젯을 도입할 때는 그 필요성을 신중히 검토하고, 가능하다면 더 가볍고 효율적인 대안을 선택하거나 필요한 기능만을 추출하여 사용해야 한다.
또 다른 중요한 접근법은 자바스크립트의 실행 시점을 조절하는 것이다. 사용자 상호작용과 직접적인 관련이 없는 초기화 코드나 분석 스크립트의 실행을 지연시켜, 페이지 로드 직후의 메인 스레드 부하를 줄일 수 있다. 이를 위해 setTimeout을 이용하거나, requestIdleCallback API를 활용하여 브라우저의 유휴 시간에 작업을 수행하도록 스케줄링할 수 있다. 이러한 최적화는 메인 스레드가 사용자 입력에 더 빠르게 반응할 수 있는 여유를 만들어 준다.
4.3. 웹 폰트 최적화
4.3. 웹 폰트 최적화
웹 폰트는 시각적 디자인을 풍부하게 하지만, 로딩 방식에 따라 퍼스트 인풋 딜레이에 부정적인 영향을 미칠 수 있다. 웹 폰트 파일이 다운로드되고 렌더링될 때까지 텍스트가 보이지 않거나 대체 글꼴로 표시되는 FOIT 또는 FOUT 현상이 발생하며, 이 과정에서 메인 스레드가 차단되어 사용자 입력에 대한 응답이 지연될 수 있다.
웹 폰트 최적화의 핵심은 폰트 로딩을 최대한 빠르게 하고 렌더링 차단을 방지하는 데 있다. font-display: swap; 속성을 사용하면 시스템 글꼴로 즉시 콘텐츠를 표시한 후 웹 폰트 로딩이 완료되면 교체하는 방식으로 FID 개선에 도움이 된다. 또한, WOFF2와 같은 최신 압축 형식을 사용하고, 필요한 문자 집합만 포함하는 서브셋 폰트를 생성하여 파일 크기를 줄이는 것이 중요하다.
최적화 기법 | 설명 | FID 개선 효과 |
|---|---|---|
| 로딩 중 대체 글꼴 표시 후 교체 | 응답성 향상 |
WOFF2 형식 사용 | 효율적인 압축으로 파일 크기 감소 | 로딩 시간 단축 |
폰트 서브셋 생성 | 페이지에서 실제 사용하는 글리프만 포함 | 리소스 크기 최소화 |
사전 로딩( | 중요 폰트에 대한 우선적 다운로드 | 렌더링 차단 감소 |
이러한 최적화를 통해 웹 폰트로 인한 렌더링 지연을 줄이고, 사용자 상호작용에 대한 브라우저의 응답 속도를 높여 전반적인 사용자 경험을 개선할 수 있다.
r1
unisquads
2026.02.24
기여도
unisquads
100%
5. 관련 지표
5. 관련 지표
5.1. Largest Contentful Paint (LCP)
5.1. Largest Contentful Paint (LCP)
Largest Contentful Paint는 웹 성능 핵심 지표 중 하나로, 페이지가 로드되는 동안 뷰포트 내에서 가장 큰 콘텐츠 요소가 렌더링 완료되는 시점을 측정하는 지표이다. 이는 사용자가 페이지의 주요 콘텐츠를 인지하는 데 걸리는 시간을 평가하는 데 사용된다. 구글이 2020년 5월에 제안한 이 지표는 사용자 경험을 직접적으로 반영하는 중요한 척도로 자리 잡았다.
LCP는 주로 이미지, 비디오 요소, 또는 대규모 텍스트 블록과 같은 주요 콘텐츠의 렌더링 완료 시간을 기준으로 한다. 이 측정값은 퍼스트 인풋 딜레이나 Cumulative Layout Shift와 함께 웹페이지의 전반적인 사용자 체감 성능을 종합적으로 평가하는 데 활용된다. 좋은 사용자 경험을 제공하기 위해서는 LCP 값이 2.5초 이내여야 하는 것이 권장 기준이다.
LCP 성능에 영향을 미치는 주요 요인으로는 서버 응답 시간, 렌더링 차단 리소스, 자바스크립트 및 CSS의 렌더링 지연, 그리고 리소스 로드 시간 등이 있다. 따라서 프론트엔드 개발자는 이미지 최적화, 코드 분할, 중요 콘텐츠의 우선 로딩과 같은 웹 성능 최적화 기법을 통해 LCP 점수를 개선할 수 있다.
5.2. Cumulative Layout Shift (CLS)
5.2. Cumulative Layout Shift (CLS)
Cumulative Layout Shift(CLS)는 웹 성능 핵심 지표(Core Web Vitals) 중 하나로, 웹페이지 로딩 과정에서 발생하는 예기치 않은 레이아웃 이동의 총량을 측정하는 지표이다. 사용자가 버튼을 클릭하려는 순간에 해당 요소가 갑자기 아래로 밀려나 클릭을 방해하거나, 읽고 있던 글이 예고 없시 이동하는 경험은 사용자에게 큰 불편함을 준다. CLS는 이러한 시각적 불안정성을 수치화하여 사용자 경험의 질을 평가하는 데 사용된다.
CLS 점수는 모든 예기치 않은 레이아웃 이동에 대한 '이동 거리 비율'과 '영향 받은 영역 비율'을 곱한 값을 페이지 수명 주기 동안 누적하여 계산한다. 점수가 0.1 이하일 경우 양호한 사용자 경험으로 평가되며, 0.25를 초과하면 개선이 필요한 상태로 본다. 이 지표는 구글이 2020년 5월에 공식적으로 제안했으며, 이후 검색 엔진 최적화(SEO)의 랭킹 요소 중 하나로도 고려되고 있다.
CLS를 악화시키는 주요 원인으로는 이미지나 동영상과 같은 미디어 요소에 명시적인 크기 속성이 정의되지 않은 경우, 동적으로 삽입되는 광고나 위젯, 그리고 웹 폰트 로딩으로 인한 FOUT(Flash of Unstyled Text) 또는 FOIT(Flash of Invisible Text) 현상이 있다. 또한, 자바스크립트에 의해 DOM 요소가 갑자기 추가되거나 내용이 변경될 때도 레이아웃 이동이 발생할 수 있다.
CLS를 개선하기 위해서는 모든 미디어 요소에 width와 height 속성을 명시하고, 동적 콘텐츠를 위한 공간을 미리 확보하거나, 사용자 상호작용에 의한 응답으로만 콘텐츠가 변경되도록 설계하는 것이 중요하다. 또한, font-display: optional과 같은 속성을 사용하여 웹 폰트 로딩을 최적화하거나, CSS transform 속성을 활용하여 레이아웃 이동 없이 애니메이션을 구현할 수 있다. 이러한 최적화는 프론트엔드 개발 과정에서 꾸준히 점검해야 할 핵심 과제이다.
r1
unisquads
2026.02.24
기여도
unisquads
100%
6. 여담
6. 여담
퍼스트 인풋 딜레이는 2020년 5월 구글이 웹 성능 핵심 지표에 공식적으로 추가한 지표로, 프론트엔드 개발과 웹 성능 최적화 분야에서 중요한 관심사로 자리 잡았다. 이 지표의 도입은 단순한 페이지 로딩 속도가 아닌, 페이지가 로드된 후의 실제 사용자 경험과 상호작용 반응성을 정량적으로 평가하려는 산업의 흐름을 반영한다.
퍼스트 인풋 딜레이는 라지스트 컨텐츠풀 페인트나 큐뮬레이티브 레이아웃 시프트와 달리, 사용자의 직접적인 행동에 대한 시스템의 응답성을 측정한다는 점에서 독특하다. 이는 사용자가 느끼는 '버벅임'이나 '멈춤' 현상을 직접적으로 수치화할 수 있게 하여, 개발자에게 더욱 명확한 최적화 목표를 제공한다.
이 지표의 등장 이후, 개발자 커뮤니티와 도구 생태계는 메인 스레드의 장기 실행 작업을 분석하고 분할하는 방법, 이벤트 루프의 동작 원리, 그리고 웹 워커를 활용한 병렬 처리 등에 대한 논의와 실천이 더욱 활발해졌다. 결과적으로 퍼스트 인풋 딜레이는 현대 웹 애플리케이션이 원활한 상호작용을 보장하기 위해 필수적으로 고려해야 할 성능 기준이 되었다.