워드프레스 느릴 때, 플러그인보다 테마 용량 먼저 봐야 할까

플러그인을 하나씩 꺼 봤는데도 속도가 그대로라면, 이번에는 테마 자체의 무게를 재는 순서입니다. 여기서 테마 용량은 서버에 설치한 ZIP 파일이나 폴더 크기가 아니라, 페이지를 열 때 브라우저가 실제로 내려받는 CSS와 JS 등의 전송량을 뜻합니다. 테마 리소스가 주요 지연 구간을 차지하거나 다른 테마로 같은 페이지를 비교했을 때 개선된다면, 플러그인을 더 줄이기보다 테마를 먼저 점검할 이유가 있습니다.

플러그인은 설치 목록에서 바로 보이니까 느려지면 가장 먼저 의심받습니다. 반면 테마는 사이트 화면의 기본값이라 불러오는 파일이 많아도 눈에 잘 안 띕니다. 다만 설치 용량이 크다는 이유만으로 페이지도 느리다고 볼 수는 없습니다. 실제로 불러오는 파일과 그 파일 때문에 늦어지는 구간을 함께 봐야 합니다.

플러그인 다 꺼도 그대로면 다음은 뭘 보나

플러그인을 전부 비활성화한 상태에서 같은 페이지를 다시 열어 봅니다. 이때도 로딩이 묵직하다면 플러그인 밖의 원인도 살펴볼 차례입니다. 플러그인은 사이트마다 골라서 얹는 조각이라 켜고 끄면서 범인을 가려낼 수 있습니다. 다만 캐시 플러그인까지 끄면 캐시 효과도 사라지므로, 속도가 그대로라는 결과 하나로 플러그인의 영향을 전부 제외하지는 않습니다.

테마도 다른 테마로 바꿔 같은 페이지를 비교할 수 있습니다. 활성화된 테마가 화면 구성을 맡지만, 모든 CSS와 JS를 매 페이지에 불러오는지는 구현에 따라 다릅니다. 멀티퍼포스 테마처럼 여러 용도에 맞춰 기능을 다 담아 둔 테마는 실제로 쓰지 않는 빌더 스크립트와 아이콘 세트까지 함께 불러오는 경우가 있습니다. 그래서 기능 목록보다 실제 요청 목록을 보는 쪽이 정확합니다.

테마 변경 방법은 WordPress 공식 테마 안내에서 확인할 수 있습니다. WordPress.com 공식 성능 점검 안내도 테스트 사이트에서 테마 변경 전후를 비교하도록 설명합니다. WordPress.com 전용 메뉴와 호스팅 기능은 일반 설치형 워드프레스와 다를 수 있지만, 운영 사이트에 적용하기 전에 비교한다는 방향은 같습니다.

개발자도구의 Network 탭을 여는 방법은 페이지에서 마우스 오른쪽 클릭 뒤 검사를 누르는 것입니다. Network 탭에서 새로고침하면 그 페이지가 실제로 내려받는 파일 목록과 각 파일의 용량이 뜹니다. 이 목록은 다운로드를 살펴보는 곳이고, 내려받은 JS가 실행되면서 화면을 늦추는 문제는 Performance 기록이나 PageSpeed Insights 진단을 함께 봐야 합니다.

테마가 무거운지는 감이 아니라 이 숫자로 갑니다

Network 탭에는 요청(Request) 수와 전체 전송 용량이 함께 표시됩니다. 이 가운데 플러그인을 다 끈 빈 페이지 상태에서 JS 전송량만 따로 봅니다. 빈 페이지는 본문 콘텐츠의 영향을 줄여 테마가 기본으로 불러오는 파일을 살펴보려는 비교용입니다. 실제 느린 페이지도 따로 측정해야 방문자가 겪는 지연과 연결할 수 있습니다.

숫자를 모으는 순서는 그대로 두고, 무엇을 알아보려는 측정인지 나눠 두면 덜 헷갈립니다. 빈 페이지에서는 테마의 기본 파일을 보고, 실제 글에서는 그 파일이 첫 화면을 늦추는지 봅니다. 서버 응답이 오래 걸릴 때는 Query Monitor로 서버 안쪽의 단서를 더 살펴봅니다.

