사이트가 느릴 때: TTFB 원인 진단과 개선 순서

“사이트가 느려요”라는 문제의 절반은 브라우저가 첫 바이트를 받기도 전에 이미 결정됩니다. TTFB(Time To First Byte)는 사용자가 주소를 입력한 순간부터 서버 응답의 첫 바이트가 도착할 때까지 걸린 시간으로, 이 시간이 길면 그 뒤에 아무리 이미지를 최적화해도 체감 속도는 나아지지 않습니다. 구글 기준으로 200ms 이하면 우수, 800ms를 넘으면 나쁨입니다. 1초가 넘는 TTFB는 거의 항상 고칠 수 있는 원인이 있습니다.

중요한 것은 TTFB가 하나의 숫자가 아니라 여러 구간의 합이라는 점입니다. DNS 조회 → TCP 연결 → TLS 핸드셰이크 → 서버 처리(생각하는 시간) → 첫 바이트 전송이 순서대로 쌓입니다. 어느 구간이 느린지 모르고 캐시 플러그인부터 설치하는 것은 진단 없이 약을 먹는 것과 같습니다. 이 가이드는 구간별로 측정하고, 구간별 범인을 찾고, 효과가 큰 순서대로 고치는 절차를 정리합니다. 지금 내 사이트의 구간별 시간을 바로 보고 싶다면 응답 시간 측정 도구에 URL을 넣어 DNS·연결·TLS·대기 시간을 분해해서 확인하세요.

TTFB에 포함되는 것과 포함되지 않는 것

먼저 범위를 정확히 해야 엉뚱한 곳을 고치지 않습니다. TTFB는 다음 다섯 구간의 합입니다.

1. DNS 조회 — 도메인을 IP 주소로 변환하는 시간.
2. TCP 연결 — 서버와 3-way 핸드셰이크를 맺는 시간(왕복 1회, RTT에 비례).
3. TLS 핸드셰이크 — HTTPS 암호화 협상(보통 왕복 1~2회 추가).
4. 서버 처리 시간 — 요청을 받고 HTML을 만들 때까지 서버가 “생각하는” 시간. DB 쿼리, 템플릿 렌더링, 외부 API 호출이 전부 여기에 들어갑니다.
5. 첫 바이트 전송 — 만들어진 응답의 첫 조각이 네트워크를 건너오는 시간.

반대로 TTFB에 포함되지 않는 것: HTML 다운로드 나머지, 이미지·JS·CSS 로딩, 렌더링, 자바스크립트 실행. 즉 TTFB가 180ms인데 페이지가 5초 걸린다면 범인은 서버가 아니라 프런트엔드 쪽입니다. 그런 경우에는 페이지 용량 분석으로 리소스 무게를, 압축 적용 확인으로 gzip/brotli 적용 여부를 먼저 점검하는 것이 맞습니다.

구간별로 측정하기 — curl 한 줄이면 충분

터미널이 있다면 curl의 -w(write-out) 옵션으로 모든 구간을 한 번에 잴 수 있습니다.

curl -o /dev/null -s -w "DNS:        %{time_namelookup}s
TCP 연결:    %{time_connect}s
TLS 완료:    %{time_appconnect}s
첫 바이트:   %{time_starttransfer}s
전체:        %{time_total}s
" https://example.com/

각 값은 누적 시간이므로 구간별 소요는 앞 값을 빼서 계산합니다.

• DNS 구간 = time_namelookup
• TCP 구간 = time_connect − time_namelookup
• TLS 구간 = time_appconnect − time_connect
• 서버 처리(핵심) = time_starttransfer − time_appconnect

터미널이 없거나 여러 지역에서의 체감을 보고 싶다면 응답 시간 측정 도구가 같은 분해 결과를 브라우저에서 보여줍니다. 측정은 3~5회 반복해 중간값을 보세요. 첫 요청은 DNS 캐시·서버 캐시가 비어 있어 항상 느리게 나옵니다.

구간별 범인 찾기

경험적으로 TTFB가 800ms를 넘는 사이트의 원인 1위는 서버 처리 시간입니다. DNS·TCP·TLS는 다 합쳐도 보통 200~300ms 안쪽이고, 나머지는 전부 서버가 HTML을 만드느라 쓰는 시간입니다.

효과 큰 순서대로 고치기

1. 전체 페이지 캐시(효과 최대). 매 요청마다 DB를 두드려 HTML을 새로 만드는 대신, 완성된 HTML을 저장해 뒀다가 그대로 내보냅니다. WordPress라면 캐시 플러그인, 직접 만든 앱이라면 리버스 프록시 캐시(nginx·Varnish)나 정적 생성(SSG). 서버 처리 시간이 수백 ms에서 한 자릿수 ms로 줄어듭니다.
2. DB 인덱스와 느린 쿼리 제거. 캐시가 비었을 때(로그인 사용자, 캐시 미스)도 빨라야 합니다. 느린 쿼리 로그를 켜고 100ms 넘는 쿼리에 인덱스를 추가하세요.
3. Keep-Alive와 HTTP/2·HTTP/3. 연결을 재사용하면 두 번째 요청부터 TCP·TLS 비용이 사라집니다. HTTP/3(QUIC)는 핸드셰이크 왕복 자체를 줄입니다.
4. CDN. 사용자가 여러 나라에 있다면 물리 거리(RTT)는 코드로 못 줄입니다. CDN 엣지가 TLS를 대신 종단하고 캐시된 HTML까지 내보내면 해외 TTFB가 극적으로 줄어듭니다.
5. 호스팅 업그레이드. 위를 다 해도 서버 처리 시간이 안 줄면 CPU가 느리거나 이웃이 많은 공유 호스팅일 가능성이 큽니다. 이때는 코드가 아니라 서버를 바꾸는 게 답입니다.

실전 예: 1.4초짜리 WordPress를 180ms로

실제 진단 흐름을 그대로 따라가 보겠습니다. 어느 WordPress 블로그의 TTFB가 1.4초였습니다.

측정 결과 DNS·TCP·TLS를 합쳐도 160ms — 네트워크는 멀쩡했습니다. 1.24초가 전부 서버 처리, 즉 PHP가 매 요청마다 테마 렌더링과 수십 개의 DB 쿼리를 실행하는 시간이었습니다. 페이지 캐시 플러그인 하나(WP Super Cache 계열)를 설치해 완성 HTML을 디스크에서 바로 내보내게 하자 서버 처리 시간이 45ms로 떨어졌고, TLS 1.3을 켜서 핸드셰이크도 조금 줄었습니다. 코드 수정 없이 TTFB가 1.4초 → 180ms. 진단을 먼저 했기에 이미지 최적화 같은 엉뚱한 작업에 시간을 쓰지 않은 것이 핵심입니다.

개선 후에는 TTFB 이후 구간도 점검하세요. 압축 적용 확인으로 HTML·CSS·JS에 brotli/gzip이 걸려 있는지, 페이지 용량 분석으로 전체 전송량이 적정한지 보면 첫 바이트 이후의 체감 속도까지 잡을 수 있습니다.