워드프레스 TTFB 줄이기｜캐시·서버 원인 20분 진단

워드프레스 페이지를 열었을 때 화면이 한동안 비어 있다면 이미지보다 첫 HTML 응답이 늦는 문제일 수 있습니다. TTFB(Time to First Byte)는 탐색을 시작한 시점부터 브라우저가 응답의 첫 바이트를 받을 때까지의 시간입니다. DNS 조회, 연결, 리디렉션, 서버 처리와 네트워크 이동이 함께 반영되므로 “서버 사양이 낮다”는 결론부터 내리면 원인을 놓치기 쉽습니다.

TTFB 기준은 진단용으로 해석하기

web.dev는 대부분의 사이트가 참고할 거친 기준으로 0.8초 이하를 양호, 0.8초 초과 1.8초 이하를 개선 필요, 1.8초 초과를 느림으로 제시합니다. 다만 TTFB 자체는 Core Web Vitals 항목이 아닙니다. 지역과 네트워크가 다른 한 번의 실험실 측정만으로 호스팅을 바꾸지 말고 실제 사용자 데이터와 LCP·FCP에 미치는 영향을 함께 봐야 합니다.

Chrome에서 문서 요청을 3회 기록하기

1. 시크릿 창에서 테스트할 URL을 엽니다.
2. 개발자 도구의 Network에서 유형이 document인 첫 요청을 선택합니다.
3. 리디렉션 횟수, 상태 코드, 응답 헤더와 Timing의 대기 구간을 기록합니다.
4. 캐시를 비운 첫 방문과 반복 방문을 각각 세 번 측정합니다.
5. 홈, 일반 글, 가장 느린 글을 같은 시간대에 비교합니다.

PageSpeed Insights의 실험실 결과와 현장 데이터가 다를 수 있다는 점도 중요합니다. web.dev 설명처럼 실험실의 서버 응답 감사는 DNS와 리디렉션을 제외한 일부 구간을 보여줄 수 있습니다. 현장 TTFB만 높다면 방문자 지역, 리디렉션 또는 캐시 제외 조건처럼 실험실에서 재현되지 않은 요인을 먼저 확인하세요.

캐시 HIT와 MISS를 먼저 분리하기

같은 URL의 첫 요청은 느리고 두 번째부터 빨라지면 페이지 캐시가 생성되는 과정일 수 있습니다. 응답 헤더에 호스팅이나 CDN의 캐시 상태가 표시된다면 HIT와 MISS를 나누어 기록하세요. 단, 헤더 이름은 서비스마다 다르므로 특정 문자열만 보고 단정하지 않습니다. 로그인 쿠키, 장바구니, 미리보기와 쿼리 문자열 때문에 의도적으로 캐시가 제외되는 경우도 있습니다.

페이지 캐시는 완성된 HTML을 재사용하고, 객체 캐시는 데이터베이스 조회 결과를 재사용합니다. 둘은 다른 계층입니다. WP_CACHE 값을 켰다는 사실만으로 Redis나 페이지 캐시가 작동하는 것도 아닙니다. 실제 응답 헤더와 캐시 플러그인 상태를 확인한 뒤 워드프레스 캐시 플러그인 설정 점검을 진행하세요.

캐시 MISS도 느리다면 서버 처리 분리하기

로그인 화면이나 캐시에서 제외된 요청이 느릴 때는 PHP, 데이터베이스 쿼리, 외부 API를 분리합니다. Query Monitor에서 총 페이지 생성 시간, 느린 쿼리, 호출한 플러그인과 HTTP API 요청을 확인하세요. 단순히 플러그인 수가 많다는 이유보다 실제 오래 걸린 요청과 쿼리를 근거로 판단해야 합니다. 자세한 절차는 Query Monitor로 느린 플러그인 찾기에서 확인할 수 있습니다.

모든 요청에서 자동 로드 옵션이 커 보인다면 wp_options autoload 점검 방법을 참고하세요. 반복 조회가 많은 사이트는 호스팅이 지원하는 경우 Redis 객체 캐시 설정도 검토할 수 있습니다. 삭제와 변경 전에는 데이터베이스 백업과 복구 경로를 먼저 준비해야 합니다.

원인별 조치와 확인 증거

Server-Timing으로 백엔드 구간 나누기

서버 코드를 관리할 수 있다면 Server-Timing 응답 헤더에 데이터베이스, 외부 API, 템플릿 처리 시간을 기록할 수 있습니다. MDN은 이 헤더가 서버 처리 지표를 브라우저 개발자 도구와 Performance API에 전달한다고 설명합니다. 헤더를 추가했다고 속도가 빨라지는 것은 아니며, 공개해도 되는 지표 이름과 범위만 사용해야 합니다.

20분 점검 순서

1. 홈과 문제 URL을 시크릿 창에서 각각 세 번 측정합니다.
2. 첫 방문·반복 방문과 로그인·로그아웃 결과를 나눕니다.
3. 3xx 리디렉션과 캐시 HIT·MISS 여부를 적습니다.
4. 캐시 제외 요청은 Query Monitor로 PHP·DB·외부 API를 구분합니다.
5. 변경 후보 하나만 스테이징에서 적용합니다.
6. 같은 URL, 시간대와 측정 방법으로 전후 값을 비교합니다.

TIP

“TTFB가 2초였다”는 기록만 남기지 말고 “로그아웃 첫 방문 MISS 2.0초, 반복 HIT 0.4초, 로그인 1.7초”처럼 조건을 함께 적으세요. 이 기록은 캐시 문제와 동적 서버 처리 문제를 바로 분리해 불필요한 플러그인 교체나 서버 업그레이드를 줄여줍니다.

