워드프레스 사이트 느릴 때 이미지를 살펴보는 이유
사이트가 느려지면 캐시 설정부터 바꾸기 쉽지만, 이미지 요청을 먼저 보면 파일이 큰지, 화면 밖 사진까지 미리 불러오는지, 첫 화면 주요 이미지의 요청이 늦는지 나눠 볼 수 있습니다. 새로고침만으로는 어느 이미지에서 지체되는지 알기 어렵습니다.
블로그나 작은 쇼핑몰을 직접 운영한다면 이미지를 왜 살펴봐야 하고, 그 속도는 어디서 봐야 할까요?⠀
새로고침해도 이미지 속도는 안 보입니다⠀
플러그인을 줄이거나 캐시 설정을 바꾸라는 조언도 보이지만, 지금 어떤 이미지가 느린지는 그 조언만으로 알 수 없습니다.⠀
이미지를 살펴보는 이유는 설정을 바꾸기 전에 로딩 상태를 측정해 지연 로딩의 필요성을 따져볼 수 있기 때문입니다.⠀
여기서 이미지 로딩 속도는 숫자 하나를 뜻하지 않습니다. 실제로 내려받은 전송량은 KB나 MB로, 요청이 시작된 시점과 요청에 걸린 시간은 ms나 초로 봅니다. 첫 화면의 가장 큰 이미지나 글자가 그려진 시점은 LCP로 따로 봅니다. 파일을 빨리 내려받았어도 화면에 늦게 나타날 수 있으므로 이 값을 나눠 읽어야 합니다. web.dev의 LCP 최적화 문서도 요청 시작까지의 지연, 리소스 로딩 시간, 화면에 그리기까지의 지연을 구분합니다.
전체 사이트가 느린지, 사진이 들어간 페이지에서 특히 느리게 느껴지는지 방문자가 열 페이지를 직접 골라 봅니다.⠀
사이트 첫 화면과 사진이 있는 글 가운데, 지금 느리다고 느낀 페이지의 주소를 먼저 적어 둡니다.⠀
측정 조건도 이때 함께 정해 둡니다. 변경 전후에는 같은 URL과 같은 도구를 쓰고, 모바일·데스크톱 구분, 브라우저, 화면 크기, 네트워크 조건을 맞춥니다. GTmetrix에서는 결과에 표시된 측정 지역과 연결 속도도 기록합니다. 선택할 수 있는 설정은 계정과 서비스 버전에 따라 다를 수 있습니다.
관리자 로그인 여부와 캐시 상태도 맞춰야 합니다. 방문자 화면을 기준으로 보고, 페이지 캐시·CDN 캐시를 비웠다면 변경 전후 모두 같은 순서로 비우고 준비한 뒤 측정합니다. 브라우저 캐시를 끈 측정과 캐시에 남은 이미지를 다시 읽은 측정을 섞으면 전송량과 시간이 달라집니다. 각 조건에서 3회 정도 측정해 중앙값을 남기면 한 번의 흔들림을 줄일 수 있습니다.
사진 개수와 원본 크기를 먼저 정리해야 한다면 사진 많은 워드프레스 속도 개선하는 방법을 함께 볼 수 있습니다. 여기서는 선택한 페이지에서 실제로 어떤 이미지가 언제 요청되는지에 초점을 맞춥니다.
페이지스피드 화면에서 속도를 봅니다⠀
구글이 제공하는 웹페이지 성능 측정 도구인 PageSpeed Insights에서 선택한 페이지의 성능과 이미지 관련 진단을 살펴봅니다.
분석 결과에서 모바일 또는 데스크톱을 고른 뒤, 아래쪽의 성능 문제 진단과 인사이트를 봅니다. LCP 요소 또는 LCP 분석에 해당하는 항목을 펼쳐 첫 화면의 가장 큰 요소가 이미지인지부터 살펴봅니다. 표시 이름은 도구 버전과 언어에 따라 다를 수 있습니다. LCP 요소가 제목 같은 글자라면 그 수치를 곧바로 이미지 로딩 시간으로 읽지는 않습니다.
위쪽의 실제 사용자 데이터와 아래쪽의 실험실 측정도 구분합니다. 실제 사용자 데이터는 최근 28일의 방문 경험을 모은 값이며, 데이터가 부족하면 해당 URL 대신 사이트 전체 데이터가 표시되거나 결과가 없을 수 있습니다. 설정을 바꾼 직후의 비교에는 아래쪽 실험실 결과를 쓰고, 장기적인 변화는 실제 사용자 데이터로 다시 봅니다. 구분 방법은 PageSpeed Insights 공식 안내에서 확인할 수 있습니다.
두 도구에서 볼 위치와 다음 행동은 아래처럼 나눠 두면 덜 헷갈립니다. 이미지 하나의 용량에 모든 사이트가 따라야 할 기준이 있는 것은 아니므로, 표시 크기와 전송량, 요청 시점을 함께 봅니다.
| 도구와 확인 위치 | 기록할 값 | 결과 해석과 다음 행동 |
|---|---|---|
| PageSpeed Insights → 실험실 성능 결과 → LCP 요소·LCP 분석에 해당하는 항목 | LCP(초), 요소가 이미지인지 글자인지, 이미지 URL, 표시되는 요청 지연·로딩 시간(ms) | 이미지 요청 시작까지의 지연이 크면 지연 로딩 적용 여부와 이미지 발견 시점을 봅니다. 로딩 시간이 길면 전송량과 응답 대기를 나눠 봅니다. |
| PageSpeed Insights → 이미지 전달 개선에 해당하는 인사이트 | 이미지 URL, 예상 절감량(KiB), 표시 크기와 이미지 크기 관련 안내 | 예상 절감량은 실제 개선 결과가 아닙니다. 화면보다 지나치게 큰 파일을 받는다면 이미지 크기 선택과 압축을 먼저 검토합니다. |
| GTmetrix → 결과의 Waterfall | 실제 이미지 URL, 전송량(B·KB), 요청 시작 시점(ms), 전체 요청 시간(ms), Waiting·Receiving 등 구간 | Receiving이 길고 전송량도 크면 크기·압축을 봅니다. Waiting이 길면 서버·CDN 응답을 봅니다. 첫 화면 주요 이미지의 막대가 늦게 시작하면 요청 지연을 봅니다. |
| 브라우저 개발자 도구 → Elements와 Network의 이미지 요청 | 화면 안팎 위치, loading 속성, 실제 요청 URL, 스크롤 전후 요청 여부 | 멀리 아래에 있는 이미지가 처음부터 요청되고 지연 로딩도 없다면 적용을 검토합니다. 첫 화면 주요 이미지에 lazy가 붙었다면 제외를 검토합니다. |
그 숫자 하나만 보고 느려진 원인을 이미지로 확정하지는 말고, 어느 페이지를 쟀는지 함께 남깁니다.⠀
LCP는 이미지 한 장의 다운로드 시간과 다릅니다. web.dev는 LCP 개선 목표로 2.5초 이하를 안내하지만, 한 번의 실험실 결과만으로 방문자 전체의 상태를 확정할 수는 없습니다. 점수보다 어떤 이미지가 LCP 요소였고 어느 구간이 길었는지가 다음 행동을 고르는 데 더 도움이 됩니다.
다른 도구에서도 이미지를 봅니다⠀
GTmetrix는 웹페이지 성능을 측정하는 도구이며, 여기에서도 이미지 로딩 속도를 살펴볼 수 있습니다.⠀
PageSpeed Insights는 첫 화면에서 중요한 요소와 개선 후보를 찾는 데 쓰고, GTmetrix는 그 이미지의 개별 요청을 따라가는 데 씁니다. 같은 페이지를 넣어도 측정 지역과 기기·네트워크 조건이 다를 수 있으므로 두 도구의 점수나 LCP 차이를 변경 효과로 계산하지는 않습니다.
GTmetrix 결과에서 Waterfall을 열고 이미지 요청을 찾습니다. 이미지 필터가 있으면 사용하고, 없으면 파일 이름과 응답의 Content-Type으로 구분합니다. 확장자가 없는 이미지 URL도 있으므로 jpg나 png라는 이름만으로 찾지는 않습니다.
- 이미지 요청의 파일 이름에 마우스를 올리거나 상세 내용을 열어 전체 URL을 읽습니다. PageSpeed Insights에서 찾은 이미지와 같은 파일인지 살펴봅니다.
- 크기 열과 상세 정보에서 실제 전송량을 기록합니다. 압축 전 리소스 크기와 전송량이 따로 표시되면 구분해서 적습니다.
- 시간 막대의 시작 위치와 전체 길이를 봅니다. 시작 위치는 페이지 측정 시작 후 언제 요청했는지, 길이는 해당 요청에 얼마나 걸렸는지를 보여 줍니다.
- 막대의 상세 구간을 봅니다. Waiting은 응답을 기다리는 구간이고 Receiving은 데이터를 받는 구간입니다. 대기 시간이 긴 요청을 파일 압축만으로 해결하려고 하면 원인을 놓칠 수 있습니다.
읽는 방법은 GTmetrix 공식 워터폴 안내를 참고할 수 있습니다. 반응형 이미지에서는 브라우저가 원본 대신 다른 크기의 파일을 고를 수 있으므로, 미디어 라이브러리의 원본 URL보다 워터폴에 실제로 나온 URL을 기준으로 삼습니다.
서로 다른 화면의 항목을 같은 값으로 취급하지 않고, 어느 도구에서 본 결과인지 붙여 둡니다.⠀
새 플러그인을 고르기 전에 지금 쓰는 페이지의 이미지가 어떻게 로딩되는지 보는 데 이 결과를 씁니다.⠀
워드프레스에 이미 기능이 있습니다⠀
워드프레스에는 5.5 버전부터 이미지 지연 로딩 기능이 기본으로 탑재되었습니다. 워드프레스 공식 도입 문서에서 확인할 수 있습니다.
이미지 때문에 느리다고 생각해 지연 로딩 플러그인을 찾았다면, 현재 사이트의 워드프레스 버전부터 살펴볼 만합니다.⠀
5.5 이상을 쓰는 사이트라면 지연 로딩 기능이 아예 없는 상태라고 가정하고 설정을 더하는 판단은 서두를 필요가 없습니다.⠀
관리자 화면의 알림판 → 업데이트에서 현재 버전을 읽고, 앞서 측정한 페이지의 이미지 로딩 상태와 함께 놓아 봅니다. 화면 구성과 권한에 따라 표시 위치는 다를 수 있습니다.
기본 기능이 있다는 사실과 지금 측정한 페이지에서 이미지가 빠르게 로딩된다는 결과는 서로 다른 이야기입니다.⠀
버전은 기능이 도입된 시점을 알려 줄 뿐, 개별 이미지의 적용 여부까지 알려 주지는 않습니다. 테마와 플러그인, 이미지가 출력되는 방식에 따라 달라질 수 있으므로 방문자 화면에서 실제 태그를 봅니다.
- 방문자 페이지에서 점검할 이미지를 마우스 오른쪽 버튼으로 누르고 검사를 엽니다. 개발자 도구의 Elements에서 해당 img 요소를 찾습니다.
- loading=”lazy”가 있으면 브라우저 기본 지연 로딩을 요청한 상태입니다. loading=”eager”이거나 속성이 없으면 이 속성에 의한 지연 로딩은 요청하지 않은 상태입니다. 다만 플러그인이 별도 스크립트로 처리할 수 있어 속성만으로 결론을 내리지는 않습니다.
- Network에서 이미지 요청만 보이도록 고르고, 브라우저 캐시를 끈 뒤 페이지를 다시 엽니다. 스크롤하지 않은 상태와 해당 사진 가까이 내려간 상태에서 요청이 언제 생기는지 봅니다. 실제 요청 URL도 함께 읽습니다.
지연 로딩은 파일 자체를 줄이는 기능이 아니라, 화면에서 멀리 떨어진 이미지의 요청을 뒤로 미루는 기능입니다. 화면에 가까운 사진은 스크롤 전에 요청될 수 있습니다. 따라서 화면 밖 이미지가 한 장 보인다는 이유만으로 실패라고 판단하지 않고, 아래쪽 사진의 위치와 요청 시점을 함께 봅니다. 이 동작과 첫 화면 이미지의 예외는 web.dev의 브라우저 이미지 지연 로딩 문서에 설명되어 있습니다.
검사한 요소가 img가 아니라 CSS의 background-image라면 loading 속성으로 판단할 수 없습니다. 배경 이미지와 스크립트로 나중에 넣는 이미지는 테마나 페이지 빌더의 출력 방식을 따로 살펴봐야 합니다. 반대로 화면 아래 사진에 이미 lazy가 있고 요청도 적절히 미뤄진다면 같은 목적의 기능을 더할 이유는 줄어듭니다.
현재 버전을 모른 채 플러그인부터 설치하면 이미 있는 기능을 살펴볼 기회를 놓칠 수 있습니다.⠀
지연 로딩은 측정값을 보고 고릅니다⠀
지연 로딩을 더 손볼지 판단할 때는 선택한 페이지에서 측정한 이미지 로딩 속도를 다시 봅니다.⠀
워드프레스 5.5부터 기본 기능이 있다는 사실만으로 지금 페이지의 로딩 상태까지 알 수는 없습니다.⠀
제가 고를 행동은 새 설정을 더하기 전에 같은 페이지의 이미지 측정 결과를 다시 읽는 것입니다.⠀
이때 바꿀 대상은 결과에 따라 달라집니다. 이미지가 느리다는 말만으로 모든 사진에 지연 로딩을 켜면 첫 화면에서 필요한 사진까지 늦출 수 있습니다.
- 전송량이 크고 데이터를 받는 구간이 길다면 파일 크기를 먼저 봅니다. 글 편집기의 이미지 블록에 크기 선택이 있다면 원본 대신 표시 폭에 맞는 크기로 사진 한 장만 바꿔 봅니다. 화면 구성은 편집기와 테마에 따라 다를 수 있습니다. 고해상도 화면의 선명도도 살피고, 변경 뒤 실제 요청 파일과 전송량이 줄었는지 봅니다.
- 화면에서 멀리 아래에 있는 사진들이 처음부터 요청되고 지연 로딩도 없다면, 현재 테마나 최적화 플러그인의 이미지 지연 로딩 설정을 검토합니다. 첫 화면 사진은 제외하고 아래쪽 사진의 요청이 미뤄지는지 봅니다. 이미 적용된 기능이 잘 작동한다면 추가 설정은 필요하지 않을 수 있습니다.
- 첫 화면의 LCP 이미지에 loading=”lazy”가 붙고 요청 시작도 늦다면, 그 이미지 한 장을 지연 로딩 제외 대상으로 고릅니다. 해당 기능의 제외 목록에 이미지 URL이나 클래스를 지정할 수 있는지는 사용하는 도구에 따라 다릅니다. 제외 뒤 요청 시작이 빨라지고 LCP도 줄었는지 봅니다.
첫 화면 이미지를 제외했는데도 요청이 늦다면 지연 로딩만의 문제는 아닐 수 있습니다. 이미지를 스크립트가 뒤늦게 추가하거나 CSS 배경으로 불러오는 경우에는 브라우저가 파일을 발견하는 시점도 늦어집니다. 이런 경우에는 테마의 이미지 출력 방식부터 봅니다. 첫 화면 주요 이미지를 지연 로딩하지 말아야 하는 이유는 web.dev의 LCP 최적화 문서에서도 확인할 수 있습니다.
이미지 로딩 속도가 신경 쓰인다면 위 조건에 맞는 설정 하나를 고르고, 백업해 둔 뒤 변경해 같은 페이지를 다시 측정합니다.
기록은 아래처럼 변경 대상과 그 대상에 맞는 값을 묶어 두면 됩니다. 다음 표는 첫 화면 이미지 한 장을 지연 로딩에서 제외했다고 가정한 설명용 예시이며, 이 사이트에서 직접 측정한 결과는 아닙니다. 숫자는 성공 기준이나 보장되는 개선 폭이 아닙니다.
| 기록 항목 | 변경 전(예시) | 변경 후(예시) |
|---|---|---|
| 대상과 변경 내용 | /sample-post/의 첫 화면 이미지 /uploads/hero.webp, loading=”lazy” | 같은 이미지 한 장만 지연 로딩 제외 |
| 측정 환경 | GTmetrix, 데스크톱 Chrome, 런던, Broadband, 비로그인 | 동일 조건 |
| 캐시 조건 | 페이지·CDN 캐시 갱신 후 준비, 브라우저 캐시 없는 측정 | 동일 순서로 준비 |
| 이미지 전송량 | 180KB | 180KB |
| 이미지 요청 시작 시점 | 측정 시작 후 1,200ms | 측정 시작 후 700ms |
| 이미지 전체 요청 시간 | 400ms | 390ms |
| LCP, 각 3회 측정 중앙값 | 3.2초 | 2.7초 |
이 예시에서는 용량이 그대로여도 요청이 먼저 시작되면서 LCP가 줄었습니다. 파일을 바꾼 경우에는 전송량과 받는 시간을, 아래쪽 사진에 지연 로딩을 적용한 경우에는 스크롤 전 요청 수와 전송량을 먼저 비교합니다. 아래쪽 사진이 스크롤할 때 정상적으로 나타나는지도 봅니다. 점수 하나보다 바꾸려던 구간이 여러 번의 측정에서 일관되게 개선됐는지가 판단 기준입니다.
실제 기록을 공개할 때는 측정일과 워드프레스 버전, 사용한 테마·최적화 플러그인도 함께 적으면 어떤 조건에서 나온 결과인지 알 수 있습니다. 위 예시 표에는 운영자의 실제 환경이나 측정일을 넣지 않았습니다.
사이트가 느릴 때 이미지를 살펴보는 이유는 측정한 이미지 로딩 속도로 지연 로딩의 필요성을 가늠할 수 있기 때문입니다.⠀
다만 파일이 큰 문제와 요청이 늦는 문제는 고를 행동이 다릅니다. 이미지 요청의 전송량과 시간이 개선됐는데도 첫 화면이 여전히 느리다면 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에서 문서 응답과 화면에 그리는 지연을 이어서 살펴볼 수 있습니다.
현재 워드프레스 버전을 읽고, 느리게 느껴지는 페이지의 이미지 로딩 속도를 측정해 보시기 바랍니다.⠀
14 Comments
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback:
Pingback: