
이 글의 링크는 추후 제휴 링크로 바뀔 수 있으며, 그 경우 구매 시 수수료를 받을 수 있습니다.
이 글에서 다루는 것
블로그 이미지의 용량을 줄여 페이지를 빠르게 만드는 방법을, 크기 줄이기와 WebP 변환과 지연 로딩 순서로 정리합니다.
글에 사진을 여러 장 넣는데 모바일에서 화면이 늦게 채워진다고 느끼는 분을 위한 글입니다.
읽고 나면 지금 느린 원인이 이미지인지 서버인지 먼저 가른 다음, 어느 작업부터 손대야 효과가 큰지 정해집니다.
결론부터: 순서가 효과를 결정합니다
이미지 때문에 느린 블로그에서 가장 흔한 실수는 변환 플러그인부터 까는 것입니다.
원본이 4000픽셀짜리 사진이면 WebP로 바꿔도 여전히 큽니다.
줄일 것을 먼저 줄이고 형식을 바꾸는 편이 순서가 맞습니다.
작업은 세 개뿐입니다.
올리기 전에 긴 변의 픽셀을 줄인다, 형식을 WebP로 바꾼다, 화면 밖 이미지는 나중에 받게 한다.
이 셋을 이 순서대로 하면 대부분의 블로그에서 본문 이미지 전송량이 눈에 띄게 내려갑니다.
반대로 이 셋을 다 했는데도 체감이 그대로라면 원인이 이미지가 아닙니다.
그 경우는 글 뒤쪽에서 따로 다룹니다.
0단계: 원인이 이미지인지 먼저 가릅니다
손대기 전에 측정부터 합니다.
구글 페이지스피드 인사이트에 블로그 주소를 넣고 분석을 누르면, 실제 방문자에게서 수집된 측정값이 먼저 나옵니다.
휴대전화 탭을 기준으로 보십시오.

페이지스피드 인사이트 결과 화면, ① 최대 콘텐츠 표시 시간 ② 첫 응답 시간 (2026-10-03 확인)
① 최대 콘텐츠 표시 시간(LCP)은 화면에서 가장 큰 요소가 다 그려질 때까지 걸린 시간입니다.
② 첫 응답 시간(TTFB)은 서버가 첫 바이트를 돌려주기까지 걸린 시간입니다.
이 두 칸을 같이 보면 원인이 갈립니다.
①이 큰데 ②가 작으면 서버는 제때 답했는데 그리는 데 오래 걸린 것이므로 이미지 쪽일 가능성이 큽니다.
②부터 이미 크면 이미지를 아무리 줄여도 체감이 크게 달라지지 않습니다.
위 화면은 설명을 위해 공개된 사이트 하나를 분석한 결과입니다(2026년 10월 3일, 휴대전화 기준, 최근 28일 실사용자 데이터).
숫자 자체보다 어느 칸을 보는지를 봐 두시면 됩니다.
1단계: 올리기 전에 긴 변부터 줄입니다
가장 효과가 크고 가장 쉬운 작업입니다.
요즘 휴대전화 사진은 긴 변이 4000픽셀을 넘지만, 블로그 본문이 실제로 보여 주는 폭은 보통 1000픽셀 안쪽입니다.
남는 픽셀은 전부 전송만 되고 버려집니다.
기준은 단순하게 잡으십시오.
본문 사진은 긴 변 1200픽셀, 전체 폭을 꽉 채우는 대표 이미지만 1600픽셀 정도면 충분합니다.
화면 캡처처럼 글자가 들어간 그림은 숫자를 조금 더 주되, 줄인 뒤 글자가 읽히는지 한 번 확인하면 됩니다.
워드프레스 공식 성능 문서도 이미지 항목에서 같은 이야기를 먼저 합니다.

워드프레스 공식 성능 문서의 이미지 항목, ① WebP를 권하는 줄 (2026-10-03 확인)
같은 목록의 윗줄은 더 근본적인 질문을 던집니다.
꼭 필요하지 않은 이미지가 있는지, 글로 대신할 수 있는 그림은 없는지 먼저 보라는 것입니다.
장식용으로 넣은 사진 한 장을 빼는 것이 그 사진을 압축하는 것보다 항상 더 빠릅니다.
2단계: 형식을 WebP로 바꿉니다
①이 가리키는 줄이 WebP 권고입니다.
같은 화질에서 파일이 더 작은 형식이니 고려하라는 내용이고, 공식 문서에 들어 있는 권고입니다.
여기서 많이 헷갈리는 지점이 하나 있습니다.
'WebP로 바꾸는 일'과 'WebP로 보내 주는 일'은 다른 작업입니다.
플러그인 설명도 이 둘을 따로 적어 둡니다.

