호스팅 및 성능
WordPress를 빠르게 만드는 방법: LiteSpeed Enterprise, LSCache 및 사이트별 Redis
가장 빠른 WordPress 요청은 전혀 실행되지 않는 요청입니다. PHP나 MySQL이 호출되기도 전에 당사의 스택이 대부분의 방문을 캐시에서 처리하는 방법과 이것이 Core Web Vitals에 무엇을 의미하는지 확인해 보십시오.
가장 빠른 요청은 아예 실행되지 않는 요청입니다
표준적인 WordPress 요청은 많은 리소스를 소모합니다. 웹 서버가 PHP로 전달하면, PHP는 WordPress를 구동하고, 플러그인을 실행하며, MySQL을 수십 번 쿼리하고, HTML을 조합한 후에야 비로소 바이트를 다시 전송합니다. 트래픽이 많은 사이트에서는 모든 방문자에게 이 전체 과정이 매번 발생하며, 이는 귀하의 time-to-first-byte 대부분이 소모되는 지점입니다.
저희의 해답은 대부분의 방문에서 이러한 과정이 전혀 발생하지 않도록 하는 것입니다. 저희가 호스팅하는 사이트 전반(100,000개 이상의 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는 요청마다 장바구니 조각, 미니 장바구니 합계 및 계정 상태를 렌더링합니다. 장바구니, 결제, 내 계정 및 모든 nonce 또는 세션 페이지는 기본적으로 제외됩니다. 구매자는 항상 자신의 장바구니와 정상 작동하는 결제 화면을 보게 되며, 상점 메인 화면은 모든 사용자에게 계속 캐시에서 제공됩니다.
콘텐츠의 최신 상태는 스마트 자동 퍼지(auto-purge)를 통해 관리됩니다. 콘텐츠, 제품, 가격 또는 주문이 변경되면 퍼지 훅이 자동으로 실행되므로 관련 캐시 페이지가 타이머에 의존하지 않고 즉시 새로고침되며, 대시보드나 WordPress 내부에서 필요에 따라 직접 퍼지할 수도 있습니다. 태그 기반 퍼지는 게시물 하나를 수정할 때 전체 캐시가 아닌 해당 게시물과 그 아카이브만 삭제함을 의미하므로, 한 번의 수정으로 인해 전체 사이트가 콜드 스타트(cold-start)되지 않습니다.
사이트별 Redis 객체 캐시: 전체 페이지로 캐시할 수 없는 대상을 위한 기능
모든 요청이 정적인 전체 페이지가 될 수는 없습니다. 로그인된 세션, WordPress 관리자, WooCommerce 장바구니, 검색, ESI가 실시간으로 남겨두는 동적 조각들은 모두 PHP를 실행해야 합니다. 이러한 경우 목표는 '애플리케이션 건너뛰기'에서 '데이터베이스 건너뛰기'로 전환됩니다.
각 사이트에는 전용 Redis 객체 캐시가 제공됩니다. WordPress는 옵션, 트랜Transient, 게시물 및 용어 조회, 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 및 JavaScript, 폰트와 광고가 로드되면서 흔들리는 레이아웃, 플러그인으로 인한 과도한 메인 스레드 작업 등이 그 원인입니다. 아무리 많은 서버 캐싱을 적용하더라도 2MB 크기의 히어로 이미지나 수 메가바이트의 JavaScript를 전송하는 테마를 해결할 수는 없습니다. 정직한 호스팅은 서버의 부담을 사실상 최소화하고 일관되게 유지해 주며, 그 후 프론트엔드를 가볍게 유지하는 것은 온전히 사이트의 몫입니다.
이러한 역할 분담은 유용한 멘탈 모델입니다. 저희는 요청이 브라우저에 신속하게 도달하고 트래픽이 집중되는 상황에서도 빠른 속도를 유지하도록 보장하며, 귀하는 페이로드를 작고 안정적으로 유지하시면 됩니다. 두 영역이 만나는 지점 — 캐시 웜업, 엣지 전송, 동적 페이지가 지연되지 않도록 데이터베이스의 응답성을 유지하는 것 — 은 바로 당사의 스택이 정밀하게 조정된 영역이며, 이것이 바로 이 플랫폼의 매니지드 WordPress를 일반 호스팅의 동일한 사이트보다 빠르게 만드는 핵심입니다.
자주 묻는 질문
WP Rocket과 같은 캐싱 플러그인이 여전히 필요한가요?
아닙니다. 전체 페이지 캐싱은 웹 서버 수준에서 LiteSpeed의 LSCache를 통해 처리되며, 사전 설치 및 자동 업데이트되는 당사의 전용 캐시 플러그인이 WordPress를 이에 올바르게 연결하고 사이트별 Redis 객체 캐시가 이를 뒷받침합니다. 여기에 두 번째 전체 페이지 캐싱 플러그인을 추가하는 것은 대개 도움이 되기보다 서버 수준의 캐시와 충돌을 일으키므로 필요하지 않으며 권장하지도 않습니다.
캐싱으로 인해 WooCommerce 장바구니 또는 로그인한 페이지가 손상될 수 있습니까?
아니요. 장바구니, 결제, my-account 및 모든 nonce 또는 세션 페이지는 기본적으로 캐시에서 제외되며, ESI는 캐시된 페이지에서도 장바구니 파편과 총액을 실시간으로 유지합니다. 상점 페이지가 캐시에서 로드되는 동안에도 구매자는 항상 자신의 장바구니와 정상 작동하는 결제 페이지를 볼 수 있습니다.
게시하거나 편집할 때 캐시가 어떻게 최신 상태로 유지되나요?
스마트 자동 비우기 기능은 관련 WordPress 훅에서 실행되므로, 콘텐츠를 게시 또는 수정하거나 제품, 가격, 주문을 변경할 때 전체 캐시가 아닌 영향을 받는 페이지와 해당 아카이브만 삭제되며 크롤러가 이를 다시 예열합니다. 대시보드나 WordPress 내부에서 필요에 따라 직접 비울 수도 있습니다.
호스팅만으로 완벽한 Core Web Vitals를 얻을 수 있습니까?
가능한 최상의 TTFB를 제공하며, 이는 서버의 역할이자 Largest Contentful Paint를 위한 유리한 출발점이 됩니다. 하지만 LCP, CLS 및 INP는 이미지 크기, 렌더링 차단 리소스, 레이아웃 안정성, 메인 스레드 JavaScript 등 페이지 자체에 의해 크게 좌우됩니다. 당사의 스택은 서버의 기여를 빠르고 일관되게 만들어 주며, 프론트엔드 페이로드를 가볍게 유지하는 것이 나머지 격차를 줄이는 방법입니다.
관련 항목
14일 동안 무료로 체험해 보세요
14일 동안 첫 사이트를 무료로 시작해 보세요 — 카드 등록 불필요. 기존 네트워크를 이전하시나요? 마이그레이션은 제한 없이 무료입니다.
무료로 시작하기