프론트엔드 개발자가 알아야 할 지연 시간 수치 정리

네트워크, 기기, 인간 인지 한계를 포괄하는 지연 시간 기준 수치를 프론트엔드 관점에서 정리한 참조 가이드다. 숫자를 외우는 것이 목적이 아니라, 아키텍처 결정을 내릴 때 직관적인 척도로 활용하기 위한 자료다.

핵심 포인트

Wi-Fi 지연은 1~4ms, 대륙 간 연결은 300ms 수준 — 깊이 3의 네트워크 워터폴이면 300ms 링크에서 총 900ms가 누적된다
60fps 디스플레이에서 한 프레임에 애플리케이션 코드가 쓸 수 있는 시간은 5~10ms뿐이다
JavaScript 1MB 파싱에 약 150ms가 소요된다 — 번들 크기가 INP에 직결된다
40~80ms 미만 응답은 즉각적으로 느껴지고, 200ms를 넘으면 느리다는 인지가 생긴다
React Server Components는 클라이언트-서버 순차 요청을 서버 내 단일 요청으로 통합해 네트워크 워터폴 지연을 최대 100배 줄일 수 있다

상세 정리

측정 기준: 2023년 고사양 Android 기기 기준. 기기·연결 품질에 따라 편차가 있으며 저가형 기기에서는 수치가 더 나쁘다.
Wi-Fi vs 모바일: Wi-Fi 1~4ms, LTE 20~50ms, 3G 200~1000ms — 모바일 타깃 앱에서 네트워크 최적화는 배가 중요하다.
대륙 간 지연: 고품질 라우팅 300ms, 저가 라우팅 최대 그 이상 — 엣지 캐싱이나 CDN 없이 먼 서버의 SSR은 TTFB만으로 300ms를 넘을 수 있다.
워터폴 누적 효과: 동일 링크에서 A→B→C 순차 요청이면 지연이 선형으로 쌓인다. RSC는 이 연쇄를 서버 내에서 처리해 클라이언트 워터폴을 제거한다.
프레임 예산: 60fps = 프레임당 16.7ms. 브라우저 오버헤드를 빼면 애플리케이션 코드에는 5~10ms만 남는다. Long Task(50ms+)는 INP 직격.
JS 파싱 비용: 1MB당 150ms — 번들 크기를 줄이는 것이 파싱 최적화에서 가장 효과적인 수단.
인간 인지 한계: 40ms 미만은 즉각, 40~80ms는 거의 즉각, 80~200ms는 약간의 딜레이 인식, 200ms 초과는 느림으로 인식.
Core Web Vitals 연결: TTFB는 서버 응답 지연, FCP/LCP는 네트워크+파싱+렌더링, INP는 프레임 예산과 JS 실행 시간의 조합으로 결정됨.
아키텍처 적용: ISR과 엣지 캐싱으로 대륙 간 TTFB를 300ms에서 수 ms로 줄이고, RSC로 클라이언트 워터폴을 제거하면 체감 속도가 크게 개선된다.

왜 읽나아키텍처·렌더링 전략을 결정하거나 Core Web Vitals를 개선할 때 숫자 기반 직관이 필요한 프론트엔드 엔지니어.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

읽음 (0)

이 글과 비슷한