비교 전에 함께 기억할 주의사항

전송량이나 요청 수가 많다는 설명 뒤에 같은 단서를 반복하기보다, 판단할 때 필요한 한계를 먼저 모아 둡니다. 아래 숫자는 원인을 찾는 출발점이고, 교체 여부는 변경 전후의 지연과 기능까지 보고 정합니다.

보이는 숫자나 경고	공통 주의사항	판단을 보강할 자료
JS 전송량이 큽니다.	100KB 미만은 건강하고 300KB 초과는 비대하다는 분류를 일반 기준으로 쓰지 않습니다. 기존 수치의 표본·압축 방식·측정 환경이 명확하지 않고, 작은 JS도 실행 시간이 길 수 있습니다.	파일의 귀속, 로딩 시점, Performance의 실행 구간과 LCP 변화
전체 요청 수가 많습니다.	50개 미만은 양호하고 80개 초과는 비대하다는 분류를 일반 기준으로 쓰지 않습니다. 전체 요청에는 이미지·폰트·광고도 포함됩니다.	첫 화면에 필요한 요청인지, Waterfall에서 실제로 어디가 늦는지
사용하지 않는 CSS·JS 경고가 나옵니다.	줄일 후보를 알려 주는 경고입니다. 현재 느려짐의 주원인인지는 별도로 살펴봐야 합니다.	해당 파일 경로, 화면 표시를 막는 구간, 설정 변경 전후 결과
빈 페이지에서 파일이 줄었습니다.	테마의 기본 부담을 비교한 결과입니다. 본문·이미지·빌더가 들어간 실제 글의 개선까지 뜻하지는 않습니다.	같은 실제 글의 LCP와 필요한 기능 유지 여부

측정 준비: 빈 페이지와 실제 글을 따로 둡니다

빈 페이지는 운영 사이트를 지우는 방식이 아니라, 복제한 테스트 사이트의 관리자 화면에서 페이지 → 새로 추가로 만듭니다. 제목만 두고 본문 블록은 비우되, 기본 템플릿과 머리글·메뉴·바닥글은 남겨 둡니다. 아무것도 없는 별도 템플릿을 쓰면 테마의 공통 파일까지 빠져 비교 목적이 달라질 수 있습니다.

1. 빈 페이지 URL과 실제 느린 페이지 URL을 하나씩 정합니다. 테마를 바꾸기 전후에 각 URL의 본문·이미지와 표시할 공통 요소를 같게 두고, 템플릿 이름과 남긴 요소도 기록합니다.
2. 플러그인 비활성화는 테스트 사이트에서 진행합니다. 관리자와 분리된 로그아웃 브라우저 창으로 페이지를 열고, 비교 중에는 플러그인 상태와 서버·CDN 캐시 설정을 같게 둡니다.
3. Network에서 Disable cache를 켜고 Preserve log는 끈 뒤 요청 목록을 비우고 새로고침합니다. Disable cache는 개발자도구가 열린 동안 브라우저 캐시를 막는 설정이며, 서버·CDN 캐시까지 끄는 것은 아닙니다.
4. 스크롤하거나 메뉴를 누르지 않은 첫 화면을 기준으로, 요청이 안정된 같은 시점에 기록합니다. 두 테마 모두 같은 기기·화면 크기·네트워크 제한 설정을 사용해야 합니다.

Network 기록: 전체 JS와 테마 파일을 구분합니다

전체 JS가 줄었다는 기록만 남기면 어떤 파일이 달라졌는지 다시 찾게 됩니다. 전체 전송량과 테마 경로의 전송량을 나눠 적어 두면, 테마 설정을 줄인 효과와 다른 요청이 달라진 효과를 구분하기 쉽습니다.

