워드프레스 이미지 최적화 후 느릴 때 확인하는 방법
이미지 용량을 줄였는데도 워드프레스 사이트가 느리다면, 사진 파일 밖의 설정도 살펴봐야 합니다.
먼저 같은 URL에서 이미지 요청의 전송량과 소요 시간이 줄었는지 확인합니다. 이미지 요청은 개선됐는데 첫 화면이 여전히 늦다면, 문서 응답의 TTFB와 LCP를 나눠 보고 캐시·플러그인·서버 중 다음 점검 대상을 고릅니다.
이 글은 이미지 병목을 확인한 뒤 남은 원인을 구분하는 후속 점검입니다. 이미지 요청을 아직 확인하지 않았다면 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유에서 측정할 이미지부터 정합니다.
이미지를 줄였는데 왜 느릴까요?
이미지 파일이 작아져도 HTML 응답이 늦거나, 다운로드한 요소를 화면에 그리는 작업이 늦으면 LCP는 크게 달라지지 않을 수 있습니다. web.dev의 LCP 최적화 문서는 LCP를 TTFB, 리소스 로딩 지연, 리소스 로딩 시간, 요소 렌더링 지연으로 나눠 설명합니다. 따라서 파일 크기만으로 전체 지연의 원인을 판단하기는 어렵습니다.
같은 URL에서 세 가지를 먼저 측정합니다
- 느린 게시글 하나를 정해 PageSpeed Insights에서 분석합니다. 모바일·데스크톱 중 비교할 조건을 고정하고 LCP와 LCP 요소를 확인합니다. 보고서의 실제 사용자 데이터와 이번 실행의 실험실 결과는 따로 기록합니다.
- 로그아웃한 별도 브라우저 창에서 같은 URL을 엽니다. Chrome 개발자 도구 → Network에서 문서 요청을 선택하고 Timing의 Waiting for server response를 기록합니다. 이 대기 시간에는 네트워크 왕복과 서버의 응답 준비 시간이 함께 들어가므로 PHP 실행 시간으로 단정하지 않습니다.
- Network의 이미지 요청에서 실제 다운로드 URL, 상태 코드, 전송량, Timing을 확인합니다. WebP를 만들었더라도 기존 JPEG가 전달되거나 오류·재요청이 있다면 이미지 병목을 배제하지 않습니다.
- 변경 전후를 비교할 때는 같은 URL·브라우저·화면 크기·네트워크 제한·로그인 상태를 유지합니다. Network 측정에서는 Disable cache를 켜 브라우저 캐시의 영향을 줄입니다. 이 옵션은 서버나 CDN 캐시를 비우지 않습니다.
요청 선택과 Timing 확인 방법은 Chrome Network 공식 문서에서 확인할 수 있습니다. PageSpeed Insights와 로컬 브라우저는 측정 환경이 다르므로 서로의 수치를 직접 대조하지 않고, 각 도구 안에서 전후 결과를 비교합니다.
LCP의 좋음 기준은 2.5초 이하이고, TTFB의 권장 기준은 0.8초 이하입니다. 실제 사용자 평가는 방문의 75번째 백분위수를 기준으로 보며, 로컬 측정 한 번이 기준을 넘었다는 이유만으로 원인을 확정하지 않습니다. 지표 읽는 방법은 워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것으로 연결해 볼 수 있습니다.
| 측정 결과 | 먼저 확인할 곳 | 다음 행동 |
|---|---|---|
| 이미지 전송량·로딩 시간이 줄지 않았습니다. | 실제로 전달된 이미지 URL·형식·크기 | 이미지 적용 여부부터 다시 확인합니다. 캐시가 이전 이미지를 전달하는지도 살펴봅니다. |
| 이미지는 개선됐지만 문서 TTFB가 반복해서 높습니다. | 페이지 캐시 적중·제외 조건 | 아래 캐시 절을 확인합니다. 캐시 미적용 요청이 계속 느리면 플러그인·PHP·데이터베이스·호스팅으로 이동합니다. |
| TTFB는 비교적 짧지만 LCP가 늦습니다. | LCP 요소의 요청 시작과 렌더링 지연 | LCP 이미지의 지연 로딩과 테마·플러그인이 추가한 CSS·JavaScript를 확인합니다. |
| 로그인 상태나 특정 페이지에서만 느립니다. | 캐시 제외 규칙과 해당 페이지의 동적 기능 | 비로그인 공개 글과 별도로 측정합니다. 개인화 페이지를 강제로 공용 캐시하지 않습니다. |
| 특정 시간대에 여러 페이지가 함께 느립니다. | 호스팅 자원·오류 기록 | 느린 시각과 서버 지표를 대조하고 업체 문의 자료를 준비합니다. |
이미지 기능은 이름보다 실제 요청을 확인합니다
용량을 줄인 작업과 WebP 변환을 같은 작업으로 적지 않고, 실제로 적용한 항목만 남깁니다. WebP 적용 여부는 이미지 응답의 Content-Type과 실제 파일을 함께 확인합니다. 변환 기능을 사용했다는 사실만으로 모든 방문자에게 WebP가 전달된다고 전제하지 않습니다. 이 글은 특정 변환 제품의 설정 안내가 아니므로, 제품별 메뉴와 적용 조건은 사용 중인 기능의 공식 문서에서 확인합니다.
워드프레스의 반응형 이미지 기능은 생성한 이미지 마크업에 srcset과 sizes를 넣어 브라우저가 파일을 고를 수 있게 합니다. 해당 속성의 존재와 Network에 실제로 요청된 파일을 함께 확인합니다. 테마의 배경 이미지처럼 출력 방식이 다른 요소까지 자동으로 적용된다고 가정하지 않습니다.
지연 로딩은 화면 밖 이미지의 요청을 늦추는 데 쓰지만, 첫 화면의 LCP 이미지에 적용하면 표시가 늦어질 수 있습니다. 워드프레스 공식 이미지 성능 설명을 참고해 LCP 이미지의 loading 속성과 요청 시작 시점을 확인합니다. 플러그인이 별도로 지연 로딩을 적용한다면 그 제외 설정도 확인합니다.
여기서는 우선순위를 높이는 설정과 요청을 늦추는 설정이 겹치지 않는지도 봅니다. 워드프레스 6.3의 공식 설명은 같은 이미지에 fetchpriority=”high”와 loading=”lazy”를 함께 지정하지 않도록 안내합니다. 코어의 자동 판단이 있더라도 테마·플러그인이 출력한 최종 속성까지 같다고 전제할 수는 없습니다. LCP 이미지가 계속 늦게 요청된다면 우선순위 속성을 더 붙이기 전에 지연 로딩이 남아 있는지 살펴볼 이유가 됩니다.
같은 상단 이미지라도 CSS 배경 이미지라면 확인할 곳이 달라집니다. web.dev의 설명에 따르면 HTML의 이미지 주소는 브라우저가 일찍 발견할 수 있지만, 외부 CSS에 적힌 배경 이미지 주소는 해당 CSS를 처리한 뒤 발견될 수 있습니다. 이 경우 img 태그의 loading 속성을 바꾸는 해결책은 해당 배경 이미지에 적용되지 않습니다. preload는 실제로 쓰이는 파일을 미리 요청하도록 도울 수 있지만, 화면 크기별 파일과 맞지 않으면 불필요한 다운로드가 생길 수 있어 실제 요청 URL을 먼저 대조합니다.
이미지 다음은 캐시를 확인합니다
이미지 용량을 줄인 뒤에도 느리다면 캐시는 별도로 점검할 수 있는 항목입니다. 특히 문서 TTFB가 높을 때는 이미지 캐시와 HTML 페이지 캐시를 구분해야 합니다.
워드프레스 공식 성능 안내에서 설명하는 페이지 캐시는 만들어 둔 페이지를 재사용해 매 요청마다 페이지를 생성하는 부담을 줄입니다. CDN은 가까운 서버에서 응답을 제공할 수 있지만, 이미지가 CDN에 캐시됐다고 HTML도 캐시된 것은 아닙니다.
| 종류 | 적용 조건·한계 | 확인 방법 |
|---|---|---|
| 페이지 캐시 | 재사용 가능한 HTML에 적용합니다. 로그인·개인화 요청은 제품과 규칙에 따라 제외될 수 있습니다. | 문서 요청의 제품별 응답 헤더, 캐시 로그 또는 공식 적중 확인 방법을 봅니다. |
| CDN 캐시 | 해당 URL이 캐시 대상이어야 합니다. 정적 파일과 HTML의 적용 규칙은 다를 수 있습니다. | 이미지와 문서의 캐시 상태를 각각 확인합니다. |
| 브라우저 캐시 | 방문자 기기에 저장한 응답을 재사용합니다. 서버의 페이지 생성 문제를 직접 해결하지는 않습니다. | Network에서 memory cache·disk cache 표시와 Disable cache 조건을 확인합니다. |
확인 위치: 워드프레스 관리자에서 사용 중인 캐시 플러그인의 설정을 열거나 호스팅의 페이지 캐시 화면으로 이동합니다. 페이지 캐시 활성화, 제외 URL·쿠키·로그인 조건, 유효 기간과 삭제 기능을 확인합니다.
판단 기준: 비로그인 공개 글을 같은 조건으로 반복 요청하고 제품이 제공하는 HIT·MISS 등의 상태를 확인합니다. 첫 요청의 MISS만으로 고장을 판단하지 않습니다. 캐시 대상인데 계속 미적중한다면 제외 규칙·쿠키·응답 헤더를 확인합니다. Cache-Control만으로 실제 적중을 확정할 수는 없습니다.
다음 행동: 백업과 현재 설정 기록을 준비한 뒤 한 항목만 바꿉니다. 변경한 URL의 캐시를 제품 안내에 따라 갱신하고, 첫 요청과 캐시가 채워진 뒤의 요청을 나눠 측정합니다. 적중 후 TTFB가 줄었다면 페이지 생성 경로가 주요 점검 대상이 됩니다. 적중 상태에서도 계속 느리다면 CDN·네트워크·호스팅을 이어서 확인합니다.
여러 설정을 동시에 바꾸면 어느 변경과 느려진 화면이 겹치는지 따져보기 어렵습니다. 현재 상태를 먼저 기록하는 이유는 변경 효과를 비교하고 문제가 생겼을 때 복원하기 위해서입니다.
제품에 따라 캐시를 켜도 달라지지 않는 이유가 있습니다
캐시 플러그인이 활성화돼 있고 이미지도 최적화됐다면 HTML까지 캐시됐다고 생각하기 쉽습니다. 그런데 제품 문서를 함께 보면 기능의 작동 조건이 다릅니다. 아래는 실제 장애 기록이 아니라 공식 문서의 적용 조건을 비교한 표입니다. 설정을 반복해서 바꾸기 전에, 지금 켠 기능이 어느 응답을 재사용하는지 구분하는 데 쓰면 됩니다.
| 제품·적용 조건 | 개선이 남지 않을 수 있는 이유 | 다음 판단에 필요한 구분 |
|---|---|---|
| Cloudflare 기본 캐시. HTML 캐시를 별도로 구성하지 않은 경우입니다. | 기본적으로 HTML과 JSON은 캐시하지 않습니다. 이미지 HIT만으로 공개 글의 HTML도 CDN에서 재사용된다고 판단할 수 없습니다. | 문서가 DYNAMIC이면 먼저 HTML의 캐시 대상 여부를 봅니다. 이미지 캐시 삭제를 반복해도 HTML의 적용 조건은 달라지지 않습니다. |
| LiteSpeed Cache 플러그인. LiteSpeed 서버나 QUIC.cloud CDN 없이 사용하는 경우입니다. | 최적화 기능은 사용할 수 있지만 플러그인의 페이지 캐시 기능은 사용할 수 없습니다. 이미지 최적화가 작동했다는 사실이 페이지 캐시 작동의 근거가 되지 않습니다. | 호스팅의 별도 페이지 캐시가 있는지 구분합니다. 플러그인 설정만 바꾸기보다 캐시를 제공하는 서버·CDN 조건을 먼저 봅니다. |
| LiteSpeed 서버의 LSCache가 적용되는 공개 HTML 요청입니다. | 첫 요청의 miss와 캐시 준비 후 hit는 의미가 다릅니다. 의도적으로 제외된 페이지도 있어 모든 URL의 미적중을 같은 문제로 묶기 어렵습니다. | X-LiteSpeed-Cache의 miss·hit를 비교합니다. QUIC.cloud에서는 X-QC-Cache 등 다른 헤더가 쓰일 수 있어 사용 중인 경로의 확인 방법을 따릅니다. |
적용 조건은 Cloudflare 기본 캐시 문서와 LiteSpeed Cache 설치·적중 확인 문서를 바탕으로 정리했습니다. 두 제품을 함께 쓴다면 CF-Cache-Status와 LiteSpeed 계열 헤더는 서로 다른 캐시 계층을 설명합니다. CDN에서 재사용된 응답에 원본 서버의 헤더가 남아 있을 수도 있으므로, 그 헤더만 보고 이번 요청이 PHP까지 도달했다고 판단하지 않습니다.
플러그인과 테마도 남았습니다
이미지 최적화 뒤에도 느릴 때 플러그인과 테마는 각각 살펴볼 수 있는 대상입니다. 서버에서 실행하는 작업은 TTFB에, 페이지에 추가한 CSS·JavaScript는 요소가 그려지는 시점에 영향을 줄 수 있어 두 지표를 함께 봅니다.
확인 위치: 관리자 → 플러그인 → 설치한 플러그인에서 활성 항목을 확인합니다. 테마는 외모 → 테마에서 확인합니다. 최근 변경한 항목과 이미지 변환·지연 로딩·캐시 기능이 겹치는 항목을 우선 후보로 정합니다. 설치돼 있다는 이유만으로 원인으로 지목하지 않습니다.
판단 방법: 백업을 복원할 수 있는 테스트 환경에서 후보 플러그인 하나만 비활성화합니다. 캐시를 갱신하고 같은 URL을 같은 조건으로 다시 측정합니다. TTFB 또는 LCP가 반복해서 줄었는지, LCP 요소 자체가 바뀌지는 않았는지 확인합니다.
다음 행동: 후보를 다시 활성화해 원래 상태로 돌린 뒤 다음 후보를 테스트합니다. 개선이 재현되는 항목은 공식 문서에서 해당 기능의 제외 설정이나 호환 조건을 확인합니다. 테마 비교도 테스트 환경에서 별도로 진행하고, 글·이미지·기능이 빠진 결과를 그대로 성능 개선으로 판단하지 않습니다.
삭제부터 진행하지 않고 현재 상태와 달라진 항목을 살펴보면 다음 행동을 고르기 쉽습니다. 플러그인과 테마를 함께 바꿨다면 어느 변경이 관련됐는지 바로 가리기 어렵습니다.
PHP와 데이터베이스도 볼까요?
페이지 캐시가 적용되지 않는 요청에서는 워드프레스가 PHP를 실행하고 데이터베이스에서 필요한 내용을 가져옵니다. 이미지 파일을 줄였다는 사실만으로 이 과정의 지연까지 줄어드는 것은 아닙니다. 워드프레스 사이트 건강 공식 문서는 서버와 데이터베이스 정보를 확인할 화면을 안내합니다.
PHP 확인 위치: 관리자 → 도구 → 사이트 건강 → 정보 → 서버에서 PHP 버전, PHP 메모리 제한, 실행 시간 제한을 기록합니다. 상태 탭의 관련 경고도 함께 봅니다.
판단 기준: PHP 버전의 지원 상태와 테마·플러그인 호환성을 확인합니다. 버전 숫자만으로 병목을 확정하거나 메모리·실행 시간 제한을 일괄 상향하지 않습니다. 메모리 부족이나 시간 초과 오류가 있다면 발생 시각과 요청을 확인하고 호스팅의 PHP 오류 기록과 대조합니다.
다음 행동: PHP 변경이 필요하다면 테스트 환경에서 호환성과 동일 URL의 TTFB를 확인한 뒤 적용합니다. 호스팅의 PHP 변경·복원 방법도 미리 확보합니다.
데이터베이스 확인 위치: 사이트 건강 → 정보 → 데이터베이스에서 서버 버전 등 구성 정보를 확인합니다. 이 화면은 느린 쿼리의 소요 시간을 보여 주는 성능 보고서가 아닙니다. 실제 병목은 호스팅이 제공하는 느린 쿼리 로그나 APM의 데이터베이스 구간에서 확인합니다.
판단 기준과 다음 행동: 느린 요청에서 쿼리 소요 시간, 반복 호출, 잠금 대기가 관찰되는지 확인합니다. 전체 테이블 크기만 보고 불필요한 데이터를 삭제하지 않습니다. 관찰 자료가 없다면 느린 URL·시각·캐시 상태를 호스팅 업체에 전달하고 데이터베이스 지연 여부를 확인해 달라고 요청합니다.
이 단계에서 화면에 없는 수치나 원인을 짐작해 적을 필요는 없습니다.
끝에는 호스팅과 CDN입니다
이미지 용량을 줄이고 내부 설정을 살펴본 뒤에도 느리다면 호스팅도 점검 대상에 들어갑니다. 캐시 미적중 요청이 여러 페이지에서 함께 느려지거나 특정 시간대에 TTFB가 늘어난다면 서버 관찰 자료가 필요합니다.
호스팅 확인 위치: 관리 화면의 자원 사용량·모니터링·로그에서 CPU, 메모리, 디스크 I/O, PHP 작업자 사용량·대기열, 5xx 오류를 확인합니다. 제공되는 지표는 업체와 상품에 따라 다릅니다.
판단 기준: 느림을 재현한 시각 전후 15분을 우선 살피고, 가능하면 같은 시간대의 정상 구간과 비교합니다. 이 15분은 조사 범위를 정하기 위한 시작점입니다. 자원 그래프의 순간 상승만으로 원인을 확정하지 않고 요청 증가·오류·대기열이 함께 발생했는지 봅니다.
다음 행동: 업체 문의에는 URL, 측정 시각과 시간대, 로그인 여부, 문서 TTFB, 캐시 적중 상태, 관련 오류와 최근 변경 항목을 첨부합니다. 사이트 내부를 살핀 내용과 함께 두면 호스팅 업체에 문의할 때도 상황을 설명할 수 있습니다.
CDN 확인 위치: Chrome Network에서 이미지 요청과 문서 요청을 각각 선택하고 Headers의 응답 헤더와 Timing을 봅니다. CDN을 사용한다는 설정만 확인하지 말고 두 요청이 실제로 어떤 캐시 상태로 전달됐는지 구분합니다.
Cloudflare를 사용하는 경우 공식 캐시 응답 문서에 따라 CF-Cache-Status의 HIT·MISS·DYNAMIC·BYPASS를 해석할 수 있습니다. HIT는 캐시에서 제공됐다는 뜻이며, DYNAMIC이나 BYPASS를 곧바로 장애로 판단하지 않습니다. 다른 CDN의 헤더명과 상태값은 다를 수 있습니다.
다음 행동: 이미지가 HIT인데 HTML이 미적중한다면 이미지 CDN은 동작해도 페이지 생성 지연은 남을 수 있습니다. HTML이 원래 캐시 대상인지 먼저 확인합니다. 로그인 화면·장바구니·사용자별 내용처럼 개인화된 응답은 공용 HTML 캐시를 강제로 적용하지 않고 제품의 제외 규칙을 따릅니다.
문서와 이미지가 모두 HIT인데도 LCP가 늦다면
HIT는 캐시에서 응답을 제공했다는 뜻이지, 브라우저가 화면을 빨리 그렸다는 뜻은 아닙니다. Cloudflare의 캐시 상태 설명과 web.dev의 LCP 구간 설명을 함께 보면, 응답의 출처와 화면 표시 시점은 따로 판단해야 합니다.
관찰 예시: 같은 로컬 Performance 기록에서 문서와 LCP 이미지가 모두 HIT이고, 문서의 첫 바이트는 탐색 시작 후 0.4초에 도착했다고 가정합니다. 이미지 요청은 0.5초에 시작해 0.9초에 끝났는데 LCP는 3.1초에 기록될 수 있습니다. 이 수치는 직접 측정한 결과가 아니라 지연 구간을 설명하기 위한 가상 예시입니다. 이 경우 이미지 다운로드 완료 뒤 화면 표시까지 남은 2.2초를 먼저 살펴봅니다.
판단과 다음 행동: Performance 기록에서 이미지가 늦게 표시된 시점과 CSS·JavaScript 작업을 대조합니다. 이미지가 스크립트 실행 뒤에야 표시되는 구조라면 파일을 더 줄여도 LCP가 그대로일 수 있습니다. web.dev도 이런 경우를 설명합니다. 다만 시간 차이만으로 특정 플러그인을 원인으로 확정하지 않고, 테스트 환경에서 후보 기능 하나를 제외한 뒤 같은 이미지가 더 일찍 표시되는지 확인합니다.
이때 다운로드가 끝났다는 이유만으로 JavaScript를 원인으로 정하지는 않습니다. web.dev가 공개한 설명용 예시는 JavaScript가 끝날 때까지 LCP 요소를 숨겨 둔 구조에서 이미지 압축 효과가 렌더링 지연으로 옮겨갈 수 있음을 보여 줍니다. 같은 문서는 렌더링을 막는 CSS, 아직 화면 구조에 추가되지 않은 요소, 요소를 숨기는 코드, 메인 스레드의 긴 작업도 후보로 설명합니다. 어느 후보가 남는지에 따라 바꿀 설정이 달라집니다.
| 남은 후보 | 후보를 좁히는 관찰 | 원인 확인에 필요한 비교 |
|---|---|---|
| 이미지 발견·지연 로딩 | 이미지 요청이 일찍 시작해 완료됐다면 이 요청의 늦은 시작만으로 이후 지연을 설명하기 어렵습니다. | 요청이 늦게 시작된 경우에만 지연 로딩 제외나 이미지 발견 방식 변경 후 시작 시점이 당겨지는지 비교합니다. |
| 렌더링을 막는 CSS | 이미지는 완료됐지만 필요한 스타일시트가 아직 로딩 중인지 봅니다. CSS가 이미 준비됐다면 다른 후보가 남습니다. | 후보 CSS의 전달 방식을 바꾼 뒤 같은 화면이 유지되면서 표시가 빨라지는지 비교합니다. 스타일이 빠진 화면은 개선으로 인정하지 않습니다. |
| 요소를 숨기거나 늦게 추가하는 스크립트 | 이미지 파일이 준비돼도 요소가 숨겨져 있거나 화면 구조에 아직 없으면 표시될 수 없습니다. 요소가 보이는 시점과 스크립트 실행을 대조합니다. | 해당 표시 기능만 제외했을 때 같은 LCP 요소가 일찍 나타나고, 복원했을 때 지연이 다시 생기는지 봅니다. |
| 메인 스레드의 긴 작업 | 이미지와 스타일이 준비되고 요소도 표시 가능한 상태인데, 그리기 직전까지 긴 작업이 이어지는지 봅니다. | 해당 작업을 만드는 기능만 변경했을 때 작업 구간과 표시 지연이 함께 줄어드는지 비교합니다. 시간상 겹쳤다는 사실만으로 원인을 확정하지 않습니다. |
앞의 가상 예시에서는 이미지 요청 시작이 빠르므로 지연 로딩보다 다운로드 뒤의 표시 조건을 먼저 봅니다. 그러나 CSS 완료 시점과 요소의 표시 상태가 제시되지 않았으므로 최종 원인은 아직 정할 수 없습니다. 후보 기능을 제외한 결과와 복원한 결과가 같은 방향으로 반복돼야 원인 판단이 강해집니다. 이 구분을 남겨 두면 “HIT인데 느리다”는 기록이 캐시를 다시 켜라는 조언에서 끝나지 않습니다.
반대로 이미지 요청 자체가 늦게 시작됐다면 지연 로딩과 이미지 발견 시점을 먼저 확인합니다. HIT인데 문서의 첫 바이트부터 늦다면 네트워크와 CDN 응답 경로를 살펴봅니다. 같은 HIT라도 어디에서 시간이 남는지에 따라 다음 행동이 달라집니다.
한 항목을 바꾼 뒤 같은 조건으로 검증합니다
변경 전과 후에 각각 3회 측정하고 중앙값과 최솟값·최댓값을 기록합니다. 캐시가 비어 있는 첫 요청과 채워진 뒤의 요청, 로그인·비로그인 결과는 각각 분리합니다. 변경 후 한 번만 빨라졌거나 전후 범위가 크게 겹친다면 개선이 재현됐다고 단정하지 않습니다.
LCP는 같은 PageSpeed Insights 조건끼리, 문서 응답과 이미지 요청은 같은 Network 조건끼리 비교합니다. 화면 내용과 기능이 정상인지도 확인하고, 문제가 생겼거나 개선이 재현되지 않으면 해당 설정을 복원합니다. 실제 사용자 데이터는 여러 방문을 집계하므로 설정 직후의 검증값과 구분합니다.
변경 전후 기록표는 가상 예시입니다。 이미지 최적화를 이미 마친 공개 글 하나에서 서버의 페이지 캐시만 켜는 상황을 가정했습니다. 실제 사이트의 측정 결과나 제품별 예상 성능이 아닙니다. LCP 2.5초와 TTFB 0.8초라는 공식 기준을 참고해, 문서 응답은 개선됐지만 LCP는 여전히 늦은 결과를 읽는 방법을 보여 줍니다. Network의 문서 대기 시간은 탐색 전체의 TTFB와 측정 범위가 같지 않으므로 0.8초 기준과 직접 일치시키지 않습니다.
| 기록 항목 | 변경 전 (예시) | 변경 후 (예시) |
|---|---|---|
| URL·시각·측정 조건 | 동일한 공개 게시글 A. 설정 변경 직전 비로그인 상태에서 측정합니다. LCP는 PSI 모바일 실험실 결과, 요청은 로컬 Chrome Network에서 확인합니다. 로컬 화면은 390×844, 네트워크 제한 없음, Disable cache 켜짐으로 가정합니다. | 설정 변경과 캐시 준비 후 같은 게시글 A를 측정합니다. 도구·화면 크기·네트워크·로그인 조건은 동일하게 유지합니다. |
| 변경 항목·캐시 상태 | 서버 페이지 캐시 꺼짐. 제품별 확인 방법에서 문서는 캐시 미적용, 이미지 CDN은 HIT로 확인되는 상황입니다. | 서버 페이지 캐시만 켭니다. 대상 URL의 캐시를 갱신하고 준비 요청 후 문서 HIT 3회를 기록합니다. 이미지 CDN은 계속 HIT입니다. 준비 요청은 비교값에서 제외합니다. |
| LCP 3회·중앙값·범위 | 3.4 / 3.6 / 3.5초. 중앙값 3.5초, 범위 3.4~3.6초. LCP 요소는 글 상단 이미지입니다. | 3.3 / 3.5 / 3.4초. 중앙값 3.4초, 범위 3.3~3.5초. LCP 요소는 같은 글 상단 이미지입니다. |
| 문서 Waiting for server response 3회 | 1.10 / 1.20 / 1.15초. 중앙값 1.15초, 범위 1.10~1.20초. | 0.30 / 0.35 / 0.32초. 중앙값 0.32초, 범위 0.30~0.35초. |
| 대상 이미지의 전송량·요청 시간 | 글 상단의 동일한 WebP 파일. 각 요청의 전송량 180KB. 요청 시작부터 완료까지 0.42 / 0.46 / 0.44초, 중앙값 0.44초. | 같은 파일 URL·형식, 전송량 180KB. 요청 시작부터 완료까지 0.43 / 0.45 / 0.44초, 중앙값 0.44초. |
| 화면·기능과 최종 판단 | 글 본문·이미지·메뉴·댓글 폼을 비교 대상으로 정합니다. | 같은 화면과 기능이 정상이라고 가정합니다. 문서 대기 시간 감소는 반복되지만 LCP 범위는 겹칩니다. 페이지 캐시는 유지하고, 남은 요청 시작·렌더링 지연을 조사합니다. |
이미지 전송량과 다운로드 시간이 줄었는데 문서 TTFB가 유지됐다면, 이미지 최적화 효과와 남은 서버 응답 지연을 구분할 수 있습니다. 이때는 이미지 압축을 반복하기보다 페이지 캐시와 캐시 미적용 요청의 처리 시간을 확인합니다. 반대로 TTFB가 줄었는데 LCP가 유지됐다면 요청 시작이나 렌더링 지연을 이어서 살펴봅니다.
표의 예시에서는 페이지 캐시를 켠 뒤 문서 대기 시간의 중앙값이 1.15초에서 0.32초로 줄지만, 이미지 전송량은 그대로이고 LCP 범위는 겹칩니다. 따라서 문서 응답 개선과 LCP 개선을 같은 결과로 적지 않습니다. 또한 PSI와 로컬 Network는 별도 실행이므로, 두 중앙값의 차이를 빼서 렌더링 지연을 계산하지 않습니다. 남은 지연 구간은 앞의 HIT 예외처럼 한 번의 Performance 기록 안에서 확인합니다.
검증 범위: 이 글의 기준과 적용 조건은 공식 문서를 바탕으로 정리했습니다. 실제 운영 사이트의 전후 측정 기록은 포함하지 않았으며, 기록표와 HIT 예외의 수치는 판단 방법을 설명하는 가상 예시입니다. 특정 워드프레스·PHP 버전, 테마·플러그인, 호스팅·CDN 제품에서 이 결과가 재현됐다는 뜻은 아닙니다. 예시의 도구와 조건은 표에 적었으며, 실제 제품의 메뉴·캐시 제외 규칙·이미지 속성 처리 방식은 버전과 설정에 따라 다를 수 있습니다.
제품별 비교는 공식 문서에 명시된 기능 조건을 정리한 것이며, 해당 제품에서 직접 겪은 실패 사례는 아닙니다. HIT 이후의 후보 배제도 관찰 결과에 따라 적용할 해석입니다. 실제 원인 확인 기록과 구분해 두는 이유는 독자가 자기 사이트에서 어디까지 판단할 수 있는지 알 수 있도록 하기 위해서입니다.
공식 문서 최종 확인일: 2026년 10월 9일. web.dev의 LCP·TTFB 문서, 워드프레스의 반응형 이미지 문서, Cloudflare의 캐시 응답 문서를 확인했습니다. 이번 수정 내용: 미작성 기록표를 가상 예시로 바꾸고, 캐시 HIT 이후에도 남는 렌더링 지연의 판단 과정을 추가했습니다. 이미지 변환 제품을 특정하는 미작성 메모는 삭제했습니다. 이 날짜는 운영 사이트의 성능 측정일이 아니라 문서 확인일입니다.
추가 보강: Cloudflare 기본 캐시와 LiteSpeed Cache의 적용 조건, 워드프레스 이미지 속성의 충돌 조건, web.dev가 설명하는 렌더링 지연 후보를 연결했습니다. 캐시 활성화가 효과를 내기 어려운 환경과 이미지 요청이 끝난 뒤에도 남는 지연을 구분할 수 있도록 보충했습니다.
측정 단계에 맞춰 이어서 읽습니다
- 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유: 이미지 요청의 지연을 확인하고 이미지 병목을 배제할 수 있는지 판단합니다.
- 워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것: LCP와 TTFB를 구분해 이 글의 분기표에 사용할 측정 결과를 준비합니다.
- 이미지 요청 개선을 확인했는데 TTFB가 높다면, 이 글의 ‘이미지 다음은 캐시를 확인합니다’ 절에서 문서 캐시 적중과 제외 조건을 점검합니다.
아래 기존 관련 링크도 유지합니다. ads.txt 글은 광고 파일 오류 확인용이고, 속도 개선 글은 추가 최적화 검토용이며, NAS 구축 글은 해당 서버 환경을 운영할 때 참고합니다. 이번 이미지 이후 진단은 위 측정 순서와 본문의 캐시 절부터 진행합니다.
One Comment
Pingback: