프론트엔드 공부를 하다 보면 성능 최적화 이야기를 정말 많이 듣게 된다.

• 렌더링 최적화
• bundle size 감소
• memoization
• virtualization

그런데 막상 서비스를 만들다 보면, 생각보다 더 자주 체감되는 건 네트워크 속도 문제였다.

분명 React 렌더링은 빠른데

• API 응답이 늦게 오고
• 첫 화면이 늦게 뜨고
• 버튼 누른 뒤 반응이 한 박자 늦는다

결국 사용자 입장에서 중요한 건

“얼마나 빨리 반응하냐”

에 가까웠다.

그 과정에서 자주 보게 되는 개념이 바로 Latency(지연 시간)다.

이번 글에서는 Latency가 정확히 뭔지, 웹 성능과 왜 연결되는지 정리해보려 한다.

---

Latency란?

Latency는 간단히 말하면

요청을 보내고 응답을 받을 때까지 걸리는 시간

이다.

예를 들어 브라우저가

GET /api/user

요청을 보냈다고 해보자.

그럼 내부적으로는 생각보다 많은 과정이 발생한다.

브라우저
  ↓
DNS 조회
  ↓
서버 연결(TCP)
  ↓
HTTPS 연결(TLS)
  ↓
서버 요청 전달
  ↓
서버 응답 생성
  ↓
브라우저 응답 수신

우리가 흔히 "응답이 느리다"고 느끼는 건 이 전체 과정에서 발생하는 시간 때문이다.

---

왜 모바일에서 더 체감될까?

개발할 때는 대부분 빠른 Wi-Fi 환경을 사용한다.

그래서 성능 문제가 잘 안 느껴질 때가 많다.

그런데 실제 사용자 환경은 다르다.

• 지하철
• LTE
• 불안정한 공용 Wi-Fi
• 해외 로밍

같은 환경에서는 Latency가 훨씬 커진다.

예를 들어

네트워크	평균 지연 시간
Wi-Fi	매우 낮음
4G	중간
3G	높음
2G	매우 높음

3G 환경에서는 요청 하나마다 수백 ms씩 지연될 수도 있다.

여기에

• API 여러 개
• 이미지 요청
• 폰트 요청

까지 겹치면 체감 속도는 급격하게 느려진다.

---

첫 요청이 특히 느린 이유

처음 요청은 단순히 API만 호출하는 게 아니다.

그 전에

DNS Lookup
→ TCP Handshake
→ TLS Handshake

과정을 먼저 거친다.

즉

• 서버 주소 찾기
• 연결 생성
• HTTPS 보안 연결

비용이 포함된다.

그래서 첫 요청(TTFB)이 상대적으로 느리다.

반대로 두 번째 요청부터는 이미 연결이 유지되고 있어서 더 빨라진다.

---

Chrome DevTools에서 보면 보이는 것들

Chrome DevTools → Network 탭을 열어보면 요청 시간들이 꽤 자세하게 나온다.

처음엔 그냥 지나쳤는데, 알고 보니 각각 의미가 있었다.

---

DNS Lookup

example.com → IP 주소 변환

과정.

도메인이 많아질수록 DNS 조회도 늘어난다.

---

TCP Handshake

브라우저와 서버가 실제 연결을 맺는 과정.

쉽게 말하면

"우리 이제 통신 시작하자"

정도 느낌이다.

---

TLS Handshake

HTTPS 보안 연결 생성 과정.

보안 연결은 필수지만 비용도 존재한다.

---

Waiting (TTFB)

서버가 응답을 생성하는 시간.

예를 들어

• DB 조회
• SSR 렌더링
• 인증 처리

같은 작업이 오래 걸리면 여기 시간이 길어진다.

---

Receiving

실제 다운로드 시간.

파일 크기가 클수록 오래 걸린다.

예

• 큰 이미지
• 무거운 JS bundle
• 큰 JSON 응답

등.

---

그래서 요청 수가 중요하다

예전에는

"코드 실행 속도"

만 성능이라고 생각했는데 실제 서비스에서는 요청 수가 더 중요할 때도 많았다.

예를 들어

API 10개 요청

이 발생하면 요청마다 Latency가 누적된다.

특히 모바일 환경에서는 이 차이가 꽤 크게 체감된다.

그래서 프론트엔드 최적화에서는

• unnecessary fetch 제거
• API 합치기
• 이미지 최적화
• 캐싱

같은 작업이 중요해진다.

---

체감 성능을 줄이는 방법

재밌는 건 실제 속도보다

"빠르게 느껴지게 만드는 것"

도 굉장히 중요하다는 점이다.

대표적인 게 Optimistic UI다.

예를 들어

• 좋아요
• 채팅
• 장바구니

같은 기능은 서버 응답 전에 먼저 UI를 업데이트한다.

즉

응답 기다리기

가 아니라

일단 보여주기
→ 나중에 검증

방식이다.

실제 네트워크 속도는 그대로여도 체감 Latency는 훨씬 줄어든다.

---

결국 핵심은

웹 성능은 단순히 React 렌더링 속도만의 문제가 아니다.

실제로는

• 네트워크
• 서버 응답
• 연결 생성
• 파일 다운로드

비용이 더 큰 경우도 많다.

특히 모바일 환경에서는

"몇백 ms 차이"

가 UX에 엄청 큰 영향을 준다.

그래서 프론트엔드 성능 최적화는 결국

• 렌더링 최적화
• 네트워크 최적화
• 캐싱 전략
• 요청 구조 설계

전부 함께 고려해야 하는 문제에 가까웠다.