워드프레스 캐시 플러그인 베스트 조합 3종 세트

워드프레스는 사이트를 가볍게 하고 압축하여 속도를 올려주는 캐시플러그인 3종 세트가 있다.

Asset CleanUp 플러그인은 내게 불필요한 JS, CSS & HTML 코드들을 정리하고 들어내는 역할을 한다면, Autoptimize 플러그인은 내 사이트의 지저분한 CSS/JS를 합치고 압축해 놓는다.

2개 플러그인의 설정법은 아래 글 참고.

WP Super Cache 플러그인은 Asset CleanUp 플러그인과 Autoptimize 플러그인이 작업해 놓은 결과물을 ‘정적 파일’로 저장해 둔다.

그러면 내 사이트를 방문한 사람은 서버를 뒤질 필요 없이 WP Super Cache 플러그인이 전송해주는 정적 파일을 아주 빠르게 받아 볼 수 있다.

WP Super Cache 플러그인 설정 방법

WP Super Cache 플러그인 설정 화면
WP Super Cache 플러그인 설정 화면

캐시 고급 설정 방법

플러그인을 추가하고 활성화하여 설정 화면, “고급” 카테고리로 들어간다.(그냥 “단순” 카테고리에서 “캐싱 켜기”만 해도 된다. 플러그인 측에서는 이 걸 권장하기도 한다)

캐싱 활성화를 제일 체크하고 전문가를 체크한다(단순을 권장하고 있으나 전문가 모드를 선택하면 속도가 조금 더 빨라진다)

로그인한 방문자에 대한 캐싱을 비활성화를 체크한다. 로그인한 방문자는 관리자를 말한다. 관리자가 수정된 화면을 확인해야 하기 때문에 캐싱하면 귀찮아 진다.

“페이지를 압축하여 방문자에게 더 빠르게 제공하세요.”와 “캐시 재구축. 새 파일이 생성되는 동안 익명 사용자에게 Super Cache 파일을 제공하세요.”도 체크해준다.

WP Super Cache 플러그인에서 “304 브라우저 캐싱. 브라우저가 마지막으로 요청한 이후 페이지가 변경되었는지 확인하여 사이트 성능을 향상시킵니다.” 이게 속도를 높여주는 핵심 기능인데, 전문가 모드를 선택하면 브라우저 캐싱은 디폴트로 설정된다.

“추가 홈페이지 확인.” 체크해 둔다. 새 글을 발행하고 나서 블로그 홈페이지가 바로바로 업데이트가 되도록 해준다.

그 아래에 있는 “상태 업데이트” 버튼을 클릭하면 위에서 설정한 내용들이 저장된다.

더 아래에 있는 “Mod Rewrite 규칙 업데이트” 버튼을 눌러주면 .htaccess 파일이 자동으로 수정되며 전문가 모드가 활성화된다.

그리고 만료 시간 및 쓰레기 수집은 블로그라면 캐시 시간 초과는 3600초, 스케줄러는 하루 한 번이 권장된다.

나는 일주일에 글 한 개 정도 올릴 예정이라 캐시 시간 초과는 604800초(일주일), 스케줄러는 하루 한 번으로 설정했다.

그리고 “만료 변경” 버튼을 눌러주면 설정 사항들이 저장된다.

허용되는 파일 이름 & 거부된 URI 목록은 캐시 파일의 증가를 막기 위해 피드 (is_feed), 검색 페이지 (is_search), 개발자 페이지 (is_author)를 체크했다.

거부된 URL 문자열에는 /page/을 추가하여 /page/2, /page/3 등의 목록은 캐시 파일에서 제외되도록 했다.

그 외에는 손 댈 필요가 없었다.

캐시 사전 로드 설정 방법

그리고 “사전 로드” 카테고리로 이동하여 방문자(봇 포함)에게 제공할 캐시 파일을 사전 로드하는 설정을 한다.

캐싱은 최신 글부터 가장 오래된 글 순으로 이루어지므로 글이 많은 경우(10,000개 이상), 서버 부담을 줄이기 위해 최신 글만 캐싱하는 것을 고려해야 한다.

나는 게시 글이 모두 930개라 모든 글을 사전 로드해도 될 것 같았다.

“사전 로드 모드 (쓰레기 수집 비활성화됨. 권장됨)” 항목을 체크하고 “0”분마다 사전 로드된 캐시 파일을 새로 고침 하세요. 체크했다. 0분은 한 번 올리고 나면 다시 올리지 않겠다는 뜻이다.

설정 저장을 하고, “지금 캐시를 사전 로드하기”를 클릭했더니, 930개를 사전 로드하는데 장장 24시간이 넘어갔다. 어? 이거 쉽게 할 게 아닌데, 라는 생각이 엄습했다.

시간이 지날 수록 캐시 파일 숫자가 늘어나더니 2일째 되는 날에는 캐시 파일이 1131개가 되었다.

정확히는 1082개(글 932+카테고리12+태크136+페이지1+홈페이지1)가 되어야 했는데 말이다.

그래서 위에서 말한 거부된 URL 문자열에는 /page/을 추가했다. 그러면 아카이브에 있는 /page/2, /page/3 등의 목록은 캐시 파일에서 제외됐다.

사전 로드를 두 번째 하니까 1시간 30분 정도 걸렸다. 사전 로드를 할수록 시간을 점점 단축되는 것 같았다.

몇 번 했더니 마지막에는 34분만에 완료되었다.(Last preload finished: 2026. 3. 6. 오전 2:18:29)

캐싱을 하는 중이나 캐싱 완료 후에 컨텐츠 카테고리에서 캐싱 현황을 확인할 수 있다.

사전 로드를 완료하고 나면 방문자가 방문했을 때 캐시 파일이 따로 생성하지 않으므로 사이트의 속도가 더 빨라질 수 있는 이점도 있다.

사이트가 빠르면 SEO 점수는 물론, 사용자 경험에도 긍정적인 영향을 미치게 된다.

캐시 적용 확인 방법

게시글에 캐싱 파일이 생성되었는지 확인하려면, 새 시크릿 창에서 게시글을 열고 마우스 우클릭–> 페이지 소스보기를 하여 제일 마지막 행에 아래와 같이 메시지가 표시되면 캐싱이 완료된 것이다.

<!-- Dynamic page generated in 0.247 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2026-03-06 01:44:47 -->

<!-- Compression = gzip -->

“page generated in 0.0247 seconds.”은 페이지 생성 속도를 말하고, “on 2026-03-06 01:44:47” 캐싱 파일이 생성된 시간, gzip은 웹 서버와 브라우저 간의 빠른 전송을 위해 텍스트, 스크립트, CSS 등이 압축되었다는 의미이다.

게시된 글을 수정하고 나면 WP-Super-Cache on의 날짜도 글 수정 날짜로 바로 반영된다.


댓글