워드프레스 모바일 LCP 낮게 나올 때 캐시 설정 확인하는 법

워드프레스 사이트가 느려졌다는 이야기가 나오면 대부분 플러그인부터 지우거나 캐시 플러그인을 새로 깔아 봅니다. 그런데 PageSpeed Insights 모바일 리포트를 열어 보면 캐시를 켜 둔 상태에서도 LCP가 그대로 낮게 나오는 경우가 있습니다. 캐시 설정이 켜져 있는지부터 화면에서 어떻게 확인하고, 켜져 있는데도 숫자가 그대로일 때는 무엇을 더 봐야 하는지 짚어 보겠습니다.

먼저 결론부터 말씀드리면 순서는 세 단계입니다. 캐시 설정 화면에서 토글이 켜져 있는지 봅니다. 그다음 브라우저 응답 헤더나 페이지 소스로 캐시가 실제로 적용되는지 확인합니다. 마지막으로 적용이 맞는데도 LCP가 그대로라면 PSI에서 TTFB와 LCP 요소를 나눠 봅니다. 토글은 설정일 뿐이고 적용 여부는 따로 확인해야 해서, 이 글은 그 부분을 중심으로 풀었습니다.

새로고침으로 달라지지 않는 이유

사이트가 느려진 걸 처음 느끼면 인터넷 문제인가 싶어서 새로고침을 몇 번 해보게 되는데요, 워드프레스는 페이지가 열릴 때마다 PHP 코드를 실행해 데이터베이스에서 글과 설정 정보를 다시 조회하는 구조라 새로고침만으로는 달라지지 않습니다. 캐시는 이렇게 매번 새로 만들어지는 HTML 결과물을 미리 저장해 두었다가 다음 요청에 그대로 보여주는 방식입니다. 서버가 매 요청마다 같은 작업을 반복하지 않게 해 주는 구조라서, 캐시가 꺼져 있던 상태라면 새로고침을 반복해도 속도가 그대로였던 이유를 여기서 찾을 수 있습니다.

LCP 2.5초 기준부터 확인하기

PageSpeed Insights 모바일 리포트에서 LCP 항목을 보면 2.5초 이하는 양호 구간으로 표시되고 그 이상은 개선이 필요한 구간으로 나뉩니다. 이 기준은 구글이 Core Web Vitals의 하나로 정한 공식 구간값이라, 임의로 더 낮거나 높은 기준을 적용할 필요는 없습니다. 숫자가 2.5초를 살짝 넘는 수준인지, 4~5초대로 한참 벗어나 있는지에 따라 다음에 봐야 할 항목의 범위가 달라집니다. 리포트 화면 상단의 핵심 웹 지표 평가에서 LCP 칸의 색상과 숫자를 가장 먼저 눈으로 확인하는 편이 다음 단계를 좁히는 데 낫다고 봅니다.

web.dev의 LCP 문서는 방문자 페이지 로드의 75번째 백분위수 기준으로 2.5초 이하를 양호, 4.0초 초과를 나쁨으로 안내합니다. 그 사이는 개선 필요 구간입니다. 4초를 넘는다면 캐시 하나만의 문제가 아닐 가능성이 커서, 아래 단계를 끝까지 따라가 보시길 권합니다.

캐시 활성화 토글 확인

캐시 플러그인 설정 화면에 들어가면 캐시 활성화 토글이 켜짐 또는 꺼짐으로 표시됩니다. 이 토글이 꺼져 있다면 켜는 것만으로 LCP 숫자가 바뀔 수 있어서, 다른 작업보다 먼저 이 화면을 열어 보는 게 순서상 맞습니다. 토글을 켠 뒤에는 설정을 저장하고 캐시를 한 번 비워 둔 상태에서 PageSpeed Insights를 다시 돌려 숫자를 메모해 둡니다. 토글이 이미 켜져 있는 상태인데도 LCP가 그대로라면, 아래에서 설명하는 응답 헤더 확인까지 마친 뒤에 캐시 설정을 원인 목록에서 내려놓을 수 있습니다.

