홈 › WordPress는 왜 이렇게 느릴까 — 그리고 실제로 어떻게 해결할까

문제점

WordPress는 왜 이렇게 느릴까 — 그리고 실제로 어떻게 해결할까

캐싱 플러그인을 설치했습니다. “빠르다”는 호스팅도 결제했습니다. 그런데도 PageSpeed 점수는 좀처럼 오르지 않습니다. 여기서는 WordPress가 왜 느린지를 아키텍처 관점에서 짚어보고, 실제로 해결되는 단 하나의 방법을 알려드립니다.

근본 원인: 페이지가 매번 방문 때마다 생성된다

캐싱 플러그인이 숨겨주는 핵심 사실이 있습니다. WordPress 페이지는 누군가 요청하기 전까지 존재하지 않습니다. 방문이 들어올 때마다 PHP가 MySQL 데이터베이스를 조회하고, 테마를 불러오고, 활성화된 모든 플러그인을 실행한 뒤 HTML을 조립해서 그 다음에야 전송합니다. 이 작업에는 시간이 걸리고, 방문할 때마다 반복됩니다. 플러그인이 많고 데이터베이스가 클수록 속도는 더 느려집니다.

• 모든 요청마다 발생하는 데이터베이스 왕복
• 플러그인 오버헤드 — 20~40개의 플러그인이 각각 쿼리, CSS, JS를 추가
• 렌더링을 막는 자산이 테마와 빌더에 의해 계속 쌓임
• 무거운 페이지 빌더(Elementor, Divi)가 많은 마크업을 함께 전송

캐싱 플러그인이 임시방편에 그치는 이유

캐싱은 미리 만들어 둔 페이지 복사본을 저장해 WordPress가 다시 조립하지 않도록 해줍니다. 하지만 그건 경우에 따라 다릅니다. 캐시는 만료되고, 로그인한 사용자 화면과 동적 페이지에서는 동작하지 않으며, 다른 플러그인과 충돌하는 일도 잦습니다. 결국 느린 기반 위에 불안정한 속도 계층을 덧붙여 관리하게 됩니다. 이는 근본 해결책이 아니라 임시방편이고, 그 결과는 Google이 랭킹 신호로 사용하는 Core Web Vitals에도 그대로 드러납니다. 페이지가 느릴수록 순위는 낮아지고 전환율도 떨어집니다.

실제로 통하는 해결책: 정적으로 전환하기

방문할 때마다 페이지를 생성하는 것이 문제라면, 해결책은 방문할 때마다 생성하지 않는 것입니다. 정적 사이트(예: Hugo)는 모든 페이지를 미리 빌드한 뒤 CDN에서 일반 HTML로 제공합니다. 데이터베이스도 없고, PHP도 없고, 요청 시점에 실행되는 플러그인도 없습니다. 이것이 밀리초와 초 단위의 차이를 만드는 이유이며, 정적 사이트가 PageSpeed에서 90~100점을 꾸준히 받는 반면 WordPress는 40~70점대에 머무는 이유이기도 합니다.

이건 사실상 “최후의 수단”이지만, 다른 방법으로는 속도를 해결할 수 없는 사이트라면 가장 올바른 선택입니다. 순위를 잃지 않고 WordPress를 벗어나는 방법도 확인해 보세요.

자주 묻는 질문

왜 wordpress는 느릴까wordpress 느림wordpress 속도 높이기wordpress 성능