티스토리 뷰
반응형
원본: https://vercel.com/blog/latency-numbers-every-web-developer-should-know
웹 앱에서 웹 페이지 로드 시간과 사용자 액션에 대한 반응성은 사용자 만족도의 주요 요인이며, 두 가지 모두 네트워크 대기 시간에 의해 지배되는 경우가 많습니다.
지연 시간 자체는 사용자가 인터넷에 연결(와이파이, LTE, 5G)하고, 사용자가 연결하고 있는 서버의 거리와 그 사이의 네트워크 품질의 함수입니다.
지연 시간 숫자는 그 자체로 낮게 보일 수 있지만 빠르게 결합됩니다. 예를 들어, 300ms 링크의 3 depth 네트워크 폭포는 총 지연 시간 900ms로 이어집니다. 리액트 서버 컴포넌트와 같은 기술은 네트워크 폭포를 동일한 요청 패턴이 100배 더 빠를 수 있는 서버로 이동시킬 수 있습니다.
Metric (측정 기준) | 추정 시간 | Metric Impact (측정 영향) |
인터넷 와이파이 지연 시간 와이파이는 연결에 최소한의 지연 시간을 추가합니다. 이것은 신호가 약하거나 오래된 하드웨어로 인해 증가할 수 있습니다. |
1-4ms | TTFB, FCP, LCP |
인터넷으로의 5G 고대역(밀리미터파) 대기 시간 밀리미터파는 가장 빠르게 전개되는 모바일 기술입니다. 그러나 전파탑까지 시야가 확보된 밀집된 도시 지역에서만 사용하기에 실용적입니다. |
1-5ms | TTFB, FCP, LCP |
초당 60프레임에 대한 프레임당 사용자 공간 예산 60fps 디바이스에서는 프레임이 16ms마다 그려집니다. 그러나 실제로 프레임을 처리하는 데 시간이 조금 필요합니다. 여기서 시간은 코드가 무엇을 칠해야 하는지 계산하는 데 사용할 수 있는 시간입니다. |
5-10ms | 매끄러운 프레임 속도 |
5G 중대역 인터넷 대기시간 정규 5G 대기시간입니다. 신호가 나쁘거나 타워에 과부하가 걸린 경우 경험치가 달라질 수 있습니다. |
10-30ms | TTFB, FCP, LCP |
동일한 클라우드 영역에 있는 서비스 또는 데이터베이스에 대한 왕복 대기 시간 인터넷에 연결하지 않고 사용자와 가까운 곳에 배치된 다른 서비스에 대한 대기 시간입니다. |
10ms | TTFB, FCP, LCP |
LTE 인터넷 지연 시간 4G 셀룰러 네트워크인 LTE를 위한 일반적인 지연 시간 |
15-50ms | TTFB, FCP, LCP |
초당 60프레임의 프레임 지속 시간(frame duration) 초당 60프레임은 디스플레이 장치에서 가장 일반적인 프레임 속도입니다. 그러나 일부 최신 장치는 90 또는 120fps와 같은 더 높은 프레임 속도를 지원합니다. |
16ms | 매끄러운 프레임 속도 |
같은 대륙의 다른 도시로의 왕복 대기 시간 사용자와 같은 대륙의 지역에 배포할 경우 예상할 수 있는 대기 시간입니다. 5000km 거리에 대해 계산되므로 실제 대기 시간은 약간 더 높거나 낮을 수 있습니다. |
33ms | TTFB, FCP, LCP |
시간이 경과함에 따라 인간이 지각하는 가장 짧은 시간 사용자의 입력에 응답할 때 이 시간 이하로 머무르는 것은 사용자가 응답을 즉각적으로 인식한다는 것을 의미합니다. |
40-80ms | INP |
1MB의 CSS를 파싱하는 시간 CSS를 파싱하는 것은 브라우저가 웹페이지를 렌더링하기 위해 수행해야 하는 작업의 일부입니다. |
100ms | FCP, LCP |
1MB의 HTML을 파싱하는 시간 파싱 HTML은 브라우저가 웹 페이지를 렌더링하기 위해 수행해야 하는 작업의 일부입니다. 짧은 웹 페이지에서는 무시할 수 있는 경우가 많지만, 매우 긴 기사의 주요 요소가 될 수 있습니다. |
120ms | FCP, LCP |
3G 인터넷 지연 시간 3G 지연 시간은 오늘날 일반적으로 가장 느린 셀룰러 표준입니다. |
150ms | TTFB, FCP, LCP |
고품질 네트워크를 통해 지구 반대편까지 왕복 대기 시간(cold-potato-routing) 단일 지역에 서비스를 배포할 경우 확인해야 할 최악의 대기 시간입니다. |
150ms | TTFB, FCP, LCP |
1MB의 JS를 파싱하는 시간 자바스크립트 파싱은 CSS와 JS보다 더 빠르게 성장하는 경우가 많기 때문에 페이지 로드 시간에 큰 영향을 미칠 수 있습니다. 코드 분할은 JS 크기를 최소화하는 주요 기법입니다. |
150ms | FCP, LCP, INP |
인간이 부진하다고 인식하는 시간 사용자의 입력에 반응할 때 이 값보다 느린 응답은 기다려야 하는 것으로 인식됩니다. 200ms는 INP에서 "개선이 필요하다"는 기준이기도 합니다. |
200ms | INP |
임대 광섬유 없이 지구 반대편까지 왕복 대기 시간(hot-potato-routing) 사용자가 직접 멀리 떨어진 서버에 연결하거나 저렴한 CDN을 사용할 경우 바이트를 가장 저렴한 경로로 통과할 때부터 사용자의 대기 시간이 두 배로 증가할 수 있습니다. |
300ms | TTFB, FCP, LCP |
방법론
기기에 의존하는 숫자는 2023년형 하이엔드 안드로이드 폰으로 측정됩니다. 대부분의 노트북은 더 빨라질 것이고, 아이폰은 더 빨라질 것이며, 다른 많은 기기들은 더 느려질 것입니다.
크레딧
제프 딘(Jeff Dean)의 "모든 프로그래머가 알아야 할 최신 번호"에서 영감을 얻었습니다. 이와 같은 더 많은 숫자는 냅킨 수학(Napkin Math)을 참조하십시오.
반응형
'프론트엔드' 카테고리의 다른 글
프론트엔드 E2E 테스트 "잘" 적용하기 (컨벤션) (0) | 2024.01.11 |
---|---|
[JS] 마이크로태스크(Microtasks)와 async/await (2) | 2020.11.11 |
[JS] 프라미스 API 중 Promise.all 직접 구현해보기 (0) | 2020.11.04 |
[JS] 프라미스 Promise 알아보기 (2) | 2020.10.28 |
[JS] try...catch 그리고 에러 핸들링 (0) | 2020.10.18 |
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- EventLoop
- Component
- vue
- 우아한테크러닝
- vuejs
- asyncawait
- ReactNative
- REACT
- chartjs
- promise
- 상태관리
- Python
- 인프런
- ES6
- 프론트엔드
- jsconf
- nodejs
- frontend
- Vuex
- typeScript
- til
- js
- axios
- vue-meta
- Docker
- vue-cli
- prerender-spa-plugin
- 리액트훅
- vue-router
- JavaScript
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
글 보관함