트래픽이 줄어드는 진짜 신호, 워드프레스 속도 저하
방치했던 워드프레스 사이트가 어느 날 갑자기 트래픽이 끊기듯 줄어들 때가 있다. 대책 없이 내버려 두면 서버 응답 시간(TTFB)이 길어지고 구글 검색 결과에서도 순식간에 밀려난다. 내가 직접 자동화 SaaS를 운영하며 겪었던 일인데, 급격한 일일 방문자수 하락을 확인하고 서버 로그를 뒤져보니 원인은 단순했다. 복구하느라 반나절을 꼬박 쓴 적이 있다. 워드프레스 속도 저하는 단순히 사용자가 불편을 느끼는 문제를 넘어, 검색 엔진이 사이트를 신뢰하는지를 판단하는 잣대가 된다.
속도 문제를 감지하려면 감에 의존하지 말고 지표를 봐야 한다. 구글 페이지 스피드 인사이트 점수가 좋지 않거나, LCP(최대 콘텐츠 페인트) 수치가 2.5초를 넘어간다면 이미 경고 신호다. 모바일 환경에서의 트래픽 감소 원인을 찾을 때는 특히 더 이 수치들을 믿고 수술에 들어가는 게 맞다.
방치했던 사이트, 어느 날 갑자기 트래픽이 끊긴 이유
자동화로 운영되는 사이트는 관리자가 매일 들르지 않기 때문에 문제가 터지고 나서야 알게 되는 경우가 많다. 내 블로그를 포함해 여러 사이트를 모니터링하던 중, 한동안 꾸준히 들어오던 검색 유입이 바닥을 치는 날이 있었다. 확인해 보니 워드프레스 코어와 플러그인 업데이트가 쌓이면서 리소스 사용량이 폭발해 쿼리가 멈춰 있었다. 방치가 얼마나 치명적인지 실감했다.
내 사이트 속도가 느린지 확인하는 필수 지표 3가지
워드프레스 속도 측정은 도구 하나만 믿으면 안 된다. PageSpeed Insights와 웹마스터 도구의 실제 사용자 데이터(CrUX)를 같이 봐야 한다. 특히 TTFB, LCP, CLS 이 세 가지는 기본으로 체크해야 한다. 도구 점수만 믿으면 안 된다. 수치가 좋아 보여도 실제 사용자가 느끼는 체감 속도와 다를 수 있기 때문에, 직접 모바일로 접속해 로딩 바가 얼마나 걸리는지 세는 것도 중요하다.
속도를 죽이는 3대 주범: 이미지, 플러그인, 그리고 호스팅
솔직히 워드프레스가 느려지는 이유는 뻔하다. 이미지, 플러그인, 호스팅 환경 이 3가지가 압도적으로 크다. 그럼 어디부터 손대야 하나. 하지만 단순히 “이미지가 무겁다”라고 말하는 건 의미가 없다. 기술적으로 어떤 메커니즘으로 속도를 잡아먹는지 이해해야 해결책이 보인다. 1인 빌더로서 여러 플러그인을 섞어 쓰다가 서버가 다운되었던 실패 사례는 이 원인들을 명확히 보여준다.
용량은 줄었는데 여전히 느린 ‘플러그인 과부하’의 함정
플러그인은 개수만 문제가 아니다. 활성화된 플러그인 하나하나가 훅(Hook)을 걸어 매 페이지 로딩마다 코드를 실행하기 때문이다. 예전에 기능이 겹치는 SEO 플러그인 두 개를 동시에 켜두었다가 사이트가 먹통이 된 적이 있다. 불필요한 기능이 쌓이면 캐싱을 해도 소용이 없다. 웹 호스팅 속도가 아무리 좋아도 플러그인이 내는 쿼리를 감당하지 못한다면 느릴 수밖에 없다.
저렴한 호스팅이 불러오는 ‘데이터베이스 병목’ 현상
저렴한 공유 호스팅을 쓸 때 발생하는 가장 큰 문제는 데이터베이스 병목이다. CPU나 메모리 제한에 걸리면 쿼리가 대기열에 쌓이고, 이는 곧 바로 로딩 속도 저하로 이어진다. 나는 크론 잡을 이용해 콘텐츠를 발행할 때, 데이터베이스 트랜잭션이 몰리는 시간대에 서버 응답 시간이 눈에 띄게 늘어나는 것을 목격했다. 찰나의 순간에 쌓이는 요청을 처리하지 못하면 502 에러를 뱉기도 한다.
압축되지 않은 이미지가 렌더링을 막는 순간
이미지 최적화 방법을 모르는 사이트는 로딩의 절반을 이미지 렌더링에 잡아먹는다. 단순히 용량을 줄이는 것(WebP 변환)만으로는 부족하고, 레이아웃 이동(CLS)을 막기 위해 width와 height 속성을 명시해야 한다. 압축되지 않은 고해상도 이미지가 브라우저가 그려지는 순간을 막고 있으면, 아무리 HTML이 가볍게 짜여 있어도 사용자는 느린 사이트라고 느낀다.
1인 사업자가 지켜야 할 플러그인 개수와 관리법
그렇다면 도대체 플러그인은 몇 개까지 써야 안전한가. 인터넷에 떠도는 “무조건 10개 이하” 같은 말은 믿지 않는다. 사이트의 트래픽과 호스팅 사양에 따라 달라지기 때문이다. 내가 운영하는 SaaS 사이트들을 기준으로 삼으면, 실제로는 활성 플러그인 수가 중요한 게 아니라 ‘양질의 플러그인’인지가 핵심이다.
성능에 지장 없는 적정 플러그인 개수는 몇 개인가?
경험상 워드프레스 필수 플러그인이라 불리는 것들 외에 추가 기능은 최소한으로 줄이는 게 맞다. 나는 현재 운영 중인 메인 사이트에서 보안, 백업, SEO 기본 기능을 포함해 10개 내외로 유지한다. 이 숫자를 넘어가면 플러그인 충돌 해결하느라 소모되는 시간이 늘어난다. 가볍고 잘 만들어진 플러그인 하나가 무거운 것 세 개보다 낫다.
기능이 겹치는 플러그인 찾아내고 제거하는 법
설치된 플러그인 리스트를 보고 기능이 겹치는 부분이 없는지 점검해야 한다. 예를 들어, 페이지 빌더 테마 안에 SEO 설정 기능이 있는데 별도의 SEO 플러그인을 또 켜두는 경우다. Query Monitor 같은 도구를 쓰면 어떤 플러그인이 쿼리를 많이 날리는지 확인할 수 있다. 무료 최적화 도구로도 충분히 찾아낼 수 있으니 방치하지 말고 주기적으로 청소해야 한다.
무료 플러그인만으로 최적화할 수 있는 한계점
무료 플러그인만으로 모든 것을 해결하려다 보면 한계에 부딪힌다. 개수만 늘리는 방식은 안 통한다. 특히 이미지 서빙이나 고급 캐싱 기능은 유료 버전에서만 제대로 작동하는 경우가 많다. 그렇다고 무조건 돈을 쓰자는 건 아니다. 무료 티어로 가능한 범위를 최대한 끌어올린 뒤, 그래도 부족할 때 코드 레벨의 개입으로 해결하는 게 1인 개발자의 현실적인 접근법이다.
플러그인 없이 무료로 적용하는 핵심 최적화 전략
플러그인을 계속 추가하는 건 방법이 아니다. 결국 코드 레벨로 건드리는 게 가장 확실하다. 나는 플러그인 충돌 없이 순수 코드나 테마 함수(functions.php)를 수정해 비용 0원으로 스크립트 최적화를 진행한다. 방법이 딱히 어렵지 않다. Core Web Vitals 점수를 올리기 위해 직접 손을 대보자.
Core Web Vitals 점수를 빠르게 올리는 렌더링 차단 해제
LCP 줄이기 방법 중 가장 효과적인 건 렌더링을 차단하는 자바스크립트와 CSS를 제거하는 것이다. 스크립트를 푸터로 옮기려면 wp_enqueue_script()의 in_footer를 쓰고, 지연 실행이 필요하면 의존성을 고려해 strategy => 'defer'를 별도로 지정한다. 다만 이 방법은 내가 등록한 스크립트에만 통한다. 테마나 플러그인이 넣은 스크립트는 등록 인자를 내가 못 건드리므로, 출력되는 태그를 가로채 defer를 붙이는 아래 방식을 쓴다. 이 코드는 푸터로 옮기는 것이 아니라 실행을 뒤로 미루는 것이다.
// 테마의 functions.php에 추가하는 예시 코드
function defer_parsing_of_js( $url ) {
if ( is_user_logged_in() ) return $url; // 관리자는 적용 제외
if ( FALSE === strpos( $url, '.js' ) ) return $url;
if ( strpos( $url, 'jquery.js' ) ) return $url;
return str_replace( ' src', ' defer src', $url );
}
add_filter( 'script_loader_tag', 'defer_parsing_of_js', 10 );
이미지 캐싱과 로딩 우선순위 설정 방법(Lazy Load)
캐싱 설정 방법을 모른다면 이미지를 아무리 압축해도 어차피 느리다. 브라우저 캐싱 만료 기간을 설정하고, 화면에 보이지 않는 이미지는 로딩하지 않는 Lazy Load를 적용해야 한다. 요즘은 워드프레스 코어에 네이티브 Lazy Load가 포함되어 있지만, 세밀한 제어를 위해서는 속성을 추가해 주는 게 좋다. ‘loading=”lazy”‘ 속성을 자동으로 주입하는 코드는 이미지 로딩 순서를 조절해 체감 속도를 크게 개선한다.
필수 코드만 남기고 CSS/JS를 최소화하는 팁
크론 발행 자체는 스크립트 로딩 순서를 바꾸지 않으며, 순서 문제가 있다면 테마·플러그인의 enqueue 의존성과 발행 훅에서 실행되는 코드를 점검해야 한다. 나는 사용하는 페이지에서만 호출되도록 스크립트를 조건부 로드(Conditional Loading) 한다. 모든 페이지에 구글 폰트나 외부 라이브러리를 싹 다 로드하는 습관을 버리고, 특정 페이지 ID에서만 작동하게 코드를 좁히는 것이다. 플러그인 충돌을 걱정할 필요 없이 서버 응답 시간을 단축하는 가장 강력한 무료 방법이다.
자동화된 워드프레스 관리를 위한 순환 고리
1인 개발자가 매일 사이트를 들여다보며 확인할 수는 없다. 그렇기 때문에 시스템을 믿고 운영할 수밖에 없다. 내가 현재 cron 63개를 돌리며 자동화 SaaS를 운영하는 방식은 워드프레스 관리도 예외가 아니다. 정기적인 데이터베이스 정리와 로그 모니터링은 손으로 하는 게 아니라 스크립트가 대신한다.
정기적인 데이터베이스 정리와 로그 모니터링 습관
시간이 지나면 워드프레스 데이터베이스에 쓰레기 데이터(Revision, 스팸 댓글 등)가 쌓인다. 이걸 주기적으로 비워주지 않으면 쿼리가 느려진다. 나는 매주 자동으로 DB 최적화 명령을 실행하도록 세팅해 뒀다. 사람이 매일 확인할 수 없기 때문에 시스템(Cron)을 활용해 정리하는 아일리고만의 운영 방식이라고 할 수 있다. 로그를 보다가 이상치가 잡히면 알림이 오게 만들어두면 된다.
테마와 플러그인 업데이트 전 점검 리스트
자동화가 편하지만, 업데이트는 조심해야 한다. 업데이트가 충돌을 일으켜 사이트를 죽이는 경우도 있으니까. 나는 테마와 플러그인 업데이트 전 항상 백업이 완료되었는지 확인한다. 그리고 메인 사이트가 아니면 테스트 환경에서 먼저 돌려본다. 이 순서를 지키지 않아 몇 번이나 긴급 복구를 했었는지 모른다.
SEO와 속도 모두 잡는 메타데이터 자동화의 필요성
속도만 빠르다고 끝이 아니다. SEO와 속도 모두 잡아야 트래픽이 유지된다. 글을 발행할 때마다 메타 데이터를 수동으로 입력하는 건 비효율적이다. 자동화된 파이프라인이 초안을 만들 때 메타 태그도 함께 세팅하도록 구성해야 한다. 속도 최적화는 기본이고, 그 위에 SEO 요소가 자동으로 씌워져야 1인 사업자가 버틸 수 있다.
요약: 지금 당장 점검해야 할 속도 체크리스트
마지막으로 지금 당장 서버에 접속해서 확인해 봐야 할 항목들을 정리한다. 그냥 오늘 해도 늦지 않다.
- LCP는 75백분위에서 2.5초 이하를 목표로 하고, TTFB는 별도 진단 지표로서 대략 0.8초 이하를 목표로 점검한다.
- 사용하지 않는 플러그인 비활성화 및 삭제 (비활성만으로도 리소스는 먹는다)
- 이미지 파일 포맷 WebP로 변환 및 width/height 속성 값 확인
- 데이터베이스 쓰레기 데이터(수정 이력 등) 수동 삭제 또는 플러그인 최적화 실행
- 테마의 functions.php 파일에서 불필요한 스크립트 로드 제거 코드 추가
이 정도만 점검해도 사이트 속도는 눈에 띄게 빨라진다. 방치는 곧 비용이다. 오늘 확인하지 않으면 내일 트래픽은 그대로 사라진다.
참고한 공식 문서
여기 올라오는 글의 초안은 운영자가 만든 AI 파이프라인이 자동으로 만듭니다. 다만 문체·사실성 검사를 통과하지 못한 초안은 공개되지 않고 사람이 손봅니다. 그 과정은 포트폴리오에서 볼 수 있습니다.