토글의 위치는 플러그인마다, 버전마다 조금씩 다릅니다. 예를 들어 LiteSpeed Cache는 관리자 메뉴의 LiteSpeed Cache > Cache 화면에 Enable Cache 옵션이 있고, 이 옵션을 끄면 기존 캐시도 함께 지워집니다(LiteSpeed 공식 문서). WP Rocket은 별도의 켜기 스위치 대신 설정 화면의 Cache 탭 옵션들로 동작하고, 호스팅이 자체 페이지 캐시를 쓰면 플러그인의 페이지 캐시가 자동으로 꺼지기도 합니다(WP Rocket 공식 문서). 토글이 켜져 있어도 이런 사정 때문에 실제 적용은 다를 수 있다는 점이 아래 확인 단계를 두는 이유입니다.

캐시가 실제로 적용되는지 확인

토글이 켜져 있다는 것과 방문자가 캐시된 페이지를 받는다는 것은 다른 이야기입니다. 그래서 저는 설정 화면 다음에 방문자 입장에서 한 번 더 확인해 보는 단계를 넣는 편이 안전하다고 봅니다. 로그인하지 않은 시크릿 창에서 확인해야 하는 이유는, 관리자로 로그인한 상태에서는 캐시를 건너뛰는 경우가 많아 결과가 달라지기 때문입니다.

1. 시크릿 창(로그인하지 않은 상태)에서 점검할 페이지를 엽니다.
2. F12로 개발자도구를 열고 Network 탭에서 페이지를 새로고침합니다.
3. 목록 맨 위의 HTML 문서 요청을 눌러 Response Headers를 봅니다.
4. 캐시 관련 헤더(x-litespeed-cache, cache-control, CDN이 붙이는 x-cache 계열 등)를 찾습니다.
5. 첫 요청에서 miss가 나오면 한 번 더 새로고침해 hit로 바뀌는지 봅니다.

LiteSpeed Cache를 쓴다면 x-litespeed-cache 헤더가 hit이면 캐시에서 내려준 것이고, miss면 이번에는 캐시에서 주지 않았다는 뜻입니다. 캐시를 막 비운 직후의 첫 요청은 miss가 정상이고, 다시 불러 hit가 되면 제대로 동작하는 것입니다. 헤더 자체가 없다면 해당 페이지가 LiteSpeed 캐시를 거치지 않는다는 신호입니다(LiteSpeed 문제 해결 문서).

헤더 이름은 플러그인이나 호스팅마다 다르기 때문에, WP Rocket처럼 헤더 대신 소스를 보는 방법도 알아 두면 좋습니다. 페이지 소스 맨 아래에 “Performance optimized by WP Rocket” 주석과 함께 Debug: cached@ 뒤에 숫자가 붙어 있으면 그 시각에 캐시 파일이 만들어진 것입니다. 주석은 있는데 숫자가 없다면 방금 첫 방문으로 캐시가 만들어지는 중이거나, 페이지 캐시가 꺼져 있거나, 호스팅이 자체 캐시를 쓰는 경우입니다. 한 번 더 새로고침해도 숫자가 없으면 그때부터 원인을 찾아야 합니다(WP Rocket 공식 문서).

시크릿 창에서도 계속 miss이거나 캐시 흔적이 없다면, 그 페이지가 캐시 제외 조건에 걸려 있을 가능성을 봅니다. LiteSpeed Cache 문서 기준으로 대표적인 조건은 아래와 같습니다. 다른 플러그인도 비슷한 제외 설정을 갖고 있지만 이름과 기본값은 다를 수 있습니다.

캐시가 적용되지 않는 조건	확인할 곳
제외 URI에 해당하는 페이지	Cache > Excludes의 Do Not Cache URIs
제외 쿼리스트링이 붙은 주소	Do Not Cache Query Strings
제외 쿠키가 있는 요청 (모든 페이지에 있는 쿠키를 넣으면 사이트 전체가 제외될 수 있음)	Do Not Cache Cookies
로그인 사용자 (기본은 개인별 비공개 캐시로 저장되어 방문자와 같은 캐시가 아님)	Cache 탭의 Cache Logged-in Users, Excludes의 Do Not Cache Roles
CDN 자체 캐시가 겹쳐 항상 miss로 보이는 경우	CDN 캐시 기능을 끄고 원본 서버를 직접 확인