아래 값은 2026년 9월 21일 같은 Windows 클라이언트에서 curl.exe로 SJSBiz 홈과 이 글을 각각 5회 요청한 결과입니다. 가장 빠른 값 하나가 아니라 5회 전체 값과 중앙값을 기록했고, HTTP 상태·응답 크기·캐시 헤더도 함께 확인했습니다.

실제 공개 URL을 반복 요청한 결과

쿼리 문자열 없이 독자가 실제 방문하는 URL을 요청했습니다.

홈의 첫 요청은 0.336초였지만 이후 네 번은 0.049~0.059초였습니다. 첫 요청만 제외해 성능을 발표하지 않고 전체 값과 중앙값을 함께 남깁니다.

사용한 형식은 다음과 같습니다.

curl.exe -sS -o NUL `
  -w "code=%{http_code} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}`n" `
  "https://sjsbiz.com/"

서로 다른 쿼리를 붙여 요청한 결과

각 요청에 서로 다른 ?ttfbaudit=... 값을 붙여 같은 경로라도 별도 URL처럼 요청했습니다.

동일한 쿼리 URL을 5회 반복했을 때도 홈 중앙값은 0.286초, TTFB 글은 0.292초였습니다. 쿼리 없는 URL보다 느렸고 응답 크기도 달랐습니다.

캐시 헤더와 해석 제한

두 조건에서 공통으로 확인된 주요 헤더는 다음과 같습니다.

HTTP/1.1 200 OK
Server: Apache
Cache-Control: public, max-age=60, s-maxage=120
X-Cache: Miss from cloudfront

모든 요청이 X-Cache: Miss from cloudfront였으므로 빠른 결과를 CloudFront HIT 때문이라고 설명할 수 없습니다. 반대로 이 헤더만 보고 서버 내부 캐시가 전혀 작동하지 않았다고 단정할 수도 없습니다. CloudFront 앞뒤의 연결 재사용, WordPress·서버 내부 캐시, 쿼리 문자열 처리와 순간 부하가 함께 영향을 줄 수 있습니다.

특히 쿼리 유무에 따라 응답 크기와 TTFB가 함께 달라졌으므로 두 결과를 같은 페이지의 단순 반복 측정으로 섞으면 안 됩니다. 실제 사용자 URL의 성능을 볼 때는 쿼리 없는 URL을 기준으로 삼고, 캐시 우회 시험은 별도 조건으로 표시해야 합니다.

이 사례에서 사용할 판정 원칙

1. 동일한 URL·로그인 상태·클라이언트에서 여러 번 측정합니다.
2. 첫 요청과 이후 요청을 모두 남깁니다.
3. 평균 하나보다 전체 값과 중앙값을 함께 봅니다.
4. TTFB뿐 아니라 HTTP 상태, 응답 크기와 캐시 헤더를 기록합니다.
5. 쿼리 문자열·쿠키·로그인 여부가 달라지면 별도 실험으로 취급합니다.
6. 단일 지역·단일 시점 결과를 전체 사용자의 성능으로 일반화하지 않습니다.

검증 범위: 이 측정은 2026년 9월 21일 한 Windows 클라이언트에서 수행한 사례입니다. 다른 지역·시간·네트워크에서는 값이 달라질 수 있으며, TTFB 전체를 PHP 실행 시간이나 CDN 시간으로 해석하지 않습니다.

공식 자료

• web.dev TTFB 측정과 최적화
• MDN Server-Timing 응답 헤더
• WordPress 성능 최적화 안내
• WordPress 캐시 안내

검증 기준 2026년 9월 2일 curl 공식 문서를 확인했습니다. 아래 명령의 결과는 독자가 자신의 URL에서 기록하는 값이며 SJSBiz의 성능 측정 결과가 아닙니다. 캐시, 지역, 네트워크와 서버 부하에 따라 값은 달라집니다.

TTFB는 같은 조건에서 반복 측정한다

한 번의 PageSpeed 점수만으로 서버 병목을 단정하지 않습니다. 로그인하지 않은 같은 URL을 같은 위치에서 최소 3회 요청하고 중앙값을 기록합니다. 첫 요청과 이후 요청은 페이지 캐시·CDN 캐시 상태가 다를 수 있으므로 응답 헤더도 함께 저장합니다.

curl -sS -o /dev/null -w "status=%{http_code} ttfb=%{time_starttransfer} total=%{time_total} redirect=%{time_redirect}
" https://example.com/

curl 공식 매뉴얼에서 time_starttransfer는 요청 시작부터 첫 바이트를 받기까지의 시간이며, 연결과 사전 전송 시간 및 서버가 응답을 계산한 시간을 포함합니다. 따라서 이 수치 전체를 PHP 실행 시간이라고 표현하지 않습니다.

변경은 한 계층씩, 오류가 생기면 원복

페이지 캐시, 객체 캐시, PHP 설정, CDN을 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 알 수 없습니다. 한 계층씩 적용하고 같은 표를 다시 측정합니다. 5xx 오류, 로그인·관리자·결제 기능 이상 또는 중앙값 악화가 나타나면 해당 변경을 원복하고 관련 캐시를 순서대로 비운 뒤 재확인합니다.

문서 확인·수정 이력: 2026-09-02 — curl 반복 측정 명령, 캐시 상태 기록표와 계층별 원복 기준을 추가했습니다.