측정 지표	확인 위치와 조건	해석할 때 남는 한계
JS 전송량	Network의 JS 필터를 선택합니다. Size 열의 네트워크 전송량을 합산합니다. 큰 요청 행 표시에서는 전송량과 압축을 푼 리소스 크기가 함께 보일 수 있으므로 구분합니다.	전송량은 압축·헤더 등의 영향을 받습니다. minify한 파일 크기나 압축을 푼 리소스 크기와 같지 않습니다.
테마 JS 전송량	JS 필터 상태에서 요청 URL의 /wp-content/themes/ 경로를 확인하고 해당 요청의 전송량만 따로 합산합니다.	CDN이나 합쳐진 파일은 경로만으로 귀속을 알기 어렵습니다. Initiator와 원래 파일 정보를 함께 봅니다.
전체 요청 수	필터를 지우고 All 상태에서 기록합니다. JS 필터 상태의 요청 수와 섞지 않습니다.	이미지·폰트·광고 등도 포함됩니다. 테마가 만든 요청 수와 동일하지 않습니다.
문서 응답의 TTFB	주 문서 요청을 선택하고 Timing의 Waiting for server response를 봅니다.	서버 처리뿐 아니라 네트워크 왕복과 캐시 상태도 영향을 줍니다. PHP 실행 시간만を 뜻하지 않습니다.
LCP와 실제 지연	PageSpeed Insights의 같은 기기 유형 결과에서 LCP 요소와 지연 구간을 봅니다. 필요하면 Performance 기록에서 JS 실행 구간도 살펴봅니다.	빈 페이지와 실제 글은 주요 요소가 다릅니다. 각각 변경 전후를 비교해야 합니다.

JS 필터를 적용한 뒤 하단 요약에 필터된 요청의 전송량과 전체 전송량이 함께 보이면, 필터된 쪽을 기록합니다. 표시 방식은 Chrome 버전에 따라 다를 수 있으므로 Size 열의 개별 값과 맞춰 봅니다. memory cache나 disk cache로 표시된 응답은 원래 파일 크기를 전송량처럼 더하지 않습니다. 처음 방문하는 조건으로 비교하려면 캐시 비활성화 상태에서 다시 측정하고, 서비스 워커가 응답하는 사이트라면 그 상태도 두 측정에서 맞춥니다.

열 표시와 필터·캐시 설정은 Chrome 공식 Network 기능 문서, 요청의 Initiator와 Timing 확인 방법은 Network 사용 안내를 참고했습니다. 압축된 응답인지 확인하려면 해당 요청의 Headers에서 Content-Encoding도 볼 수 있습니다.

파일과 설정을 연결할 때는 한 번에 여러 기능을 끄기보다, 실제로 쓰지 않는 기능 하나부터 비교하는 쪽이 결과를 읽기 쉽습니다. 아래 경로는 특정 테마에서 확인한 파일이 아니라 기록 방법을 보여 주는 예시입니다. 파일 이름만으로 역할을 확정하지 않고, 공식 문서의 기능 설명과 요청의 Initiator를 함께 봅니다.

파일 경로와 기능 설정을 연결하는 방법(예시)

요청 목록의 파일 예시	비교할 조건	변경 뒤 살펴볼 점
/wp-content/themes/example-theme/assets/js/slider.js	첫 화면에 슬라이더가 없고, 테마 공식 문서에 해당 기능을 끄는 설정이 있는 경우	설정을 끈 뒤 요청이 빠지는지 봅니다. 남아 있다면 그 설정은 화면 기능만 끄고 파일 로딩은 유지할 수 있습니다.
/wp-content/themes/example-theme/assets/css/icons.css	테마 아이콘을 쓰지 않고, 아이콘 로딩을 조절할 수 있는 경우	CSS 요청과 연결된 폰트 요청이 달라지는지 봅니다. 메뉴나 버튼의 아이콘이 사라지는지도 함께 봅니다.
CDN 도메인의 묶음 JS	파일 경로에서 테마 이름을 찾기 어려운 경우	Initiator와 묶음 파일의 원래 구성 정보를 봅니다. 귀속을 알 수 없다면 테마 JS 합계에 임의로 넣지 않습니다.

지연 원인 해석: 다운로드 뒤의 화면 표시까지 봅니다

PageSpeed Insights나 GTmetrix의 결과 화면에서 사용하지 않는 CSS나 JS 경고가 나온다면, 그 경고가 가리키는 파일 경로가 플러그인 폴더인지 테마 폴더인지를 봅니다. 경로가 테마 폴더 쪽으로 몰려 있으면 테마에서 줄일 파일이 있는지 살펴볼 근거가 됩니다.