장바구니나 결제처럼 사용자마다 내용이 달라지는 동적 페이지도 캐시에서 빠지는 경우가 많습니다. 점검하려는 URL이 이런 종류인지부터 확인해 두면 헛수고를 줄일 수 있습니다.

캐시는 켜졌는데 숫자가 그대로일 때: TTFB 비교

캐시가 필요한 이유는 결국 서버가 페이지를 매번 새로 조립하는 시간, 즉 서버 응답 시간(TTFB)을 줄이는 데 있습니다. 캐시 토글이 켜져 있어도 TTFB 자체가 느린 호스팅 환경이라면 LCP는 여전히 낮게 나올 수 있습니다. 워드프레스 LCP를 늦추는 대표 원인으로 미최적화 이미지, 렌더링 차단 리소스, 느린 서버 응답, LCP 이미지의 지연 로딩이 꼽히는데, 캐시를 켠 뒤에도 숫자가 그대로라면 이 가운데 TTFB 쪽을 먼저 들여다보는 편이 낫다고 봅니다. PageSpeed Insights 리포트의 진단 항목에서 서버 응답 시간 관련 항목의 숫자를 캐시 켜기 전후로 나란히 적어 두면 비교가 쉬워집니다.

진단 항목 이름은 PSI 언어와 시점에 따라 “초기 서버 응답 시간이 짧음”처럼 표시됩니다. 판단 기준으로는 web.dev가 TTFB 문서에서 0.8초 이하를 양호, 1.8초 초과를 나쁨으로 안내하는 값을 씁니다. 같은 문서는 0.8초를 대략적인 가이드로 설명하고, TTFB는 Core Web Vitals 지표가 아니라고 밝힙니다. 그러니 TTFB가 조금 높더라도 LCP가 양호하면 서두를 필요는 없습니다.

비교 결과는 아래처럼 정리해 두면 어느 쪽이 병목인지 한눈에 보입니다. 숫자는 이해를 돕기 위한 예시이고, 실제 값은 사이트마다 다릅니다.

상태 (예시)	TTFB	LCP	읽는 법
캐시 끔	1.9초	4.6초	서버 응답이 이미 느림
캐시 켬, 캐시 생성 후	0.5초	2.9초	TTFB가 줄면서 LCP도 함께 개선
캐시 켬, TTFB만 개선	0.5초	4.1초	서버는 정상, LCP 병목은 다른 곳

마지막 줄처럼 TTFB는 줄었는데 LCP가 그대로라면, 캐시는 제 역할을 했고 남은 시간이 다른 데서 쓰이고 있다는 뜻입니다. 이때는 PSI에서 Lighthouse 영역의 LCP 필터를 선택해 “Largest Contentful Paint element” 진단을 엽니다. 어떤 요소가 LCP인지와 시간이 어디에 쓰였는지 단계별로 나뉘어 나옵니다. web.dev의 LCP 최적화 문서는 LCP를 네 구간으로 나눠 보라고 안내합니다. 이 비율은 엄격한 규칙이 아니라 구간끼리 비교하는 용도의 가이드입니다.

구간	권장 비중	이 구간이 클 때 다음에 볼 것
TTFB	약 40%	캐시 적용 여부, 호스팅 응답 속도, CDN
리소스 로딩 지연	10% 미만	LCP 이미지에 지연 로딩이 걸려 있는지, 발견이 늦어지는 구조인지
리소스 로딩 시간	약 40%	이미지 실제 용량과 표시 크기 비교
요소 렌더링 지연	10% 미만	렌더링을 막는 CSS·JS 리소스

