구글이 말하는 합격선은 LCP 2.5초, INP 200밀리초, CLS 0.1입니다. 이 세 개를 못 넘기면 아무리 글이 좋아도 모바일 이탈이 늘어나요. 그런데 여기서 많은 분이 곧장 테마부터 갈아엎습니다. 답부터 말하면, 워드프레스 테마 속도는 전체 로딩 시간의 결정적 변수가 맞지만 원인의 전부는 아니에요. 테마가 요청하는 CSS·JS 파일 수와 웹폰트 처리 방식이 LCP를 좌우하는 반면, 서버 응답을 뜻하는 TTFB는 호스팅 몫이고 이미지 용량은 운영 습관 몫입니다. 그래서 순서가 중요해요. 먼저 병목이 어디인지 3단계로 가려내고, 그다음 테마 교체가 손익이 맞는지 계산하는 겁니다. 이 글은 진단 → 지표 해석 → 테마 조건 → 유형별 비교 → 교체 없이 개선 → 안전한 이사 순으로, 비전공자도 그대로 따라 할 수 있게 정리했어요.
- 테마를 바꾸면 정말 빨라질까, 결론부터
- 느린 원인이 테마인지 가려내는 3단계 진단법
- 숫자로 읽는 속도 지표, 어디까지 맞춰야 하나
- 빠른 테마의 공통 조건 체크리스트
- 테마 유형별 성능 비교
- 테마를 바꾸지 않고 개선하는 순서
- 교체 결정 기준과 안전한 이사 절차
- 바꾼 뒤 관리 루틴과 자주 나오는 후속 문제
- 자주 묻는 질문
- 참고자료
테마를 바꾸면 정말 빨라질까, 결론부터
📌 핵심 요약
테마 교체는 프런트엔드 렌더링 구간(LCP·CLS)을 크게 줄여주지만 서버 응답(TTFB)과 이미지 용량은 그대로이므로, 기본 테마 테스트로 병목을 확인한 뒤에 결정하는 게 맞습니다.
워드프레스 한 페이지가 열릴 때 브라우저는 보통 40~90개의 파일을 내려받아요. HTML 한 개, 스타일시트 몇 개, 자바스크립트 몇 개, 폰트, 이미지가 뒤섞여 있죠. 이 중 스타일시트와 자바스크립트, 웹폰트를 몇 개나 부르는지를 결정하는 게 바로 테마입니다.
무거운 멀티퍼포스 테마는 페이지 하나에 CSS·JS만 20~30개를 불러오는 경우가 흔해요. 슬라이더, 아이콘 폰트, 애니메이션 라이브러리, 자체 그리드 시스템이 통째로 들어 있는데, 정작 블로그 글 페이지에서는 그중 대부분을 쓰지 않습니다.
반대로 경량 테마는 같은 페이지를 CSS 1~3개, JS 0~2개로 그려냅니다. 이 차이가 렌더링 차단 리소스를 줄여 LCP를 앞당기는 거예요. 그래서 무거운 테마에서 경량 테마로 옮기면 모바일 LCP가 4초대에서 2초 초반으로 내려오는 사례가 자주 보고됩니다.
다만 여기서 착각하기 쉬운 지점이 있어요. 테마를 바꿔도 서버가 HTML 첫 바이트를 뱉는 데 걸리는 시간, 즉 TTFB는 거의 그대로입니다. 공유 호스팅에서 TTFB가 800밀리초를 넘고 있다면 테마를 어떤 걸 써도 합격선을 맞추기 어려워요.
💡 꼭 알아두세요
속도 개선의 손익비는 보통 이 순서입니다. ① 이미지 최적화 ② 캐싱 ③ 호스팅 ④ 테마 ⑤ 플러그인 정리. 앞의 세 개를 안 한 상태에서 테마부터 바꾸면 며칠을 쓰고도 점수가 10점밖에 안 오를 수 있어요.
느린 원인이 테마인지 가려내는 3단계 진단법
가장 흔한 실수는 측정 없이 감으로 판단하는 겁니다. “느린 것 같다”는 느낌만으로 유료 테마를 결제하고, 이틀 동안 디자인을 다시 잡고 나서야 원인이 이미지였다는 걸 알게 되는 경우가 많아요. 진단은 30분이면 끝납니다.
기준값 기록하기
PageSpeed Insights에서 홈, 글 목록, 대표 글 3개 URL을 모바일 기준으로 측정하고 LCP·CLS·TTFB 숫자를 메모장에 적어둡니다. 점수보다 이 세 숫자가 중요해요. GTmetrix의 워터폴 탭에서 요청 수와 총 페이지 용량도 함께 적습니다.
기본 테마로 갈아 끼워보기
스테이징 사이트나 트래픽이 적은 새벽에, 워드프레스 기본 테마(Twenty 시리즈)로 잠깐 전환해 같은 URL을 다시 측정합니다. LCP가 1초 이상 줄면 테마가 진짜 병목이고, 0.3초 안팎이면 범인은 다른 데 있어요.
플러그인 절반씩 끄며 좁히기
플러그인을 절반 비활성화하고 측정, 다시 그 절반을 끄고 측정하는 이분 탐색 방식이 가장 빠릅니다. 슬라이더, 소셜 공유, 관련 글 추천, 폼 빌더 계열이 상습적으로 무겁습니다.
세 단계를 마치면 병목이 숫자로 드러납니다. 예를 들어 기본 테마에서 LCP가 4.1초에서 2.3초로 줄었다면 테마 요인이 1.8초, 그런데도 TTFB가 여전히 900밀리초라면 호스팅에서 추가로 깎을 여지가 0.5초쯤 남아 있는 식이죠.
⚠️ 주의사항
운영 중인 사이트에서 테마를 바꿔 끼우면 그동안 방문한 사람에게 깨진 화면이 보입니다. 호스팅사가 제공하는 스테이징 기능이나 로컬 환경에서 테스트하고, 여의치 않으면 점검 모드 플러그인을 켠 상태로 5분 안에 끝내세요.
숫자로 읽는 속도 지표, 어디까지 맞춰야 하나
PageSpeed Insights 점수 100점을 목표로 삼는 순간 고생이 시작됩니다. 점수는 여러 지표를 가중 평균한 값이라, 같은 사이트를 연속 측정해도 5~10점씩 흔들려요. 구글이 검색 순위에 실제로 참고한다고 밝힌 건 점수가 아니라 Core Web Vitals의 실사용자 데이터입니다.
| 지표 | 합격 기준 | 주된 원인 |
|---|---|---|
| LCP (최대 콘텐츠 표시) | 2.5초 이하 | 대표 이미지 용량, 렌더링 차단 CSS, 웹폰트, 느린 서버 |
| CLS (레이아웃 이동) | 0.1 이하 | 이미지 크기 미지정, 광고 영역, 폰트 교체 시 밀림 |
| INP (상호작용 반응) | 200ms 이하 | 무거운 자바스크립트, 슬라이더·팝업 스크립트 |
| TTFB (첫 바이트) | 600ms 이하 권장 | 호스팅 성능, 캐싱 미적용, 서버 위치, PHP 버전 |
현실적인 목표는 이렇게 잡는 걸 권합니다. 모바일 점수 70점대, LCP 2.5초 이하, CLS 0.05 이하. 여기까지만 와도 검색 노출에서 속도 때문에 손해 보는 일은 거의 없어요. 90점대를 위해 자바스크립트를 지연 로딩으로 밀어붙이다 보면 댓글창이나 메뉴가 안 열리는 부작용이 생깁니다.
또 하나, 실험실 데이터와 실사용자 데이터를 구분해야 해요. PageSpeed Insights 상단의 “실제 사용자 환경” 항목이 실사용자 데이터인데, 방문자가 적은 신생 블로그는 이 데이터가 아예 안 뜹니다. 그럴 땐 아래쪽 실험실 점수를 참고하되 절대치로 믿지 마세요.
빠른 테마의 공통 조건 체크리스트
테마 판매 페이지의 “초고속”이라는 문구는 판단 기준이 못 됩니다. 대신 데모 사이트 URL을 그대로 PageSpeed Insights에 넣어보면 됩니다. 데모는 보통 이미지가 많아 실사용보다 무겁게 나오지만, 요청 수와 JS 실행 시간은 참고할 만해요.
📋 테마 고를 때 점검 체크리스트
✓ jQuery 없이 동작하는가 (바닐라 JS 여부 명시)
✓ 아이콘 폰트 대신 SVG를 쓰는가
✓ 구글 폰트를 외부 호출 없이 로컬로 담을 수 있는가
✓ 블록 에디터를 네이티브로 지원하는가
✓ 쓰지 않는 기능을 설정에서 끌 수 있는가
✓ 최근 6개월 안에 업데이트 기록이 있는가
이 중 체감 차이가 가장 큰 항목은 웹폰트입니다. 한글 웹폰트는 글자 수가 많아 파일이 크고, 서브셋 처리가 안 된 폰트 하나가 1MB를 넘기도 해요. 외부 CDN에서 불러오면 DNS 조회와 연결 시간까지 더해집니다. 폰트를 서버에 직접 올리고 font-display를 swap으로 두는 것만으로 LCP가 0.5초 가까이 줄어드는 경우가 많습니다.
두 번째는 “끌 수 있는 기능”의 유무입니다. 슬라이더, 라이트박스, 무한 스크롤 같은 기능을 설정 화면에서 개별로 끌 수 있는 테마는 실제 사용 페이지의 요청 수를 절반까지 줄일 수 있어요. 반대로 전부 묶여 있는 테마는 코드를 건드리지 않는 한 다이어트가 불가능합니다.
테마 유형별 성능 비교
특정 상품명을 나열하는 대신 유형으로 보는 게 실용적이에요. 테마는 계속 바뀌지만 유형별 구조적 특성은 잘 안 바뀌거든요. 아래는 같은 글 한 편을 같은 호스팅에 올렸을 때 흔히 관찰되는 범위입니다.
| 테마 유형 | CSS·JS 요청 | 모바일 LCP 경향 | 누가 쓰면 좋은가 |
|---|---|---|---|
| 경량 블로그형 (GeneratePress·Astra 계열) | 2~5개 | 1.8~2.5초 | 글 중심 블로그, 애드센스 운영자 |
| 워드프레스 기본 블록 테마 (Twenty 시리즈) | 1~3개 | 1.5~2.3초 | 디자인 욕심 없이 속도만 챙길 때 |
| 멀티퍼포스 올인원형 | 15~30개 | 3.5~5초 | 디자인 시안이 급하고 속도는 후순위일 때 |
| 경량 테마 + 페이지 빌더 조합 | 8~18개 | 2.5~4초 | 랜딩페이지가 필요한 1인 사업자 |
표에서 눈여겨볼 대목은 세 번째 줄과 네 번째 줄의 차이예요. 페이지 빌더가 무조건 느린 게 아니라, 빌더를 쓰는 페이지에서만 무거워집니다. 랜딩페이지는 빌더로 만들고 블로그 글은 블록 에디터로 쓰면, 글 페이지에서는 빌더 스크립트가 로드되지 않도록 설정할 수 있어요.
또 하나. 무료냐 유료냐는 속도와 직접 상관이 없습니다. 공식 저장소의 무료 경량 테마가 고가의 멀티퍼포스 테마보다 훨씬 빠른 경우가 흔해요. 유료로 지불하는 건 대개 디자인 프리셋과 지원이지 성능이 아닙니다.
테마를 바꾸지 않고 개선하는 순서
진단 결과 테마 기여도가 1초 미만이라면 교체는 답이 아닙니다. 아래 순서대로만 해도 모바일 점수가 20~30점 오르는 일이 흔해요. 위에서부터 하나씩, 한 번에 하나만 바꾸고 재측정하는 게 요령입니다.
이미지부터 잡기
대표 이미지 한 장이 2MB면 다른 걸 아무리 손봐도 소용없어요. 업로드 전에 가로 1200px 이하로 줄이고, WebP로 변환합니다. 이미지 최적화 플러그인은 자동 변환과 레이지 로딩을 함께 켜두면 됩니다. 단, 첫 화면에 보이는 대표 이미지는 레이지 로딩 대상에서 제외해야 LCP가 오히려 나빠지지 않아요.
페이지 캐싱 켜기
캐싱 플러그인 하나로 TTFB가 절반 이하로 떨어지는 경우가 많습니다. 방문할 때마다 PHP가 페이지를 새로 만드는 대신 완성된 HTML을 내주기 때문이죠. 캐싱 플러그인은 반드시 하나만 씁니다. 두 개를 겹쳐 쓰면 화면이 깨집니다.
폰트 로컬화와 개수 줄이기
웹폰트는 굵기 2종(400·700)이면 충분합니다. 300·500·800까지 다 부르면 파일이 서너 배가 돼요. 외부 CDN 호출 대신 서버에 올려 쓰고, 서브셋 버전이 제공되면 그걸 씁니다.
CSS·JS 정리와 PHP 버전 올리기
미니파이와 병합, 사용하지 않는 CSS 제거 옵션을 하나씩 켜며 화면이 깨지지 않는지 확인합니다. 호스팅 관리 화면에서 PHP 버전을 최신 안정판으로 올리는 것도 체감이 큽니다. 오래된 버전은 처리 속도가 눈에 띄게 느려요.
CDN과 데이터베이스 정리
해외 방문자가 있다면 CDN이 효과적이지만, 국내 방문자 위주면 우선순위가 낮습니다. 대신 리비전과 스팸 댓글, 만료된 임시 데이터를 정리하면 관리자 화면이 눈에 띄게 가벼워져요.
⚠️ 주의사항
최적화 플러그인의 “사용하지 않는 CSS 제거”와 “JS 지연 로딩”은 화면을 깨뜨리는 대표적인 옵션입니다. 켠 뒤에는 반드시 시크릿 창으로 모바일·PC 양쪽에서 메뉴 열기, 검색, 댓글 작성까지 눌러보고 넘어가세요.
교체 결정 기준과 안전한 이사 절차
교체를 권할 만한 상황은 꽤 명확합니다. 기본 테마 테스트에서 LCP가 1초 이상 줄었고, 지금 테마의 마지막 업데이트가 1년 넘게 없고, 쓰지 않는 기능을 끌 방법이 없을 때. 이 세 가지 중 둘 이상이면 갈아타는 게 장기적으로 이득이에요.
반대로 교체가 답이 아닌 경우도 분명합니다. 커스텀 필드나 전용 숏코드에 콘텐츠가 묶여 있는 사이트, 쇼핑 기능을 테마가 담당하는 사이트, TTFB가 1초를 넘는 저사양 호스팅. 이럴 땐 테마보다 호스팅이나 콘텐츠 구조를 먼저 손봐야 합니다.
비용 감각도 미리 잡아두면 좋아요. 경량 테마 교체는 보통 반나절에서 이틀이 걸립니다. 메뉴·위젯 재설정 1~2시간, 색상과 타이포 조정 2~3시간, 숏코드로 만든 요소를 블록으로 바꾸는 데 나머지 시간이 들어가요. 글이 500편이 넘으면 본문 점검에만 하루가 더 필요합니다.
📋 테마 교체 전 준비 체크리스트
✓ 스테이징 사이트 생성 (호스팅 기능 또는 로컬)
✓ 현재 테마의 커스텀 CSS 전문 복사해두기
✓ 애드센스·애널리틱스 코드가 어디에 삽입됐는지 확인
✓ 테마 전용 숏코드를 쓴 글 목록 추리기
✓ 교체 전 지표(LCP·CLS·TTFB) 기록
순서는 스테이징에서 새 테마를 적용하고, 상단 메뉴·사이드바·푸터를 다시 잡고, 대표 글 5편을 열어 레이아웃을 확인한 뒤 라이브에 반영하는 식이 안전합니다. 추적 코드는 테마 설정이 아니라 코드 삽입 전용 플러그인이나 자식 테마에 넣어두면 다음 교체 때 다시 헤맬 일이 없어요.
되돌리는 법도 미리 정해두세요. 새 테마를 켜고 24시간 동안 이탈률과 오류 로그를 지켜보다가, 문제가 있으면 이전 테마를 다시 활성화하면 됩니다. 워드프레스는 테마를 삭제하지 않는 한 설정 대부분이 남아 있어 복귀가 어렵지 않아요.
바꾼 뒤 관리 루틴과 자주 나오는 후속 문제
교체 직후 측정한 점수는 캐시가 비어 있어 실제보다 낮게 나옵니다. 캐싱 플러그인의 프리로드를 돌리고 두세 시간 뒤에 다시 재보세요. 실사용자 데이터는 반영에 최대 28일이 걸리므로, 서치콘솔의 페이지 개선 보고서는 한 달 뒤에 확인하는 게 맞습니다.
모바일 점수가 PC보다 20~30점 낮은 건 정상입니다. 측정 도구가 모바일에서 느린 회선과 저성능 기기를 가정하기 때문이에요. 그러니 PC 95점에 집착하기보다 모바일 LCP를 2.5초 아래로 붙잡는 데 힘을 쓰는 게 실익이 큽니다.
관리자 페이지만 유독 느린 경우도 자주 나옵니다. 이건 테마보다 플러그인이 대시보드에 붙이는 위젯, 자동 업데이트 확인 요청, 과도한 리비전과 스팸 데이터가 원인인 경우가 많아요. 리비전 저장 개수를 5개 정도로 제한하고 대시보드 위젯을 정리하면 대부분 해결됩니다.
💡 꼭 알아두세요
월 1회, 홈과 대표 글 3개를 같은 시간대에 측정해 스프레드시트에 기록해두면 언제 무엇 때문에 느려졌는지 추적이 됩니다. 새 플러그인을 설치한 날짜를 같은 시트에 적어두는 게 핵심이에요.
자주 묻는 질문
테마를 바꾸면 속도가 실제로 얼마나 빨라지나요?
무거운 멀티퍼포스 테마에서 경량 테마로 옮기면 모바일 LCP가 1~2초 줄어드는 경우가 많습니다. 다만 이미 경량 테마를 쓰고 있다면 개선폭은 0.2초 안팎에 그칩니다. 기본 테마 테스트로 예상 개선폭을 먼저 확인하는 게 정확해요.
무료 테마와 유료 테마 중 어느 쪽이 빠른가요?
가격과 속도는 상관관계가 약합니다. 공식 저장소의 무료 경량 테마가 고가 테마보다 빠른 경우가 흔해요. 유료 비용은 대개 디자인 프리셋, 데모 임포트, 기술 지원에 대한 값입니다.
PageSpeed Insights 점수는 몇 점이면 충분한가요?
모바일 70점 이상이면서 LCP 2.5초·CLS 0.1을 통과하면 실무적으로 충분합니다. 구글이 순위에 참고하는 건 점수가 아니라 실사용자 Core Web Vitals 데이터라서, 90점을 위해 기능을 망가뜨리는 건 손해예요.
페이지 빌더를 쓰면 반드시 느려지나요?
빌더로 만든 페이지만 무거워지고 블록 에디터로 쓴 글은 영향을 덜 받습니다. 빌더 설정에서 사용하지 않는 위젯 모듈을 끄고, 글 페이지에서 빌더 에셋이 로드되지 않도록 하면 차이를 크게 줄일 수 있어요.
캐싱 플러그인만 설치하면 해결되나요?
TTFB는 확실히 좋아지지만 LCP와 CLS는 별개입니다. 대표 이미지가 무겁거나 폰트가 늦게 뜨면 캐싱을 켜도 체감 속도는 그대로예요. 캐싱은 다섯 단계 중 하나일 뿐이라고 보는 게 맞습니다.
참고자료
- web.dev Core Web Vitals — 구글이 정의한 LCP·INP·CLS 기준값과 측정 방법 공식 문서
- PageSpeed Insights — URL만 넣으면 실사용자·실험실 데이터를 함께 보여주는 구글 공식 측정 도구
- WordPress 공식 성능 최적화 문서 — 캐싱, 데이터베이스, 서버 설정을 다룬 개발자 핸드북
- Google Search Console — 페이지 개선 보고서에서 실사용자 기준 속도 통과 여부 확인
워드프레스 테마 속도 문제는 “테마가 범인인가”를 먼저 확인하는 데서 출발합니다. 기본 테마로 30분만 테스트해보면 교체로 얻을 시간이 1초인지 0.2초인지 숫자로 나오고, 그 숫자가 결제 버튼을 누를지 말지를 대신 결정해줘요. 개선 순서는 이미지, 캐싱, 폰트, CSS·JS 정리, 그다음이 테마입니다. 앞 네 가지를 건너뛰고 테마부터 바꾸면 시간은 시간대로 쓰고 점수는 조금밖에 안 오릅니다. 목표는 100점이 아니라 모바일 LCP 2.5초, CLS 0.1 통과예요. 오늘은 측정값 기록부터 시작하고, 한 번에 한 가지만 바꾸며 다시 재보는 순서를 권합니다. 그 기록이 쌓이면 다음에 사이트가 느려졌을 때 어디를 볼지 바로 알게 돼요.
함께 보면 좋은 글