예를 들어 테마 CSS가 첫 화면 렌더링을 막고 있거나, 테마 JS 실행 중 주요 요소가 늦게 그려진다면 테마 점검의 우선순위가 올라갑니다. 반대로 HTML 응답을 기다리는 시간이 길고 테마 파일은 그 뒤에 빠르게 내려받는다면 서버·캐시 쪽도 함께 봐야 합니다. web.dev의 LCP 최적화 문서는 LCP를 TTFB, 리소스 로딩 지연, 리소스 로딩 시간, 요소 렌더링 지연으로 나눠 설명합니다.

이 구분은 파일을 줄인 뒤에도 쓸모가 있습니다. 전송량은 줄었는데 LCP가 그대로라면, 줄인 파일이 첫 화면을 기다리게 하던 파일이었는지부터 다시 봅니다. 아래처럼 남은 구간을 나누면 다음에 바꿀 대상이 달라집니다.

길게 남은 구간	살펴볼 대상	변경 뒤의 검증
HTML을 받기 전의 대기	서버·CDN 캐시 상태와 문서 응답	같은 캐시 조건에서 문서 TTFB가 줄었는지 봅니다.
LCP 이미지 요청이 시작되기 전의 지연	이미지를 늦게 발견하거나 JS 처리 뒤에 요청하는 구조	같은 이미지의 요청 시작 시점이 앞당겨졌는지 봅니다.
LCP 이미지 자체의 다운로드	실제로 선택된 이미지 파일과 전송량	해당 이미지의 다운로드 시간과 LCP가 함께 줄었는지 봅니다.
파일을 받은 뒤 화면에 그리기까지의 지연	렌더링을 막는 CSS, JS 실행, 요소를 숨겨 두는 표시 조건	Performance에서 남은 작업과 요소가 표시되는 시점을 봅니다.

Query Monitor 보조 점검: 서버 안쪽의 단서를 더 봅니다

Query Monitor를 켜서 보면 데이터베이스 쿼리의 실행 시간과 호출 정보, 사용한 템플릿 등을 살펴볼 수 있습니다. 다만 쿼리 실행 시간은 템플릿이나 함수 전체의 실행 시간과 다릅니다. 이 플러그인은 점검이 끝나면 꺼 두는 쪽이 낫습니다.

브라우저에서 테마 파일이 빨리 내려받아져도 문서 응답이 늦다면, 파일 용량만 계속 줄이기보다 서버가 페이지를 만드는 쪽의 단서를 살펴볼 이유가 있습니다. Query Monitor는 그때 보조로 씁니다. 호출 정보를 보고 특정 테마나 플러그인에서 반복되는 쿼리가 있는지 좁힌 뒤, 방문자 화면의 속도 비교는 로그아웃 조건으로 다시 합니다.

Query Monitor 공식 안내는 쿼리와 호출 주체 등을 구분해 보여 주는 기능을 설명합니다. 함수 안의 특정 코드 구간을 재려면 공식 프로파일링 문서처럼 시작·종료 타이머를 코드에 넣어야 합니다. 활성화만으로 모든 함수의 실행 시간을 자동 측정하는 도구로 보면 안 되고, 코드 수정이 필요한 점검은 테스트 사이트에서 진행하는 편이 낫습니다.

요청 수까지 많다면 테마 쪽도 함께 봅니다

압축 JS 용량과 함께 봐야 할 것이 요청 수입니다. 이 두 수치는 따로 보지 않고 함께 봅니다. JS 용량만 낮아도 작은 파일을 많이 요청하는 구조라면 전체 로딩이 느려질 수 있습니다.

HTTP/2와 HTTP/3에서는 여러 요청을 함께 처리할 수 있어 요청 개수만으로 대기 시간을 예상하기 어렵습니다. 같은 80개라도 첫 화면을 막는 CSS가 많은 경우와 화면 아래 이미지를 나중에 불러오는 경우는 다릅니다. 재방문에서는 캐시로 전송량이 줄 수 있고, 광고·분석·외부 폰트 요청은 테마 폴더 밖에 있어도 오래 걸릴 수 있습니다. Network의 Protocol 열과 Waterfall, 개별 요청의 Timing을 함께 보는 이유입니다.