LCP 요소는 이미지일 수도 있고 큰 글자 블록일 수도 있습니다. web.dev는 img, video, url()로 불러온 배경 이미지, 글자가 든 블록 요소를 LCP 후보로 꼽습니다. 이미지가 병목으로 나오면 같은 사이트의 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에서 이어서 확인하실 수 있습니다.

모바일 LCP가 더 낮게 나오는 이유

데스크톱 리포트는 양호로 나오는데 모바일만 낮게 나오는 경우, 모바일 자체가 더 까다로운 측정 환경입니다. 모바일은 데스크톱보다 느린 네트워크와 제한된 처리 속도를 기준으로 측정되기 때문에, 같은 페이지라도 모바일 리포트의 숫자가 더 박하게 나오는 구조입니다. 개인적으로는 모바일 리포트에서 토글을 켠 전후 숫자를 먼저 적어 두고, 그 다음 TTFB 항목 숫자를 따로 적는 순서가 가장 헷갈리지 않는다고 봅니다.

PSI 도움말은 모바일 실험실 측정을 중간급 기기와 제한된 모바일 네트워크를 시뮬레이션한 환경이라고 설명합니다. 같은 페이지도 데스크톱보다 모바일에서 더 느리게 나오는 것이 자연스럽습니다. 같은 도움말은 실험실 데이터가 한 번의 시뮬레이션이라 페이지를 바꾸지 않아도 실행마다 숫자가 달라질 수 있다고도 안내합니다(PageSpeed Insights 도움말). 그래서 한 번의 숫자로 개선 여부를 단정하지 않는 편이 좋습니다.

캐시 토글이 켜져 있는지와 TTFB 숫자, 이 두 가지를 순서대로 눈으로 확인하는 것이 지금 할 수 있는 다음 행동입니다. 토글을 바꾸는 작업은 캐시를 비우기 전에 현재 설정값을 캡처해 두면 되돌릴 때 도움이 됩니다.

재측정할 때 지킬 조건

설정을 바꾼 뒤 숫자가 좋아졌는지는 조건을 맞춰야 판단할 수 있습니다. 조건이 달라지면 캐시 효과인지 측정 오차인지 구분이 안 되기 때문입니다.

1. 캐시를 비운 뒤 점검할 URL을 시크릿 창에서 한 번 열어 캐시를 먼저 만들어 둡니다. 캐시 생성 전 첫 요청은 miss라 TTFB가 길게 나올 수 있습니다.
2. 응답 헤더나 소스 주석으로 캐시 hit를 확인합니다.
3. 같은 URL을 모바일 탭에서 PSI로 3회 측정해 LCP와 TTFB의 중앙값을 적습니다.
4. 설정을 바꾸기 전과 후를 같은 방식으로 비교합니다. URL, 모바일 여부, 측정 횟수를 바꾸지 않습니다.
5. PSI 상단의 방문자 데이터(현장 데이터)는 최근 28일 평균이라 설정을 바꿔도 바로 달라지지 않습니다. 변화는 아래쪽 Lighthouse 실험실 데이터로 먼저 확인하고, 현장 데이터는 시간이 지난 뒤 봅니다.

참고한 자료 wikidocs.net How To Speed Up WordPress Site? Effective Tips & Tricks

기준값과 확인 방법은 공식 문서를 기준으로 정리했습니다. web.dev LCP, web.dev TTFB, web.dev LCP 최적화, PageSpeed Insights 도움말, LiteSpeed Cache 문제 해결, WP Rocket 캐시 확인. 이 문서들은 2026년 10월 11일에 확인했고, 플러그인 메뉴 이름과 기준값은 이후 바뀔 수 있습니다. 본문의 비교 표 수치는 예시입니다.

• 워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것
• 같은 워드프레스인데 휴대폰에서만 느리게 열리는 이유
• TTFB가 나쁨으로 나오는 워드프레스, 꼭 고쳐야 할까
• 워드프레스 속도, 도구마다 점수가 다른 이유
• 갑자기 느려진 워드프레스, 어디부터 손대야 할까