호스팅 및 성능
WordPress를 빠르게 만드는 방법: LiteSpeed Enterprise, LSCache 및 사이트별 Redis
가장 빠른 WordPress 요청은 결코 실행되지 않는 요청입니다. PHP나 MySQL이 호출되기도 전에 캐시에서 대부분의 방문을 처리하는 당사의 스택 작동 방식과 그것이 Core Web Vitals에 미치는 의미를 여기서 확인하세요.
실행되지 않는 요청이 가장 빠른 요청입니다
표준 WordPress 요청은 비용이 많이 듭니다. 웹 서버가 PHP에 처리를 넘기고, PHP는 WordPress를 부팅하고, 플러그인을 실행하고, MySQL에 수십 번 쿼리를 날리고, HTML을 조립한 후에야 바이트를 다시 보냅니다. 트래픽이 많은 사이트에서는 방문자마다 이 전체 과정이 반복되며, 거의 모든 시간-대-첫-바이트(time-to-first-byte)가 여기서 소모됩니다.
저희의 해답은 대부분의 방문에서 이 중 어떤 과정도 아예 일어나지 않도록 하는 것입니다. 저희가 호스팅하는 사이트들—10만 개가 넘는 PBN 사이트와 일반적인 관리형 WordPress를 포함—전체에서 프론트엔드 페이지 뷰의 대다수는 PHP를 실행하거나 데이터베이스를 건드리지 않고, 캐시에서 곧바로 사전 렌더링된 전체 페이지로 제공됩니다. 이 글의 나머지 부분은 그것을 가능하게 하는 계층들이 어떻게 서로 맞물려 있는지, 그리고 각 계층이 어떻게 그 역할을 해내는지에 대한 이야기입니다.
중요한 관점은 이것들이 둘 중 하나를 선택해야 하는 경쟁 관계의 캐시가 아니라는 점입니다. 풀페이지 캐시, 오브젝트 캐시, 그리고 CDN 엣지는 각각 서로 다른 유형의 요청을 처리하며, 진정한 가치는 이들이 어떻게 서로에게 작업을 인계하는지에 있습니다.
LiteSpeed Enterprise + LSCache: 풀페이지 레이어
모든 사이트는 서버 레벨의 LSCache가 적용된 LiteSpeed Enterprise에서 실행됩니다. 프론트엔드 응답을 캐시할 수 있는 경우, 웹 서버는 여기에 LiteSpeed 캐시 제어 및 태그 헤더를 부여하며, 다음 요청 시 LiteSpeed가 PHP 프로세스를 실행하거나 MySQL 쿼리를 발생시키지 않고 전체 페이지를 직접 제공합니다. 이는 핫 패스에서 전체 애플리케이션 부팅 과정을 제거하므로 WordPress TTFB에 가장 큰 영향을 미치는 요인입니다.
LSCache는 PHP 플러그인이 아닌 웹 서버 내부에 위치하므로 요청 수명 주기의 더 이른 단계에서 작동하며 서버가 즉시 플러시할 수 있는 형태로 페이지를 유지합니다. 캐시 크롤러가 인기 페이지를 미리 로드해 두므로, 퍼지 후 첫 번째 방문자가 페이지 재생성 비용을 부담하지 않아도 됩니다. 그 결과 캐시가 여전히 PHP 뒤에 위치하는 일반 스택에 부착된 플러그인 전용 캐시보다 훨씬 낮고 일관된 TTFB를 제공합니다.
당사 자체의 리포급 캐시 플러그인이 모든 사이트에 사전 설치 및 자동 업데이트되어 제공되며, 별도의 설정 없이도 WordPress를 LSCache에 올바르게 연동합니다. LiteSpeed가 아닌 오리진에서는 전체 페이지 헤더를 생성하지 않고 작동을 멈추는 반면, 오브젝트 캐시와 예외 규칙은 계속 작동하므로 이전된 사이트가 깨지거나 절반만 설정된 상태로 남지 않습니다.
오래된 콘텐츠를 노출하지 않으면서 속도 유지하기: ESI 및 스마트 자동 퍼지
공격적인 전체 페이지 캐싱에는 두 가지 전형적인 실패 모드가 있습니다. 로그인한 사용자에게 다른 사람의 페이지를 보여주는 것과, 변경되었어야 할 페이지를 누구에게나 보여주는 것입니다. 두 문제 모두 캐싱을 줄이는 방식이 아니라 캐싱 계층에서 해결됩니다.
ESI(Edge Side Includes)를 사용하면 실시간으로 유지되어야 하는 부분에 구멍을 뚫는 동시에 페이지를 캐시할 수 있습니다. WooCommerce 스토어에서는 카탈로그, 상품 및 카테고리 페이지가 가능한 가장 빠른 TTFB를 위해 풀페이지 캐시로 제공되며, ESI는 요청별로 장바구니 조각, 미니 장바구니 합계 및 계정 상태를 렌더링합니다. 장바구니, 체크아웃, 내 계정 및 모든 논스 또는 세션 페이지는 기본적으로 제외됩니다. 쇼핑객은 항상 자신의 장바구니와 작동하는 체크아웃을 볼 수 있으며, 모든 사용자는 여전히 캐시에서 스토어프런트를 가져옵니다.
최신성은 스마트 자동 퍼지에 의해 관리됩니다. 콘텐츠, 상품, 가격 또는 주문이 변경될 때 퍼지 후크가 자동으로 실행되므로 타이머가 아닌 즉시 관련 캐시 페이지가 새로 고쳐지며, 대시보드나 WordPress 내부에서 온디맨드 방식으로 퍼지할 수도 있습니다. 태그 기반 퍼지는 단일 게시물을 수정할 때 전체 캐시가 아닌 해당 게시물과 그 아카이브만 지우므로, 단 한 번의 수정으로 전체 사이트가 콜드 스타트되지 않습니다.
사이트별 Redis 객체 캐시: 전체 페이지가 될 수 없는 항목용
모든 요청이 정적 풀 페이지일 수는 없습니다. 로그인된 세션, WordPress 관리자 페이지, WooCommerce 장바구니, 검색, 그리고 ESI가 남기는 동적 조각들은 모두 PHP를 실행해야 합니다. 이 경우 목표는 '애플리케이션 건너뛰기'에서 '데이터베이스 건너뛰기'로 전환됩니다.
모든 사이트에는 전용 Redis 오브젝트 캐시가 제공됩니다. WordPress는 반복되는 데이터베이스 읽기 결과(옵션, 트랜시언트, 게시물 및 용어 조회, WooCommerce 제품 및 세션 데이터)를 메모리에 캐시하므로, 매 요청마다 MySQL에서 동일한 쿼리가 실행되지 않습니다. 이 효과는 전체 페이지 캐시가 도움을 줄 수 없는 부분에서 가장 뚜렷하게 나타납니다. 즉, 더 빠른 대시보드, 더 빠른 장바구니, 그리고 트래픽 발생 시 훨씬 낮아진 데이터베이스 부하를 경험할 수 있습니다.
오브젝트 캐시는 사이트별로 제공되며 공유되지 않으며, 이는 성능과 격리성 모두에 중요합니다. 사이트별 데이터베이스 스로틀링과 결합되어, 하나의 사이트에서 발생하는 과도하거나 잘못 작성된 쿼리로 인해 인접 사이트의 데이터베이스 리소스가 고갈되지 않습니다. 전체 다층 구조의 결합 방식에 대해서는 당사의 캐싱 기능 페이지에서, 테넌트 간의 격리 경계에 대해서는 관련 문서에서 자세히 확인할 수 있습니다.
엣지와 그 아래의 전송 레이어
원본 서버에 저장되는 캐시는 여전히 네트워크를 거쳐야 합니다. 서버 앞단에 CDN 엣지가 위치하므로 정적 자산과 캐시 가능한 페이지는 방문자 인근의 팝(PoP)에서 제공되며, 트래픽이 몰려도 원본 서버는 안정적으로 유지됩니다. 풋프린트 프리(Footprint-Free) 호스팅 라인의 경우, 동일한 엣지가 여러 공급업체에 분산된 멀티 CDN 풀로 구성되어 성능뿐만 아니라 검색엔진 최적화 목표도 달성하며, 일반적인 WordPress에서는 원본 서버를 유휴 상태로 유지하는 빠르고 안정적인 레이어 역할을 합니다.
기초적인 부분에서도 결코 타협하지 않습니다. 사이트는 HTTP/3가 지원되는 NVMe 스토리지에서 실행되므로, 캐시가 실제로 전송하는 바이트는 현대적인 멀티플렉싱 전송 방식을 통해 전달되며 캐시 미스가 발생하더라도 빠른 스토리지가 뒷받침합니다. 이 중 어떤 계층도 추가 기능이 아닙니다. LiteSpeed, LSCache, 사이트별 Redis, NVMe 및 HTTP/3는 상위 요금제로 유도하기 위한 옵션이 아니라 모든 플랜의 기본 사양입니다.
실제로 Core Web Vitals를 움직이는 것들
Core Web Vitals에 대해 호스팅이 과장되어 판매되는 경우가 많으므로 정확히 파악할 가치가 있습니다. TTFB는 서버가 책임지는 영역이며, 그 상단의 캐싱 스택이 이를 단축시키는 주역입니다. 엣지에서 HTTP/3를 통해 서빙되는 캐시된 풀 페이지는 TTFB가 도달할 수 있는 가장 낮은 수준에 가깝습니다. TTFB는 Largest Contentful Paint의 선두 주자이므로, 빠른 오리진은 다른 방법으로는 가질 수 없는 출발상의 우위를 모든 하위 지표에 제공합니다.
하지만 LCP, CLS, INP는 대부분 브라우저에서 페이지 자체에 의해 결정됩니다. 최적화되지 않은 히어로 이미지, 렌더링을 차단하는 CSS와 자바스크립트, 폰트와 광고가 로드될 때 레이아웃이 이동하는 현상, 플러그인으로 인한 무거운 메인 스레드 작업 등이 그것입니다. 그 어떤 서버 캐싱도 2MB짜리 히어로 이미지나 수 메가바이트의 자바스크립트를 로드하는 테마를 해결하지 못합니다. 정직한 호스팅은 서버의 기여도를 실질적으로 무료이자 일관되게 만들고, 그 이후에는 사이트의 프런트엔드를 가볍게 유지하는 것이 과제가 됩니다.
역할 분담은 유용한 정신적 모델입니다. 당사는 요청이 브라우저에 빠르게 도달하고 트래픽 속에서도 빠른 상태를 유지하도록 보장하며, 귀하는 페이로드 작고 안정적으로 유지합니다. 캐시 워밍업, 엣지 딜리버리, 동적 페이지가 정체되지 않도록 데이터베이스 응답성 유지 등 두 영역이 만나는 지점이야말로 저희 스택이 최적화된 곳이며, 이 플랫폼에서 관리형 WordPress가 일반 호스팅의 동일한 사이트보다 더 빠른 이유입니다.
자주 묻는 질문
WP Rocket과 같은 캐싱 플러그인이 여전히 필요한가요?
아니요. 전체 페이지 캐싱은 웹 서버 수준에서 LiteSpeed의 LSCache와 사전 설치 및 자동 업데이트되는 자체 캐시 플러그인을 통해 처리되며, 이를 통해 WordPress가 올바르게 연동되고 백엔드에는 사이트별 Redis 객체 캐시가 적용됩니다. 그 위에 두 번째 전체 페이지 캐싱 플러그인을 추가하는 것은 서버 수준 캐시를 돕기보다는 오히려 충돌을 일으키므로 필요하지 않으며 권장되지 않습니다.
캐싱으로 인해 WooCommerce 장바구니나 로그인된 페이지에 문제가 발생합니까?
장바구니, 결제, 내 계정 및 모든 넌스(nonce) 또는 세션 페이지는 기본적으로 캐시에서 제외되며, ESI는 캐시된 페이지에서도 장바구니 조각과 합계가 실시간으로 유지되도록 합니다. 고객은 스토어프론트가 캐시에서 로드되는 동안에도 항상 자신의 장바구니와 정상 작동하는 결제 페이지를 볼 수 있습니다.
게시하거나 수정할 때 캐시는 어떻게 최신 상태로 유지되나요?
스마트 자동 삭제 기능은 관련 WordPress 훅에서 작동하므로 콘텐츠 발행 및 수정, 또는 상품·가격·주문 변경 시 전체 캐시가 아닌 영향받는 페이지와 그 아카이브만 삭제되며 크롤러가 해당 페이지를 다시 워밍업합니다. 대시보드나 WordPress 내부에서 온디맨드로 캐시를 삭제할 수도 있습니다.
호스팅만으로 완벽한 Core Web Vitals 점수를 얻을 수 있나요?
이는 서버 측 몫이자 Largest Contentful Paint를 위한 유리한 출발점인 최상의 TTFB를 제공합니다. 그러나 LCP, CLS, INP는 이미지 크기, 렌더링 차단 리소스, 레이아웃 안정성, 메인 스레드 JavaScript 등 페이지 자체에 의해 크게 좌우됩니다. 당사의 스택은 서버의 기여도를 빠르고 일관되게 만들어 주며, 프론트엔드 페이로드의 용량을 가볍게 유지하는 것이 나머지 격차를 좁히는 방법입니다.
관련 상품
14일 동안 무료로 체험해 보세요
14일 동안 첫 사이트를 무료로 생성해 보세요. 카드 등록은 필요하지 않습니다. 기존 네트워크를 이전하시나요? 첫 번째 마이그레이션은 저희가 비용을 부담합니다.
무료로 시작하기