플러그인을 다 비활성화한 빈 페이지 상태로 측정했는데도 JS 전송량과 요청 수가 많다면, 테마가 불러오는 파일부터 확인할 이유는 있습니다. 파일의 귀속과 실제 지연 구간을 확인한 뒤, 같은 페이지의 테마 변경 전후 결과까지 맞아야 판단이 단단해집니다.

개인적으로는, 이 두 수치가 동시에 기준선을 넘는 경우라면 가벼운 테마로 바꾸는 쪽을 먼저 적어 두고 다음 방문 때 비교해 보는 편이 낫다고 봅니다. 여기서 기준선은 앞의 300KB·80개를 보편적인 합격선으로 쓰자는 뜻이 아니라, 같은 조건에서 비교할 현재 테마의 기록이나 사이트가 정한 목표를 뜻합니다. 교체는 우선 비교해 볼 후보이고, 실제 적용 여부는 속도와 필요한 기능이 함께 유지되는지 보고 정합니다.

현재 보이는 상태	먼저 해볼 선택	장점과 확인할 점
쓰지 않는 슬라이더·아이콘·효과 파일이 로드되고, 테마에 해당 기능을 끄는 설정이 있습니다.	미사용 기능부터 비활성화합니다.	기존 디자인을 유지하기 쉽습니다. 설정을 꺼도 파일이 남는 구현이 있으므로 요청 목록에서 빠졌는지 다시 봅니다.
공통 CSS·JS가 실제 지연에 관여하고, 설정을 줄여도 남습니다.	가벼운 테마로 같은 페이지를 비교합니다.	기본 리소스를 줄일 여지가 있습니다. 메뉴·위젯·빌더·자식 테마 의존 기능의 수정 비용도 함께 봅니다.
테마 파일은 줄었지만 HTML 응답 대기나 외부 요청이 그대로 길게 남습니다.	캐시·서버 응답·외부 리소스를 다음 대상으로 잡습니다.	전송량 감소와 체감 개선을 구분할 수 있습니다. 테마도 서버 처리에 영향을 줄 수 있으므로 TTFB의 변경 전후 결과까지 봅니다.

테마 교체는 자식 테마나 커스터마이저에 손댄 설정이 있다면 그 내용을 먼저 백업해 둔 뒤에 진행합니다. 파일만 복사하면 설정이 빠질 수 있어 데이터베이스도 함께 보관해야 합니다. WordPress 공식 백업 안내도 사이트 파일과 데이터베이스를 구분해 설명합니다.

1. 호스팅 백업 기능이나 백업 도구로 전체 파일과 데이터베이스를 같은 시점에 보관합니다. 내려받기나 복원 기능이 있는지 확인하고, 부모·자식 테마 파일과 직접 수정한 코드가 포함됐는지도 봅니다.
2. 커스터마이저 설정, 추가 CSS, 메뉴 위치, 위젯과 블록 테마의 템플릿·스타일 변경은 화면 기록이나 별도 복사본도 남깁니다. 데이터베이스에 보관된 설정이 있어도 새 테마가 같은 방식으로 적용하지는 않을 수 있기 때문입니다.
3. 복제한 테스트 사이트에서 외모 → 테마로 들어가 비교할 테마를 활성화합니다. 부모 테마를 바꾸면 기존 자식 테마의 수정 내용이 자동으로 옮겨지지 않으므로, 필요한 기능이 새 테마에서도 동작하는지 따로 봅니다.
4. 메뉴·모바일 화면·이미지·빌더 레이아웃·숏코드·폼 등 실제 쓰는 기능을 확인합니다. 기능을 빼거나 주요 이미지를 없애서 빨라졌다면, 같은 화면을 유지한 성능 개선과 구분해야 합니다.
5. 각 테마에서 빈 페이지와 실제 느린 페이지를 같은 조건으로 각각 3회 측정해 중앙값을 비교합니다. 테마 변경 뒤 서버·CDN 캐시를 비운다면 양쪽 모두 같은 방식으로 비우고, 예열한 캐시로 비교한다면 양쪽 모두 먼저 한 번 열어 둡니다.

