* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(워드프레스 해부 ㉝) 성능
워드프레스 성능은 마법 플러그인 하나가 아니라 여러 캐시 계층의 합이다. 요청이 들어와서 나갈 때까지, 각 단계에서 반복 작업을 줄이는 구조를 이해하면 최적화가 보인다.
- 페이지 캐시 — 완성된 HTML을 통째로 저장해 PHP·DB를 아예 건너뜀(가장 큰 효과).
- 오브젝트 캐시 — 반복 쿼리 결과를 메모리에(18편). Redis/Valkey로 영구화.
- 정적 자원 캐시 — CSS·JS·이미지에 브라우저 캐시 헤더(예: 1개월).
- DB·이미지 — 리비전 정리, 이미지 적정 크기.
나도 이 사이트에 이 계층을 순서대로 쌓았다 — 페이지 캐시 + 정적 자원 1개월 캐시 + Valkey 오브젝트 캐시. 그 결과 Query Monitor(32편)의 쿼리 수가 캐시 적중 시 확 줄어든다.
직접 해보기
# 캐시 켜기 전후, 같은 페이지의 쿼리 수/시간 비교
$ wp cache flush # 캐시 비우고
# (페이지 열어 Query Monitor로 쿼리 수 확인 → 첫 방문은 많음)
# (같은 페이지 새로고침 → 캐시 적중으로 쿼리 수 급감)✅ 확인 — 페이지 캐시가 동작하면, 두 번째 방문의 응답이 눈에 띄게 빨라지고 Query Monitor의 쿼리 수가 줄거나 캐시에서 나온다. “같은 걸 두 번 계산하지 않는다”가 성능 최적화의 본질이다.
실무 팁 — 속도 최적화는 계층으로 본다. ①페이지 캐시로 TTFB를 200ms 이하로, ②오브젝트 캐시(Redis/Valkey)로 반복 쿼리·autoload 옵션을 흡수, ③정적 자원·이미지 최적화로 프런트를 줄인다. 오브젝트 캐시는 적중률(hit ratio)을 보고, autoload 크기가 1MB를 넘으면 정리 대상이다.
캐시 계층을 표로 — 효과 순서
최적화는 위에서부터 손대는 게 정석이다. 효과가 크고 품은 덜 든다. 페이지 캐시 하나만 제대로 걸어도 체감이 확 달라진다.
| 계층 | 무엇을 줄이나 | 효과 |
|---|---|---|
| 페이지 캐시 | PHP·DB를 통째로 생략 | ★★★ |
| 오브젝트 캐시 | 반복되는 DB 쿼리 | ★★ |
| 브라우저·정적 캐시 | 자원 재다운로드 | ★★ |
| CDN | 서버까지의 물리적 거리 | ★★ |
측정부터 — 뭘 고칠지 모르면 못 고친다
무작정 플러그인부터 깔지 말고 먼저 잰다. Query Monitor(32편)로 느린 쿼리·훅을, PageSpeed·Lighthouse로 프런트를 본다. 요즘 기준은 Core Web Vitals(LCP·CLS·INP)다. 병목을 확인하고 거기부터 손대는 게 순서다 — 감으로 고치면 엉뚱한 데 힘 쓴다.
사실 제일 무거운 건 이미지다
대부분 페이지 용량의 큰 몫은 이미지다. 여기만 잡아도 로딩이 확 빨라진다. ① 적정 크기로 리사이즈, ② WebP·AVIF 같은 최신 포맷, ③ 지연 로딩(워드프레스가 기본 제공), ④ srcset으로 화면 크기별 이미지 제공. 이 네 가지가 LCP 개선의 핵심이다.
플러그인은 ‘개수’가 아니라 ‘무게’
‘플러그인 많으면 느리다’는 반만 맞다. 진짜 문제는 개수가 아니라 무거운 플러그인 하나다. 매 페이지에 자기 CSS/JS를 싣거나 무거운 쿼리를 돌리는 녀석이 범인이다. Query Monitor로 어느 플러그인이 시간을 먹는지 확인하고, 안 쓰는 건 삭제한다(비활성화만으론 부족할 때가 있다).
참고 — 이 블로그의 실제 구성
이 사이트는 WP Super Cache(페이지 캐시) + Valkey 오브젝트 캐시 + 정적 자원 장기 캐시 + Cloudflare(CDN) 순으로 쌓았다. 별난 최적화 플러그인 없이 이 조합만으로 충분히 빠르다. 마법 하나가 아니라, 계층을 순서대로 하나씩 얹은 결과다.
빠르게 만들었으니, 이제 안전하게 지키는 백업과 이전이다.
🔧 현장에서 — 서버가 아니라 클라이언트 풀이 문제일 때가 있다
Redis 장애가 났을 때 Redis Server Latency만 보고는 Client 쪽 Connection 부족을 못 봤다. Lettuce Command Metric과 Commons Pool Metric(active objects)을 같이 보고 나서야 병목이 보였다. 성능도 캐시 Server만이 아니라 Client Pool까지 함께 봐야 한다.
교훈 — 외부 시스템 성능은 Server Metric만큼 Client Pool Metric도 중요하다. (캐시 구조 자체는 18편)
자주 묻는 질문 (FAQ)
워드프레스 속도를 높이는 핵심은 뭔가요?
캐시 계층(페이지·오브젝트), 정적 자원 최적화, DB 정리, 좋은 호스팅입니다. 캐시가 가장 체감이 큽니다.
플러그인이 많으면 느려지나요?
수보다 ‘무거운 플러그인’이 문제입니다. Query Monitor로 어느 플러그인이 느린 쿼리를 만드는지 찾아 정리하세요.
답글 남기기