워드프레스 공식 플러그인 저장소의 WebP 관련 설명, ① 변환 기능 ② 브라우저별 제공 기능 (2026-10-03 확인)
① 변환은 올라와 있는 jpg와 png를 WebP 파일로 만들어 두는 일입니다.
② 제공은 방문자의 브라우저가 WebP를 지원하면 WebP를, 아니면 원래 파일을 돌려주는 일입니다.
변환만 해 두고 제공 설정을 켜지 않으면 용량은 그대로 나갑니다.
같은 화면의 설명은 열에 아홉이 넘는 방문자가 이미 WebP를 볼 수 있는 브라우저를 쓰는데도 대부분의 사이트가 여전히 jpeg를 내보내고 있고, 같은 화질 기준으로 jpeg가 보통 두 배쯤 크다고 적습니다.
바꿔 말하면 설정 한 번으로 줄일 수 있는 폭이 그만큼 남아 있다는 뜻입니다.

같은 저장소의 다른 이미지 최적화 플러그인 설명, ① WebP 항목 (2026-10-03 확인)
① 항목처럼, 올려 둔 이미지를 한꺼번에 WebP 버전으로 만들어 두고 지원하는 브라우저에만 보내는 방식이 일반적입니다.
바로 아래에는 AVIF 항목이 따로 있습니다.
WebP 다음 형식도 이미 선택지에 있다는 뜻이지만, 지금 당장은 WebP까지만 해도 충분합니다.
티스토리나 네이버 블로그처럼 서버를 직접 만지지 않는 곳이라면 플러그인을 쓸 수 없습니다.
그 경우에는 올리기 전에 WebP로 저장해서 올리는 방법이 남습니다.
1단계의 크기 줄이기와 같은 작업 안에서 한 번에 처리하면 품이 거의 늘지 않습니다.
3단계: 화면 밖 이미지는 나중에 받게 합니다
지연 로딩은 방문자가 아직 스크롤하지 않은 아래쪽 이미지를 먼저 받지 않는 기능입니다.
사진이 열 장 들어간 글에서 첫 화면에 필요한 것은 한두 장이니, 나머지를 미뤄 두면 첫 화면이 채워지는 시간이 짧아집니다.
워드프레스는 이 처리를 코어에서 직접 합니다.
코어 팀이 올린 공지에 어디까지 자동인지가 정리돼 있습니다.

워드프레스 코어 팀의 이미지 성능 공지, ① 변경 요약 (2026-10-03 확인)
① 아래 목록의 요지는 두 가지입니다.
화면에서 가장 큰 이미지로 판단된 것에는 우선순위를 높이는 속성을 자동으로 붙이고, 그 덕에 최대 콘텐츠 표시 시간이 보통 5에서 10퍼센트 줄어든다는 것입니다.
그리고 첫 화면에 들어오는 이미지는 지연 로딩에서 빼는 처리가 5.9에서 시작돼 6.3에서 정리됐다는 것입니다.
그래서 워드프레스를 최신 버전으로 쓰고 있다면 지연 로딩은 대체로 건드릴 일이 없습니다.
문제가 생기는 쪽은 테마나 플러그인이 코어 바깥에서 이미지를 직접 그리는 경우입니다.
슬라이더나 커스텀 헤더에 들어간 첫 화면 이미지까지 지연 로딩이 걸리면, 가장 먼저 보여야 할 그림이 가장 늦게 나타납니다.
확인 방법은 간단합니다.
블로그 첫 화면에서 가장 큰 이미지를 오른쪽 클릭해 검사 메뉴를 열고, 그 img 태그에 loading 속성이 lazy로 붙어 있는지 봅니다.
붙어 있으면 그 이미지만 지연 로딩에서 빼 주면 됩니다.
어디부터 손댈지 정하는 표
세 작업의 효과와 품을 나란히 두면 순서가 분명해집니다.
| 작업 | 줄어드는 폭 | 드는 품 | 주의할 점 |
|---|---|---|---|
| 긴 변 픽셀 줄이기 | 가장 큼 | 올릴 때 한 번 | 글자 들어간 그림은 읽히는지 확인 |
| WebP 변환과 제공 | 큼 | 설정 한 번 | 변환만 켜고 제공을 빠뜨리기 쉬움 |
| 지연 로딩 | 첫 화면에 한정 | 대부분 자동 | 첫 화면 이미지에는 걸지 않기 |
| 이미지 자체를 덜 넣기 | 확실함 | 글 쓸 때 판단 | 설명에 꼭 필요한 그림은 유지 |
위에서 아래로 내려가면서 하면 됩니다.
세 번째 줄까지 왔는데도 측정값이 그대로라면, 남은 원인은 이미지 바깥에 있습니다.
다 줄였는데도 안 빨라질 때
이미지를 줄여도 첫 응답 시간이 그대로면 원인은 서버 쪽입니다.
워드프레스 공식 문서도 이미지 다음 순서로 전송 단계의 압축을 다룹니다.