변경 전후 검증: 같은 도구 안에서 비교합니다

전송량과 요청 수는 Network에서, LCP는 PageSpeed Insights의 실험실 결과에서 기록할 수 있습니다. 측정 도구마다 네트워크 조건이 다르므로 서로 다른 도구의 숫자를 직접 맞대기보다 각 도구 안에서 변경 전후를 비교합니다. PageSpeed Insights의 실제 사용자 데이터는 과거 방문 기록이 반영되므로 방금 바꾼 테마의 효과를 곧바로 보여 주는 값으로 쓰지는 않습니다.

테마 변경 전후 기록 방법과 해석 예시 — 직접 측정한 결과가 아닙니다

기록 항목	현재 테마 A(예시)	비교 테마 B(예시)
측정 환경	같은 테스트 서버, 로그아웃, 같은 모바일 화면·네트워크 설정, 브라우저 캐시 비활성화, 서버 캐시 예열	A와 동일, 같은 본문·이미지·공통 요소 유지
빈 페이지: 전체 JS 전송량 / 전체 요청 수	360KB / 84개	140KB / 49개
실제 느린 페이지: 전체 JS 전송량 / 전체 요청 수	420KB / 106개	200KB / 71개
실제 느린 페이지: 문서 TTFB 중앙값	0.9초	0.9초
실제 느린 페이지: 실험실 LCP 중앙값	3.8초	2.7초
이 예시에서의 판단	전송량과 LCP는 줄었지만 문서 응답 대기는 남아 있습니다. 테마 변경의 개선 효과를 확인한 뒤, 남은 지연 구간을 추가로 살펴볼 수 있습니다.

표의 숫자는 기록과 해석을 보여 주기 위한 예시이며, 특정 테마의 성능이나 합격선을 뜻하지 않습니다. web.dev의 LCP 기준에서 좋음은 2.5초 이하이며, 모바일과 데스크톱을 나눠 실제 방문의 75번째 백분위수로 평가합니다. 실험실에서 몇 번 측정한 중앙값만으로 실제 사용자 전체가 이 기준을 충족한다고 볼 수는 없습니다.

실제 비교 결과를 공개할 때는 테마 이름과 버전, 부모·자식 테마 사용 여부, 페이지 구성, 활성 플러그인과 캐시 조건까지 함께 적는 편이 낫습니다. 같은 테마 이름이라도 설정과 화면 구성이 다르면 내려받는 파일이 달라질 수 있기 때문입니다. 위 표는 그 기록 방법을 보여 주는 예시이고, 특정 테마의 실제 비교 자료는 아닙니다.

전송량은 줄었는데 LCP가 그대로인 경우

테마 파일을 줄였다고 첫 화면도 같은 만큼 빨라지는 것은 아닙니다. web.dev의 LCP 최적화 문서에는 이미지를 더 작게 만들어도, JS가 끝날 때까지 주요 요소를 숨겨 두는 페이지에서는 LCP가 개선되지 않는 설명용 사례가 있습니다. 다운로드가 일찍 끝난 만큼 화면 표시를 기다리는 시간이 길어지는 구조입니다.

그 구조를 숫자로 풀면 아래처럼 볼 수 있습니다. 시간은 공식 문서의 실측값이 아니라 이해를 돕기 위해 구성한 예시입니다. 두 조건에서 LCP 요소는 같은 첫 화면 이미지이고, 이미지를 표시하는 JS 작업은 페이지 로딩 시작 후 3.8초에 끝난다고 가정합니다.

이미지 전송량을 줄여도 LCP가 그대로인 구조(예시)

LCP를 나눈 구간	변경 전(예시)	변경 후(예시)
TTFB	0.8초	0.8초
이미지 요청 시작까지의 지연	0.4초	0.4초
이미지 다운로드 시간	1.2초	0.5초
다운로드 뒤 요소 렌더링 지연	1.4초	2.1초
LCP 합계	3.8초	3.8초

