TTFB가 나쁨으로 나오는 워드프레스, 꼭 고쳐야 할까

새로고침을 몇 번 해도⠀

로딩 화면은 똑같은 속도로 다시 뜹니다⠀

그건 인터넷 문제가 아닐 수 있습니다⠀

PageSpeed Insights를 돌릴 때마다⠀

초기 서버 응답 시간 단축이라는 항목이⠀

자꾸 걸리는 분들이 있습니다⠀

TTFB가 나쁨으로 뜬다고⠀

바로 손봐야 하는 건지 짚어 보겠습니다⠀

⠀⠀⠀

새로고침해도 그대로인 이유가 있다⠀

⠀⠀⠀

캐시가 없는 워드프레스는 화면을 미리 저장해 두지 않습니다⠀

요청이 들어올 때마다 PHP가 다시 움직이고⠀

MySQL을 거쳐 페이지를 새로 만듭니다⠀

그래서 새로고침을 반복해도⠀

응답이 시작되는 속도 자체는 달라지지 않습니다⠀

브라우저 캐시를 지워도 마찬가지입니다⠀

이 지점을 짚어 주는 항목이⠀

PageSpeed Insights의 초기 서버 응답 시간 단축입니다⠀

서버가 첫 바이트를 보내기까지 걸린 시간을 보여줍니다⠀

⠀⠀⠀

0.8초와 1.8초, 이 두 숫자가 기준이다⠀

⠀⠀⠀

web.dev는 TTFB를 세 구간으로 나눕니다⠀

0.8초 이하면 좋음이고⠀

0.8초에서 1.8초 사이면 개선 필요입니다⠀

1.8초를 넘으면 나쁨으로 분류됩니다⠀

화면에 뜬 숫자가 이 세 구간 중 어디에 있는지⠀

바로 대 보면 됩니다⠀

숫자 하나만 보고 끝내지 말고⠀

이 구간 표시를 그대로 옮겨 적어 두는 게 낫습니다⠀

다음에 다시 측정했을 때 비교할 기준이 됩니다⠀

⠀⠀⠀

나쁨이 뜬다고 다 고쳐야 하는 건 아니다⠀

⠀⠀⠀

TTFB는 Core Web Vitals 지표가 아닙니다⠀

LCP나 CLS처럼 순위나 평가에 직접 들어가는 지표와는 다릅니다⠀

그래서 TTFB가 나쁨으로 나와도⠀

LCP 같은 핵심 지표에 지장이 없다면⠀

좋음 기준을 반드시 맞춰야 하는 건 아닙니다⠀

개인적으로는 LCP가 초록으로 뜨는데도⠀

TTFB 하나 때문에 캐시 플러그인을 새로 깔거나⠀

호스팅을 바꾸는 건 순서가 앞서갔다고 봅니다⠀

⠀⠀⠀

숫자를 적어 둘 때 함께 볼 것이 있다⠀

⠀⠀⠀

TTFB를 측정할 때는 숫자만 적지 않습니다⠀

0.8초와 1.8초 기준선에 대 보고⠀

좋음인지 개선 필요인지 나쁨인지 구간까지 함께 적습니다⠀

그 옆에 LCP 상태도 같이 적어 둡니다⠀

TTFB만 따로 보면 어느 쪽이 실제로 문제인지 놓치기 쉽습니다⠀

이렇게 두 값을 같은 표에 적어 두면⠀

다음 점검에서 어느 쪽이 움직였는지 바로 비교할 수 있습니다⠀

⠀⠀⠀

호스팅, 플러그인, DB, 캐시 중 어디를 먼저 열까⠀

⠀⠀⠀

캐시가 없으면 PHP와 MySQL 처리가 매 요청마다 반복됩니다⠀

그래서 호스팅, 플러그인, DB, 캐시 중⠀

어디가 병목인지 나눠서 봐야 합니다⠀

공유 호스팅은 여러 사이트가 자원을 나눠 쓰는 구조라⠀

서버 위치나 사양에 따라 응답이 갈립니다⠀

플러그인 목록에서는 외부 API를 부르는 것들을 눈여겨봅니다⠀

리비전이나 스팸 댓글로 데이터베이스가 비대해진 경우⠀

autoload 데이터가 과도하게 쌓인 경우도 원인으로 꼽힙니다⠀

지속형 오브젝트 캐시는 이런 DB 쿼리를 줄이는 수단으로 쓰입니다⠀

백업이나 크론 작업이 겹치는 시간대도 영향을 줄 수 있습니다⠀

한꺼번에 여러 곳을 손대면⠀

무엇 때문에 값이 바뀌었는지 알 수 없습니다⠀

플러그인 하나를 꺼 두고 다시 측정할 때는⠀

백업해 둔 뒤 진행하는 편이 안전합니다⠀

그 상태에서 TTFB 값을 다시 적어 앞의 기록과 대 봅니다⠀