같은 공식 문서의 압축 항목, ① 서버가 보내는 단계에서 줄이는 방법 (2026-10-03 확인)
① 항목은 서버가 파일을 내보낼 때 압축해서 보내는 설정과, 그 처리를 캐시 플러그인이 대신해 주는 경우를 함께 설명합니다.
공유 호스팅에서는 이 설정을 열어 주지 않는 곳도 있어, 같은 글이 업체에 따라 다르게 나가기도 합니다.
여기서부터는 글을 고쳐서 해결되는 영역이 아니라 어떤 서버에 올려 두었느냐의 문제입니다.
관리형 클라우드 호스팅은 이 구간을 업체가 맞춰 두는 쪽이고, 클라우드웨이즈도 그중 하나입니다.
가장 낮은 구간이 월 14달러이고(2026년 10월 3일 공식 요금 페이지 기준, 세금 별도), 무료 SSL과 자동 백업, 스테이징이 전 구간에 들어갑니다.
카드 등록 없이 3일 동안 먼저 돌려 볼 수 있으니, 지금 쓰는 곳과 첫 응답 시간을 비교해 보고 결정하면 됩니다.

클라우드웨이즈 공식 요금 페이지, ① 가장 낮은 구간 ② 월 요금 (2026-10-03 확인)
① 가장 낮은 구간은 설명 자체가 개인 웹사이트와 단순한 블로그용이라고 적혀 있고, ② 월 요금은 14달러입니다.
처음부터 윗 구간으로 갈 이유는 없습니다.
글이 쌓이고 메모리 경고나 느려짐이 보일 때 올리면 됩니다.
구간별 사양과 월 요금을 공식 요금 페이지에서 직접 확인하기
미리 알아 둘 불편과 안 맞는 경우
이 글의 1단계와 2단계는 어느 블로그에서나 손해 볼 일이 없지만, 마지막 서버 이야기는 사람에 따라 맞지 않습니다.
해외 관리형 호스팅은 요금이 달러로 청구돼 환율에 따라 원화 금액이 달라지고, 세금은 표시 금액과 별도입니다.
관리 화면과 고객지원이 영어이고, 메일 주소는 기본 포함이 아니라 별도 부가 서비스로 붙습니다.
백업을 외부 저장소에 두면 용량에 따라 요금이 더 붙습니다.
월 방문자가 아직 많지 않고 사진도 글당 두세 장이라면, 1단계만 해도 체감이 충분히 달라집니다.
그런 경우에는 월 1만 원 이하 공유 호스팅이나 지금 쓰는 블로그 플랫폼으로 그대로 두는 편이 낫습니다.
영어 화면 앞에서 시간을 많이 쓰는 편이라면 국내 업체 쪽이 속이 편합니다.
자주 묻는 질문
이미지 용량을 줄이면 화질이 나빠지나요?
보이는 폭보다 큰 픽셀을 덜어 내는 것은 화질과 무관합니다.
어차피 화면에서 줄여 보여 주던 부분이기 때문입니다.
화질이 걸리는 쪽은 압축률을 과하게 올렸을 때이므로, 줄인 파일을 휴대전화에서 한 번 열어 보고 정하면 됩니다.
WebP로 바꾸면 원본 jpg는 사라지나요?
플러그인마다 다릅니다.
보통은 원본을 두고 WebP 버전을 따로 만들어 두었다가 지원하는 브라우저에만 보냅니다.
원본을 덮어쓰는 설정이 따로 있는 도구도 있으니, 켜기 전에 그 항목이 어떻게 돼 있는지 확인하고 백업을 한 번 받아 두십시오.
검색엔진이 WebP 이미지를 제대로 읽나요?
WebP는 오래전부터 쓰인 표준 형식이라 읽는 데 문제가 없습니다.
더 중요한 것은 형식보다 대체 텍스트와 파일 이름이고, 이미지를 줄여 페이지가 빨라지는 쪽이 검색에서는 더 직접적인 이득입니다.
지연 로딩을 모든 이미지에 거는 것이 좋지 않나요?
아닙니다.
첫 화면에 보이는 이미지에 걸면 오히려 느려 보입니다.
가장 큰 이미지는 먼저 받아야 화면이 빨리 채워지므로, 지연 로딩은 화면 밖 이미지에만 거는 것이 맞습니다.
마무리
이미지로 느려진 블로그는 긴 변 줄이기, WebP 변환과 제공, 화면 밖 지연 로딩 세 작업을 이 순서대로 하면 대부분 정리됩니다.
손대기 전에 최대 콘텐츠 표시 시간과 첫 응답 시간을 같이 보고, 원인이 이미지인지 서버인지부터 가르십시오.
첫 응답 시간이 이미 크면 이미지를 줄여도 체감이 바뀌지 않습니다.
서버가 원인으로 좁혀졌다면 가장 낮은 구간으로 시작하고, 느려지는 신호가 보일 때 올리면 됩니다.
지금 블로그의 최대 콘텐츠 표시 시간과 첫 응답 시간이 각각 몇 초로 나오시나요?
두 숫자와 글당 넣는 사진 장수를 댓글로 남겨 주시면 어느 작업부터 하면 되는지 같이 짚어 드리겠습니다.
다음 글에서는 「클라우드웨이즈 해지·서버 삭제·환불 규정 정리」에 대해 알아보겠습니다.