HTML을 만드는 서버 처리가 반복해서 느리고, 여러 방문자에게 같은 화면을 보여 줘도 된다면 페이지 캐시를 시험할 만하다. 이미 호스팅 캐시가 있거나 HTML 응답이 충분히 빠르다면 캐시 플러그인을 더할 이유부터 확인한다.
적용 대상은 비로그인 공개 글부터 고른다. 로그인·계정·장바구니·개인 일정은 공용 캐시 시험에서 제외하고, 속도뿐 아니라 글 수정과 비공개 전환이 제대로 반영되는지도 확인한다. 아래 표에서 현재 환경에 맞는 판단을 먼저 고를 수 있다.
캐시 플러그인을 설치하기 전에 볼 것
새 제품을 고르기 전에 현재 호스팅에 어떤 캐시가 있는지부터 확인한다. 관리형 호스팅이 HTML 캐시를 제공하거나 웹 서버에 이미 캐시가 설정되어 있다면, 플러그인을 하나 더 추가했을 때 관리할 사본과 삭제 경로가 늘어날 수 있다.
나는 우선 비로그인 공개 글 하나를 기준으로 다음 항목을 적어 두겠다.
| 현재 확인할 내용 | 판단 | 다음 조치 |
|---|---|---|
| 호스팅이나 웹 서버가 이미 HTML을 캐시한다 | 기존 기능으로 충분할 수 있다 | 제공 범위·제외 조건·갱신 방식을 확인하고 먼저 유지한다 |
| 페이지 캐시가 없고 서버 처리 지연이 반복된다 | 페이지 캐시 시험 후보가 된다 | 테스트 환경에서 공개 글 한 종류부터 비교한다 |
| 캐시를 써도 첫 응답 대기가 길다 | 캐시 미적중이나 다른 전달 지연일 수 있다 | 쿠키·URL·리디렉션·연결·서버 부하를 나눠 확인한다 |
| HTML은 빨리 오지만 제목이나 이미지가 늦다 | HTML 캐시만으로 해결되지 않을 수 있다 | 해당 폰트·이미지·CSS와 브라우저 작업을 조사한다 |
- 호스팅이나 웹 서버가 이미 HTML을 캐시한다
- 판단기존 기능으로 충분할 수 있다
- 다음 조치제공 범위·제외 조건·갱신 방식을 확인하고 먼저 유지한다
- 페이지 캐시가 없고 서버 처리 지연이 반복된다
- 판단페이지 캐시 시험 후보가 된다
- 다음 조치테스트 환경에서 공개 글 한 종류부터 비교한다
- 캐시를 써도 첫 응답 대기가 길다
- 판단캐시 미적중이나 다른 전달 지연일 수 있다
- 다음 조치쿠키·URL·리디렉션·연결·서버 부하를 나눠 확인한다
- HTML은 빨리 오지만 제목이나 이미지가 늦다
- 판단HTML 캐시만으로 해결되지 않을 수 있다
- 다음 조치해당 폰트·이미지·CSS와 브라우저 작업을 조사한다
TTFB에는 연결과 네트워크 시간도 포함될 수 있다. 응답 시작이 느리다는 이유만으로 PHP나 DB가 원인이라고 단정하지 않는다는 1편의 기준은 여기서도 같다. WordPress 성능 최적화 개요
같은 화면을 돌려줘도 되는 페이지부터 고른다
공개 블로그 글과 계정 페이지는 캐시 조건이 다르다. 공개 글의 본문은 여러 방문자에게 같을 수 있지만, 계정 이름·장바구니·개인 일정은 사용자마다 달라진다. 로그인 여부뿐 아니라 HTML 안에 개인별 값이 들어가는지 확인해야 한다.
| 페이지·기능 | 첫 시험에서의 판단 | 구체적으로 확인할 것 |
|---|---|---|
| 비로그인 공개 글 | 우선 시험할 후보 | 본문·메뉴·이미지와 갱신 시점 |
| 홈·카테고리 목록 | 캐시할 수 있지만 갱신 연결이 필요하다 | 새 글 발행·수정·비공개 전환 후 목록 반영 |
| 로그인·관리·계정 화면 | 공용 HTML 캐시 시험에서 제외한다 | 인증 상태와 개인 정보가 다른 방문자에게 섞이지 않는지 |
| 장바구니·결제·개인 일정 | 동작을 확인하기 전 공용 캐시에서 제외한다 | 세션·권한·실시간 값과 서비스별 권장 제외 규칙 |
| 검색 결과·URL 매개변수 | 같은 결과를 공유할 수 있는지 먼저 확인한다 | 검색어·언어·필터가 캐시 구분에 반영되는지 |
| HTML은 공통이고 JS가 개인 데이터를 요청하는 앱 | HTML과 데이터 요청을 나눠 판단한다 | API 응답의 인증·캐시 정책과 오래된 보안 토큰 포함 여부 |
- 비로그인 공개 글
- 첫 시험에서의 판단우선 시험할 후보
- 구체적으로 확인할 것본문·메뉴·이미지와 갱신 시점
- 홈·카테고리 목록
- 첫 시험에서의 판단캐시할 수 있지만 갱신 연결이 필요하다
- 구체적으로 확인할 것새 글 발행·수정·비공개 전환 후 목록 반영
- 로그인·관리·계정 화면
- 첫 시험에서의 판단공용 HTML 캐시 시험에서 제외한다
- 구체적으로 확인할 것인증 상태와 개인 정보가 다른 방문자에게 섞이지 않는지
- 장바구니·결제·개인 일정
- 첫 시험에서의 판단동작을 확인하기 전 공용 캐시에서 제외한다
- 구체적으로 확인할 것세션·권한·실시간 값과 서비스별 권장 제외 규칙
- 검색 결과·URL 매개변수
- 첫 시험에서의 판단같은 결과를 공유할 수 있는지 먼저 확인한다
- 구체적으로 확인할 것검색어·언어·필터가 캐시 구분에 반영되는지
- HTML은 공통이고 JS가 개인 데이터를 요청하는 앱
- 첫 시험에서의 판단HTML과 데이터 요청을 나눠 판단한다
- 구체적으로 확인할 것API 응답의 인증·캐시 정책과 오래된 보안 토큰 포함 여부
이 표는 첫 시험의 보수적인 출발점이다. 모든 로그인 페이지를 어떤 방식으로도 캐시할 수 없다는 뜻은 아니다. 예를 들어 FlyingPress에는 역할별 로그인 캐시 기능이 있다. 다만 같은 역할의 사용자끼리 사본을 공유하는 것만으로 개인화가 안전해지는 것은 아니므로, 일반 공개 글 시험과 분리해 검토하겠다. FlyingPress 역할별 로그인 캐시
이미 만들어 둔 HTML을 다시 쓰면 줄어드는 작업
캐시가 없는 기본 흐름에서는 WordPress가 요청을 받을 때 PHP 코드를 실행하고 데이터베이스에서 필요한 정보를 읽어 HTML을 만든다. 글 내용이 바뀌지 않았고 방문자에게 같은 화면을 보여 줘도 된다면, 이 작업을 매번 반복할 필요는 줄어든다.
페이지 캐시(page cache)는 완성된 HTML 사본을 보관해 다음 요청에 재사용한다. 서버 설정에 따라 PHP와 WordPress를 거치기 전에 파일을 제공할 수도 있고, 일부 코드를 실행한 뒤 캐시를 반환할 수도 있다. 모든 캐시가 같은 경로로 동작한다고 가정하지 말고, 사용 중인 호스팅이나 제품의 제공 방식을 확인해야 한다.
캐시가 요청에 쓸 사본을 찾으면 캐시 적중(cache hit, HIT), 찾지 못하면 캐시 미적중(cache miss, MISS)이라고 부른다.
캐시에 쓸 수 있는 HTML 사본이 있을 때: HIT
- 브라우저페이지 요청
- 캐시 처리 계층저장한 HTML 확인
응답: 저장한 HTML을 브라우저로 돌려준다. 구체적인 제공 경로는 제품·서버 설정에 따라 다르다.
사용할 사본이 없을 때: MISS
- 브라우저페이지 요청
- 캐시 처리 계층쓸 사본 없음
- WordPress·DBHTML 생성 처리
응답: 생성한 HTML을 브라우저로 전달한다. 사본의 저장·재생성 시점은 제품 정책에 따른다.
그림은 HTML 페이지 캐시의 역할을 설명한 모델이다. 이 글을 위해 운영 캐시를 끄거나 새 전후 성능 시험을 실행한 것은 아니다. 내 사이트의 기존 측정값을 CDN 없는 서버의 결과로 가져오지도 않았다.
WordPress 공식 문서도 페이지 캐시와 객체 캐시를 별도로 설명한다. 객체 캐시(object cache)는 WordPress가 사용하는 데이터 등을 재사용하는 방식이고, 페이지 캐시는 완성된 페이지를 재사용한다. 둘이 줄여 주는 작업이 달라 Redis 같은 객체 캐시가 있다는 이유만으로 HTML 페이지 캐시도 있다고 판단할 수는 없다. WordPress 캐시 설명
HIT와 MISS를 확인하되, 헤더만으로 끝내지 않는다
MISS일 때 원래 페이지를 만들어 응답한 뒤 사본을 저장하는 제품도 있고, 백그라운드에서 생성 작업을 예약하는 제품도 있다. 따라서 캐시를 비운 직후 한 번 열어 본 결과만으로 실패라고 판단하기는 어렵다.
내 사이트에서 쓰는 FlyingPress도 캐시가 없는 페이지를 방문했을 때 원본 응답을 제공하고 최적화·캐시 생성으로 이어지는 흐름을 문서로 설명한다. 파일 저장 위치와 생성 시점은 그 제품의 동작 사례이며, 다른 캐시 제품에 그대로 적용할 설정은 아니다. FlyingPress 캐시 생성과 저장 위치
제품이 제공하는 응답 헤더나 관리 화면은 사본이 사용됐는지 확인할 단서다. 다만 중간 프록시가 원본 헤더를 저장해 돌려줄 수 있고, HIT인 HTML 자체가 오래됐을 수도 있다. 화면 내용과 실제 응답을 함께 확인한다.
- 비로그인 공개 글을 열고 HTML 문서 요청의 헤더·본문과 검사 시각을 저장한다.
- 제품 문서에 따른 캐시 생성 완료 여부를 확인한 뒤 같은 조건으로 다시 요청한다.
- HIT·MISS 또는 해당 제품의 상태 표시를 기록하고, 기대한 본문이 반환됐는지 확인한다.
- 브라우저 캐시와 서버 캐시는 따로 적는다. 개발자 도구의 Disable cache가 서버 사본까지 지우는 것은 아니다.
속도와 함께 새 내용이 반영되는지도 시험한다
저장한 사본을 언제 교체하는지가 다음 문제다. 글을 고쳤는데 독자가 예전 본문을 계속 받는다면 빠른 응답만으로는 적용을 마칠 수 없다. 사본을 무효화하거나 지우는 작업을 캐시 삭제(purge)라고 한다. 미리 페이지를 생성하는 작업인 사전 생성(preload)과는 역할이 다르다.
테스트 환경에서는 합성 글을 쓰고, 기존 본문과 설정을 되돌릴 수 있게 준비한다. 다음 순서에서 어느 변경이 어떤 페이지를 갱신해야 하는지 정해 둔다.
| 시험할 변경 | 기대하는 결과 | 확인 범위 |
|---|---|---|
| 글 본문 수정 | 공개 응답에 새 문장 반영 | 해당 글의 HTML과 실제 화면 |
| 새 글 발행 | 관련 홈·카테고리 목록에 노출 | 목록의 공개 조건·정렬·제외 규칙 |
| 글을 비공개로 전환 | 비로그인 접근 차단과 목록 제거 | 해당 글·관련 목록·중간 캐시 |
| 메뉴·공통 영역 수정 | 적용 대상 페이지에 새 내용 반영 | 대표 글 여러 개와 PC·모바일 |
| 갱신 작업 실패 | 오류가 드러나고 복귀 가능 | 작업 상태·이전 설정·내용 재확인 |
- 글 본문 수정
- 기대하는 결과공개 응답에 새 문장 반영
- 확인 범위해당 글의 HTML과 실제 화면
- 새 글 발행
- 기대하는 결과관련 홈·카테고리 목록에 노출
- 확인 범위목록의 공개 조건·정렬·제외 규칙
- 글을 비공개로 전환
- 기대하는 결과비로그인 접근 차단과 목록 제거
- 확인 범위해당 글·관련 목록·중간 캐시
- 메뉴·공통 영역 수정
- 기대하는 결과적용 대상 페이지에 새 내용 반영
- 확인 범위대표 글 여러 개와 PC·모바일
- 갱신 작업 실패
- 기대하는 결과오류가 드러나고 복귀 가능
- 확인 범위작업 상태·이전 설정·내용 재확인
FlyingPress는 글 변경 시 관련 페이지를 자동으로 삭제·사전 생성하는 기능을 설명한다. 내 사이트처럼 별도 홈 목록이나 추가 캐시 계층이 있다면 그 경로까지 실제로 연결됐는지 확인해야 한다. 제품의 일반 기능 설명만으로 내 사이트의 자동 갱신이 검증됐다고 볼 수는 없다. FlyingPress 관련 페이지 자동 갱신
적용할지 결정할 때 남길 기록
캐시가 없는 응답, 캐시 생성이 끝난 응답, 내용을 바꾼 뒤의 응답을 구분해 기록한다. PC·모바일, 로그인 상태, 브라우저 캐시·서버 캐시, 회선과 측정 도구가 다른 값을 한 비교표에 섞지 않는다. 같은 조건으로 반복한 수치의 중앙값과 범위도 함께 남긴다.
내가 적용 기준으로 삼을 것은 HTML 응답 대기가 줄었는지, 본문과 기능이 정상인지, 내용 변경과 접근 권한이 제때 반영되는지다. 캐시가 적중해도 지연이 그대로라면 다른 원인을 더 조사한다. 기능이나 권한이 깨지면 시험을 멈추고 설정을 복구한다.
이번 글에는 새 전후 측정값이 없다. 위 표들은 시험 순서와 판단 기준이며, 내 사이트에서 이번에 다시 실행한 결과표가 아니다. 1편의 과거 폰트 사례도 이 페이지 캐시 시험의 성능 근거로 사용하지 않았다.
다음 편에서는 HTML 응답은 빨라졌는데도 화면이 늦는 경우를 다룬다. LCP 요소를 기준으로 이미지·폰트·CSS·JavaScript 중 어디를 먼저 손댈지 살펴보겠다.
