블루호스트 VPS cPanel WHM 속도 최적화 워드프레스 객체 캐시부터 PHP FPM
블루호스트 VPS cPanel과 WHM까지 같이 손보면 체감이 달라지는 이유
웹사이트 속도는 단순히 이미지 몇 장 줄인다고 끝나지 않습니다. 특히 워드프레스를 운영하면서 방문자 수가 늘거나 글 수가 쌓이기 시작하면, 캐시를 어떻게 잡는지, PHP를 어떻게 돌리는지, 압축과 프록시를 어떻게 쓰는지에 따라 첫 화면 로딩과 관리자 반응 속도 차이가 꽤 크게 벌어집니다.
그래서 블루호스트 VPS처럼 cPanel과 WHM까지 같이 만질 수 있는 환경은 생각보다 손볼 수 있는 범위가 넓습니다
. 일반적인 블로그 서비스에서는 손댈 수 없는 서버 단 설정까지 건드릴 수 있기 때문인데요. 제대로 잡으면 첫 페이지 응답, 관리자 속도, DB 쿼리 처리, 로그인과 주문 처리 반응까지 같이 좋아지는 경우가 많습니다.
이 글은 단순히 캐시 플러그인 하나 추천하고 끝내는 식이 아니라, 블루호스트 VPS 접속, WHM에서 먼저 볼 메뉴, cPanel에서 바로 적용 가능한 압축과 버전 설정, 워드프레스 페이지 캐시, 오브젝트 캐시, PHP-FPM, Redis·Valkey, NGINX 리버스 프록시, 코어 웹 바이탈 기준까지 길게 정리한 버전입니다.
먼저 알아둘 것
이 글에서 설명하는 WHM, cPanel, PHP-FPM, Redis, Valkey, NGINX reverse proxy 같은 설정은 블루호스트 VPS처럼 서버 접근 권한이 있는 환경을 기준으로 합니다. 반대로 서버 루트 영역을 직접 만질 수 없는 환경에서는 적용 범위가 훨씬 좁아집니다.
- [IT 리뷰/블로그 SEO] - 블루호스트 VPS 워드프레스 TTFB 줄이기(OPcache + Redis Object Cache 설치)
- [IT 리뷰/블로그 SEO] - WHM(EasyApache 4) PHP 8.4 OPcache + Redis Object Cache 구성 장애 복구후기
- [IT 리뷰/블로그 SEO] - 워드프레스 느린 이유 서버 사양 충분한데도 PHP-FPM ondemand 설정이 문제일 수 있는 이유
그래서 같은 워드프레스라도 공유호스팅과 VPS는 손볼 수 있는 범위가 꽤 다릅니다.
블루호스트 VPS에서 가장 먼저 확인할 접속 구조
블루호스트 VPS를 처음 쓰는 분들이 가장 많이 헷갈리는 부분이 접속 경로입니다.
관리자 화면이 하나만 있는 게 아니라, 블루호스트 포털, WHM, 개별 cPanel, SSH가 나뉘어 있기 때문입니다.
| 접속 위치 | 주로 하는 일 | 누가 만지는지 |
|---|---|---|
| 블루호스트 포털 | 서버 진입, WHM 버튼 접근, 청구·플랜 관리 | 계정 소유자 |
| WHM | 서버 전체 설정, PHP 버전, 계정 생성, 보안, 서비스 관리 | 서버 관리자 |
| cPanel | 도메인별 파일, DB, 압축, PHP 버전, 이메일, 백업 | 사이트 운영자 |
| SSH | WP-CLI, 서버 점검, 패키지 확인, 캐시 재시작 | 고급 사용자 |
실제로는 블루호스트 포털에서 WHM 버튼으로 들어가고, WHM 안에서 다시 개별 cPanel 계정을 관리하는 구조로 이해하면 편합니다.
WHM에서 가장 먼저 손볼 메뉴
저는 VPS를 처음 세팅하면 WHM에서 아래 순서부터 보는 편입니다. 무작정 캐시 플러그인부터 넣기보다, 서버가 PHP를 어떻게 처리하는지, 압축과 프록시가 어떻게 잡혀 있는지, 오브젝트 캐시를 넣을 수 있는 상태인지부터 보는 편이 훨씬 안정적이었습니다.
WHM MultiPHP Manager
이 메뉴는 사실상 서버 속도와 호환성을 같이 잡는 핵심 메뉴입니다.
PHP 버전을 너무 낮게 두면 워드프레스와 플러그인 호환성도 떨어지고, 속도도 손해를 보기 쉽습니다. 반대로 최신 버전으로만 밀어붙이면 테마나 플러그인이 안 맞는 경우도 있어서, 실제 운영 사이트는 지원 끝난 버전이 아닌 안정적인 최신대 버전으로 맞추는 편이 좋습니다.
여기서 같이 보는 항목이 PHP-FPM입니다.
PHP-FPM을 켜두면 PHP 요청을 더 효율적으로 처리할 수 있어서, 관리자 반응과 동적 페이지 처리에서 차이가 나는 경우가 많습니다. 특히 글쓰기 화면, 주문 처리, 로그인, 검색, 폼 전송처럼 캐시가 완전히 먹지 않는 구간에서 체감이 납니다.
PHP-FPM 풀 설정과 php.ini 조정
WHM에서 PHP-FPM이 켜져 있더라도, 풀 설정과 PHP 제한값이 너무 보수적으로 잡혀 있으면 사이트가 답답할 수 있습니다. 보통은 아래 항목을 같이 봅니다.
- memory_limit
- max_execution_time
- max_input_vars
- upload_max_filesize
- post_max_size
- pm.max_children 같은 풀 관련 값
워드프레스 관리자에서 이미지 업로드가 자주 막히거나, 편집기 저장이 느리거나, 플러그인 설치 중 타임아웃이 나는 사이트는 이 구간을 같이 보는 편이 좋습니다. 단, 무조건 숫자만 크게 잡는다고 좋은 건 아닙니다. 서버 메모리가 작은데 풀 워커만 과하게 늘리면 오히려 전체가 무거워질 수 있습니다.
EasyApache 4
WHM에서 서버 웹스택을 만질 때 가장 자주 보게 되는 메뉴가 EasyApache 4입니다.
여기서 PHP 버전 추가, 필요한 확장 설치, Apache 모듈 조정, NGINX reverse proxy, Redis·Valkey 컨테이너 같은 것들을 연결해서 보게 됩니다.
워드프레스 기준으로는 최소한 아래 항목을 체크하는 편이 좋습니다.
- 필요한 PHP 버전이 설치되어 있는지
- OPcache가 정상적으로 활성화되어 있는지
- mod_deflate 또는 Brotli 계열 압축 사용 여부
- 이미지 처리용 imagick, gd 같은 확장이 필요한지
- NGINX reverse proxy를 붙일지
워드프레스 사이트가 많고 트래픽이 늘고 있다면 이 메뉴는 한 번 보고 끝나는 곳이 아니라, 운영 중에도 종종 다시 보는 메뉴라고 생각하면 됩니다.
NGINX Reverse Proxy
정적 파일 응답과 캐시 처리까지 같이 챙기고 싶다면 NGINX reverse proxy를 붙이는 구성이 꽤 괜찮습니다. 특히 이미지, CSS, JS 요청이 많은 사이트는 정적 리소스를 더 가볍게 내보내는 데 도움이 됩니다. 워드프레스처럼 동적 PHP와 정적 파일이 섞여 있는 사이트에서 체감이 나는 편입니다.
다만 이미 LiteSpeed 계열을 쓰고 있거나, 캐시 구조가 복잡하게 꼬여 있다면 무조건 추가하는 게 답은 아닙니다. 지금 쓰는 웹서버 구조를 먼저 확인하고 들어가는 편이 좋습니다.
LiteSpeed를 붙일지 말지
cPanel/WHM 서버는 LiteSpeed도 많이 씁니다. 장점은 Apache 설정과 .htaccess 호환성이 좋아서 운영 중인 사이트를 크게 뜯지 않고 옮기기 좋다는 점입니다. 또 LSCache 계열을 잘 쓰면 워드프레스 속도를 상당히 쉽게 끌어올릴 수 있습니다.
하지만 LiteSpeed가 활성화되어 있으면 MultiPHP Manager 쪽 PHP 핸들러 편집이 제한되는 구간도 있기 때문에, PHP-FPM과 lsphp 중 어떤 구조로 갈지 먼저 정해야 합니다. 그냥 유행처럼 하나 더 얹기보다 서버 구조를 단순하게 가져가는 편이 관리하기는 더 편합니다.
cPanel에서 바로 손볼 수 있는 속도 메뉴
WHM이 서버 전체를 보는 메뉴라면, cPanel은 실제 사이트 단위에서 바로 적용하기 좋은 메뉴가 많습니다. 사이트 하나만 빠르게 손보고 싶을 때는 오히려 cPanel 쪽이 더 편할 때도 있습니다.
Optimize Website 압축 설정
cPanel의 Optimize Website 메뉴는 생각보다 기본인데도 효과가 괜찮습니다. HTML, CSS, JavaScript, 텍스트 응답을 압축해 전송량을 줄여주기 때문에, 첫 방문 로딩과 모바일 응답을 가볍게 만드는 데 도움이 됩니다.
이 메뉴는 Apache의 mod_deflate가 켜져 있어야 보이므로, 보이지 않는다면 WHM의 EasyApache 4 쪽에서 모듈 상태를 먼저 보는 편이 맞습니다. 최근 서버는 Brotli를 같이 쓰는 경우도 있어서, 지원 환경이면 압축률이 더 좋아질 수 있습니다.
MultiPHP Manager for cPanel
도메인 단위로 PHP 버전을 나눠서 잡아야 할 때는 cPanel의 MultiPHP Manager가 편합니다.
테스트 도메인과 실서비스 도메인을 다른 PHP 버전으로 돌리고 싶을 때, 굳이 서버 전체를 흔들지 않고 도메인 단위로 맞출 수 있습니다.
플러그인 몇 개가 오래돼서 최신 PHP에서 깨질 때, 바로 전체 서버를 낮추기보다 개별 도메인만 잠깐 조정하는 식으로 대응할 수 있어 운영이 훨씬 편합니다.
파일, 이미지, 백업 구조 정리
속도 문제는 서버 설정만으로 끝나지 않습니다. 오래된 워드프레스 사이트는 업로드 폴더에 안 쓰는 이미지가 수만 장 쌓여 있고, 백업 파일이 public_html 안에 그대로 남아 있거나, 웹에서 접근 가능한 경로에 캐시 파일이 과하게 쌓여 있는 경우도 많습니다.
이런 사이트는 캐시 플러그인 하나보다 파일 구조 정리, 백업 파일 외부 이동, 오래된 로그와 임시 파일 정리가 먼저인 경우도 많습니다. 실제로 디스크 I/O가 답답한 VPS는 이런 정리만 해도 관리자 반응이 좋아지는 경우가 있습니다.
워드프레스에서 반드시 나눠서 봐야 하는 캐시 4종류
워드프레스 속도는 캐시 하나로 설명이 안 됩니다. 저는 최소한 아래 네 가지를 분리해서 보는 편입니다.
| 캐시 종류 | 역할 | 대표 예시 |
|---|---|---|
| 페이지 캐시 | 완성된 HTML을 빠르게 재사용 | WP Super Cache, Cache Enabler, 서버 페이지 캐시 |
| 오브젝트 캐시 | DB 쿼리 결과와 객체 재사용 | Redis Object Cache, Valkey |
| 브라우저 캐시 | 정적 파일 재방문 속도 개선 | Cache-Control, Expires |
| 서버 캐시 | 리버스 프록시, 웹서버 단 캐시 | NGINX caching, LiteSpeed cache |
이걸 섞어서 생각하면 세팅이 꼬입니다. 예를 들어 페이지 캐시만 잘 걸어도 첫 화면은 빨라질 수 있지만, 관리자나 비로그인 상태가 아닌 화면, 검색, 필터링, 장바구니, 회원 기능 같은 동적 구간은 오브젝트 캐시와 PHP 처리 구조가 더 중요할 수 있습니다.
오브젝트 캐시는 언제 넣는 게 맞는지
워드프레스 운영자들이 가장 많이 헷갈리는 부분이 여기입니다.
오브젝트 캐시는 무조건 넣으면 좋아지는 만능 스위치가 아닙니다. 하지만 DB 호출이 많고, 플러그인이 많고, 게시글이나 상품 수가 많고, 관리자 화면이 무겁고, 로그인 사용자 기능이 많을수록 효과가 나는 경우가 많습니다.
반대로 글 몇 개 없는 가벼운 블로그에 무리해서 넣으면 체감 차이가 작거나, 메모리만 더 먹고 관리 포인트만 늘어날 수도 있습니다. 그래서 저는 아래 기준으로 판단합니다.
- 페이지 캐시만으로 부족한가
- 로그인 사용자 비중이 높은가
- DB 읽기 요청이 많은가
- 관리자 화면 반응이 유난히 느린가
- WooCommerce, 멤버십, 검색, 필터링이 많은가
Redis Object Cache
워드프레스에서 가장 많이 쓰는 오브젝트 캐시 중 하나가 Redis Object Cache입니다. 설치가 비교적 편하고, 워드프레스 오브젝트 캐시 API와 맞춰 쓰기 좋습니다. WooCommerce, Jetpack, Yoast SEO 같은 플러그인과의 최적화 항목도 공식 플러그인 설명에 나와 있습니다.
다만 운영 중에는 Redis 자체 메모리 사용량, 캐시 히트율, 키 수, 캐시 폭주를 같이 보는 편이 좋습니다. 무조건 연결만 해두고 끝내면 오히려 메모리만 늘고 체감이 안 나는 경우도 있습니다.
Redis 대신 Valkey를 볼 수 있는 상황
최근에는 Valkey를 같이 보는 경우도 늘었습니다. cPanel/EasyApache 4 컨테이너 문서에도 Valkey 구성이 별도로 정리돼 있어서, 운영 환경과 지원 패키지에 따라 Redis 대신 Valkey를 선택하는 경우도 있습니다. 다만 워드프레스 플러그인 호환성과 실제 운영 편의성까지 같이 보고 결정하는 편이 좋습니다.
워드프레스 페이지 캐시와 오브젝트 캐시는 같이 써야 더 낫다
페이지 캐시는 첫 화면과 비로그인 방문자를 빠르게 만드는 데 유리하고, 오브젝트 캐시는 DB 호출과 내부 객체 재사용에 유리합니다. 이 둘은 경쟁 관계가 아니라 역할이 다릅니다.
예를 들어 뉴스형 블로그나 정보성 사이트는 페이지 캐시 비중이 더 크고, 쇼핑몰이나 회원 기능이 많은 사이트는 오브젝트 캐시 체감이 더 클 수 있습니다. 결국 사이트 성격에 따라 조합이 달라집니다.
그래서 저는 워드프레스 최적화를 할 때 아래 순서로 보는 편입니다.
- 페이지 캐시부터 정상 동작하게 만든다
- 압축과 브라우저 캐시를 잡는다
- PHP-FPM과 웹서버 구조를 점검한다
- DB 호출이 무거우면 Redis나 Valkey 오브젝트 캐시를 넣는다
이미지와 CSS·JS 최적화는 여전히 기본입니다
서버 설정만 아무리 잘해도 프런트가 무거우면 코어 웹 바이탈 점수는 잘 안 올라갑니다.
특히 워드프레스는 테마와 플러그인 때문에 불필요한 CSS, 중복 JS, 너무 큰 히어로 이미지, 광고 스크립트, 슬라이더 때문에 LCP와 INP, CLS가 같이 무너지는 경우가 많습니다.
그래서 서버 단 세팅과 별개로 아래는 기본처럼 같이 봅니다.
- 첫 화면 대표 이미지 크기와 포맷
- lazy load 적용 범위
- 필요 없는 JS 지연 또는 제거
- 광고 코드 개수와 위치
- 폰트 preload 여부
- 외부 스크립트 최소화
광고를 많이 넣는 사이트는 특히 CLS가 쉽게 무너집니다. 광고 영역 높이를 미리 잡지 않거나, 본문 중간 광고가 늦게 밀려 들어오면 사용자가 읽던 부분이 움직이기 때문입니다.
코어 웹 바이탈은 지금 기준으로 봐야 합니다
예전 글들에는 아직 FID를 많이 쓰지만, 지금은 핵심 지표를 LCP, INP, CLS 기준으로 보는 편이 맞습니다.
그래서 블루호스트 VPS를 쓰든, 워드프레스를 쓰든, 속도 점검은 이 세 가지를 기준으로 보는 쪽이 더 정확합니다.
| 지표 | 무엇을 보는지 | 좋음 기준 |
|---|---|---|
| LCP | 가장 큰 콘텐츠가 보이기까지 걸리는 시간 | 2.5초 이하 |
| INP | 클릭·탭·입력 반응 지연 | 200ms 이하 |
| CLS | 로딩 중 화면이 밀리는 정도 | 0.1 이하 |
워드프레스에서 LCP는 첫 화면 큰 이미지, TTFB, 캐시, 압축, CDN 영향을 많이 받고, INP는 무거운 JS, 서드파티 스크립트, 관리자 바와 동적 요소, 과도한 이벤트 처리 영향을 많이 받습니다.
CLS는 광고, 이미지 사이즈 미지정, 폰트 교체, 늦게 들어오는 위젯에서 자주 깨집니다.
블루호스트 VPS에서 실제로 체감이 큰 조합
제 기준에서는 아래 조합이 가장 현실적이었습니다.
- PHP-FPM 활성화
- 도메인별 최신 안정 PHP 버전 적용
- Optimize Website로 텍스트 압축 활성화
- 페이지 캐시 플러그인 또는 서버 페이지 캐시 적용
- DB 부담이 크면 Redis 오브젝트 캐시 추가
- 정적 파일이 많으면 NGINX reverse proxy 또는 LiteSpeed 구조 검토
- 이미지와 광고 코드 정리
- 코어 웹 바이탈은 LCP·INP·CLS 기준으로 재점검
이렇게 하면 단순히 점수만 좋아지는 게 아니라 관리자 저장 반응, 카테고리 목록 진입, 검색, 로그인, 주문·결제 직전 화면, 첫 방문 로딩처럼 실제 사용자가 체감하는 구간이 같이 좋아지는 경우가 많았습니다.
이런 사이트라면 오브젝트 캐시를 더 적극적으로 볼 만합니다
- 쇼핑몰
- 회원 등급이나 로그인 기능이 많은 사이트
- 상품·글 수가 매우 많은 사이트
- 검색과 필터를 자주 쓰는 사이트
- 관리자 화면이 유독 느린 사이트
- 트래픽이 꾸준히 올라가는 미디어형 사이트
반대로 글 몇 개 올리는 가벼운 개인 블로그라면 페이지 캐시와 이미지 최적화, 압축만으로도 충분히 만족스러운 경우가 많습니다. 그러니 오브젝트 캐시는 유행처럼 넣기보다 사이트 구조를 먼저 보는 편이 낫습니다.
WHM과 cPanel에서 같이 챙기면 좋은 부가 설정
속도만 보더라도 실제 운영에서 같이 챙기면 좋은 메뉴가 꽤 있습니다.
- 백업 정책 : 캐시나 PHP 변경 전에 롤백 수단 확보
- 서비스 SSL : cPanel·WHM 로그인 구간 보안 점검
- 연락 이메일 : 서버 장애, 디스크, 서비스 알림 수신
- SSH 접근 : WP-CLI, 캐시 플러시, 점검 자동화
- 방화벽 : 속도와 별개로 무차별 로그인·봇 트래픽 차단
이 부분은 직접 속도 점수를 올리는 메뉴는 아니지만, 운영 안정성을 높여서 결과적으로 서버가 버벅이는 일을 줄이는 데 도움이 됩니다.
블루호스트 VPS에서 속도를 올리는 방법은 하나가 아닙니다.
cPanel 압축, WHM의 PHP-FPM, EasyApache 4, NGINX reverse proxy, 워드프레스 페이지 캐시, Redis 오브젝트 캐시, 이미지와 광고 코드 정리가 각각 따로 노는 게 아니라 서로 맞물려 돌아갑니다.
그래서 제 기준에서는 무조건 플러그인부터 넣기보다, 현재 서버 구조를 먼저 파악하고, 그다음 캐시 계층을 순서대로 쌓는 방식이 가장 덜 꼬였습니다. 서버 권한이 있는 VPS를 쓰고 있다면, 이 차이를 제대로 누릴 수 있습니다.
공식 문서 링크 모음
- Bluehost WHM Support Guide
- Bluehost Getting Started with VPS
- Bluehost VPS Hosting Scope of Support
- cPanel WHM MultiPHP Manager
- cPanel PHP-FPM and php.ini
- cPanel Optimize Website
- cPanel NGINX with Reverse Proxy
- cPanel Redis via Containers
- cPanel Valkey via Containers
- WordPress Cache Handbook
- Redis Object Cache Plugin
- Core Web Vitals Official Guide