이 예시에서 이미지를 줄인 작업은 다운로드 시간을 줄였습니다. 다만 첫 화면이 나타나는 시점은 여전히 JS 작업에 묶여 있습니다. 그래서 다음에는 이미지를 다시 압축하기보다, 어느 코드나 표시 조건이 요소를 기다리게 하는지 봅니다. 그 코드가 테마에 속하면 테마 설정이나 교체 비교로 이어지고, 빌더·플러그인·외부 코드에 속하면 해당 쪽을 먼저 살펴볼 이유가 생깁니다.

테마의 전체 JS 전송량이 줄었을 때도 판단 방식은 같습니다. 줄어든 파일이 LCP와 관계없는 화면 아래 기능의 파일이라면, 전송량 감소만으로 첫 화면 개선을 기대하기 어렵습니다. 같은 LCP 요소의 요청과 표시 시점을 비교해야 파일을 줄인 효과와 남은 병목을 구분할 수 있습니다.

다음으로 볼 것은 지금 쓰는 테마의 공식 문서나 데모 페이지에 올라온 리소스 목록이 실제 쓰는 기능과 얼마나 차이 나는지입니다. 데모는 콘텐츠·플러그인·서버·캐시 조건이 다르므로, 데모가 빠르다는 사실만으로 내 사이트도 빨라진다고 보지는 않습니다. 공식 문서에서 기능별 로딩 설정을 찾고, 내 페이지의 요청 목록에서 실제로 달라지는지 확인하는 쪽이 낫습니다.

테마 비교 후 결과	다음 행동
테마 리소스와 LCP가 반복 측정에서 함께 줄고 필요한 기능도 유지됩니다.	테마 설정 변경이나 교체를 적용 후보로 삼습니다. 운영 사이트에 적용한 뒤에도 같은 URL을 다시 확인합니다.
빈 페이지는 빨라졌지만 실제 느린 글은 그대로입니다.	그 글의 주요 이미지·빌더·외부 삽입 요소를 봅니다. 빈 페이지 결과만으로 교체를 결정하지 않습니다.
전송량은 줄었지만 LCP는 거의 같습니다.	LCP 요소와 남은 지연 구간을 확인합니다. 이미지 요청도 개선됐다면 이미지 최적화 후 느릴 때 확인하는 방법에서 문서 응답과 화면 표시 지연을 나눠 볼 수 있습니다.
다른 테마에서도 TTFB가 길거나 결과가 크게 흔들립니다.	캐시 상태·서버 부하·네트워크 조건을 먼저 맞춥니다. 조건이 안정되기 전에는 테마 원인으로 결론 내리지 않습니다.

참고 문서와 수정 이력

측정과 해석의 근거는 본문의 해당 설명에 연결했습니다. 아래에는 실제 근거로 사용한 공식 문서만 모았습니다.

• 테마 변경과 비교: WordPress 공식 테마 안내, WordPress.com 공식 성능 점검 안내
• 전송량·요청·캐시 확인: Chrome 공식 Network 기능 문서, Network 사용 안내
• LCP 기준과 지연 구간: web.dev의 LCP 기준, LCP 최적화 문서
• 서버 안쪽의 보조 점검: Query Monitor 공식 안내, 프로파일링과 로깅 문서
• 교체 전 백업: WordPress 공식 백업 안내

이번 본문 보강일과 공식 문서 최종 확인일은 2026년 10월 10일입니다. 측정 단계별 소제목과 공통 주의사항, 파일·설정 비교 방법, 전송량 감소가 LCP 개선으로 이어지지 않는 예시를 추가하고 잘못된 참고 링크를 삭제했습니다. 원문 작성일은 제공된 본문에서 확인되지 않아 추정해 적지 않았습니다. 이 글에 운영 사이트의 직접 측정 결과는 포함하지 않았습니다.

• 사진 올릴수록 사이트 느려지는 이유, 원본 그대로 쓰고 있나요
• 이미지만 WebP로 바꿨는데 LCP가 달라지는 이유
• 구글색인이 외면하던 내 블로그가 살아난 비결
• TTFB가 나쁨으로 나오는 워드프레스, 꼭 고쳐야 할까