워드프레스에 캐시 플러그인이 설치돼 있으면 캐시도 잘 돌아가고 있을 거라고 생각하기 쉽다. 나도 LiteSpeed Cache가 활성화돼 있었기 때문에 일단 그 부분은 갖춰진 줄 알았다. 그런데 관리자 진단에서는 페이지 캐시가 감지되지 않고 서버 반응이 느리다는 경고가 나왔다.
설정을 더 세게 켜는 문제가 아니었다. 내 서버에서 그 페이지 캐시 기능을 쓸 수 있는지를 먼저 봐야 했다. 2026년 11월 9일 점검 당시 구성은 HestiaCP의 Nginx와 Apache, PHP-FPM이었다.
설정 화면에 이미 답이 적혀 있었다
LiteSpeed Cache의 캐시 설정 화면에는 현재 LSCache 캐싱 기능을 사용할 수 없다는 경고가 있었다. 페이지 캐시를 쓰려면 LiteSpeed 계열 서버나 QUIC.cloud CDN이 필요하다는 내용이었다. 플러그인 안의 켜기 스위치만 보고 지나치면 놓치기 쉬운 부분이다.
공식 FAQ는 기능을 둘로 나눠 설명한다. 페이지 캐시는 서버 쪽 엔진이 실제 일을 하고 플러그인은 그 엔진과 소통한다. 반면 CSS·JS 정리, 이미지 관련 기능 등은 페이지 캐시와 조건이 다르다. 따라서 LiteSpeed가 아닌 서버에서는 플러그인의 모든 기능이 쓸모없다는 뜻도 아니다.
내 사이트에서는 페이지 캐시를 한 가지로 정리했다
기존 LiteSpeed 설정을 먼저 백업했다. 플러그인을 삭제하거나 최적화된 이미지를 지우지는 않고 비활성 상태로 남겨뒀다. 그런 다음 무료 WP Super Cache를 설치해 단순 모드로 페이지 캐시를 구성했다.
다른 서버에서도 이 조합이 무조건 정답이라는 이야기는 아니다. 이미 호스팅 캐시나 Nginx 캐시가 잘 작동한다면 또 하나를 얹기보다 기존 캐시부터 확인해야 한다. 내 경우에는 작동하지 않던 페이지 캐시를 정리하고 한 가지 방식으로 확인하는 쪽을 택했다.
단순 모드를 고른 이유
WP Super Cache의 단순 모드는 만들어둔 정적 HTML 파일을 PHP를 통해 제공한다. 이 플러그인의 권장 방식이고, 전문가 모드처럼 캐시용 rewrite 규칙을 직접 수정할 필요가 없다. 다만 일반적인 고유주소 설정 등 플러그인의 동작 조건은 확인해야 한다.
캐시 만료는 1,800초, 오래된 파일 확인 간격은 600초로 시작했다. 글이나 페이지가 바뀌면 캐시가 지워지도록 설정했고, 처음부터 모든 글을 사전 생성하는 기능은 켜지 않았다. 방문자가 읽는 공개 페이지부터 작동 여부를 확인했다.
관리자와 검색 화면은 같은 방식으로 다루지 않았다
- 로그인한 방문자는 캐시에서 제외했다.
- 검색 페이지와 GET 매개변수가 있는 요청은 제외했다.
- 워드프레스 관리자·로그인·API 관련 경로를 제외 목록에 넣었다.
- 일반적인 미리보기처럼 쿼리 매개변수가 붙는 요청도 캐시하지 않도록 했다.
- 기존 캐시를 비운 뒤 익명 방문과 로그인 방문을 각각 확인했다.
공개 글을 빠르게 보여주는 것과 개인별 화면을 섞지 않는 것은 함께 봐야 한다. 쇼핑몰의 장바구니·결제·회원 전용 페이지가 있는 사이트라면 추가 제외와 검증이 필요하다. 내 블로그에서 통과한 설정을 다른 사이트에 그대로 복사하라는 뜻은 아니다.
속도는 무엇을 잰 값인지부터 적었다
측정은 같은 브라우저에서 로그인 쿠키를 보내지 않고 홈페이지 HTML을 받아오는 방식으로 했다. 적용 전 세 번의 기록은 1,350ms, 940ms, 890ms였다. 평균은 1,060ms다. 캐시 적용 뒤 첫 요청은 1,198ms였고, 그다음 세 번은 276ms, 247ms, 245ms로 평균 256ms였다.
첫 요청과 캐시가 생긴 뒤의 요청을 나눠 적는 이유가 있다. 캐시 파일을 처음 만드는 비용까지 사라지는 것은 아니기 때문이다. 또 이 숫자는 이미지·광고·글꼴이 모두 뜰 때까지의 시간이 아니다. 사이트 전체가 네 배 빨라졌다거나 모든 방문자에게 같은 결과가 나온다고 말할 수는 없다.
측정값은 그날 작업 중의 기록이다. 이후 방문자에게 노출되던 별도 Worker 스크립트도 차단했으므로, 현재의 전체 로딩 상태는 다시 측정해야 한다. 캐시 자체의 동작은 플러그인 테스트에서 두 응답의 생성 시각이 같은지, 익명 HTML에 캐시 표시가 있는지로 함께 확인했다.
남은 과제까지 끝난 척하지 않기
페이지 캐시 문제를 정리한 뒤 워드프레스 사이트 건강 판정은 양호로 바뀌었다. 그래도 오래된 PHP 버전과 영구 객체 캐시에 관한 권장 사항은 남았다. 페이지 캐시 하나로 서버 업데이트나 데이터베이스 문제까지 모두 해결한 것은 아니다.
내가 다시 같은 상황을 만난다면 플러그인 개수부터 늘리지 않을 것 같다. 서버 종류, 캐시 경고, 익명 요청의 실제 응답을 차례로 확인하면 된다. 설치돼 있다는 사실보다 중요한 것은 지금 내 사이트에서 제대로 작동하고 있느냐였다.
