워드프레스 이미지 최적화｜WebP·AVIF보다 먼저 볼 5가지

워드프레스 이미지 최적화는 JPEG를 WebP나 AVIF로 바꾸는 작업만 뜻하지 않습니다. 화면에는 800px로 보이는데 4,000px 원본을 내려받거나, 첫 화면의 LCP 이미지를 지연 로딩하거나, 변환본을 만들고도 HTML과 CDN이 원본 파일을 전달하면 체감 속도는 거의 달라지지 않습니다.

먼저 브라우저가 실제로 받은 이미지의 주소·크기·용량을 확인하고 원본 크기, 반응형 이미지, 압축 형식, 로딩 우선순위와 캐시를 차례로 점검해야 합니다. 이 글은 대표 URL 세 개를 기준으로 20분 안에 원인을 구분하는 순서를 설명합니다.

이미지 최적화의 다섯 구간

워드프레스는 미디어를 업로드할 때 여러 중간 크기를 만들고, 일반 이미지 마크업에 srcset과 sizes를 포함해 브라우저가 화면 폭과 해상도에 맞는 파일을 선택하도록 돕습니다. 따라서 파일명에 WebP가 보이는지만 확인하지 말고 개발자 도구의 Network 패널에서 실제로 선택된 currentSrc와 전송 용량을 확인해야 합니다.

형식은 이미지 역할에 맞춰 선택

무조건 AVIF가 정답은 아닙니다. 사진, 캡처 화면과 투명 그래픽을 각각 몇 장 골라 같은 표시 크기에서 화질과 용량을 비교하세요. 글자가 많은 캡처는 강한 손실 압축으로 번짐이 생길 수 있고, 단순 사진은 PNG보다 손실 WebP나 AVIF가 효율적일 수 있습니다.

20분 진단과 적용 순서

1. 대표 URL 세 개를 정한다

홈 또는 카테고리, 일반 글, 이미지가 많은 글을 하나씩 고릅니다. 로그인 상태에서는 관리자 도구와 캐시 예외가 개입할 수 있으므로 시크릿 창이나 로그아웃 상태에서도 확인합니다. 변경 전 URL, 모바일·PC 조건, 이미지 요청 수와 전송량을 기록하세요.

2. 가장 무거운 이미지의 실제 전달 파일을 확인한다

브라우저 Network 패널에서 Img 유형을 용량순으로 정렬합니다. 화면의 표시 폭, 원본 픽셀, 전송된 URL과 용량을 함께 적습니다. CSS로 작게 보인다는 이유만으로 작은 파일이 전달되는 것은 아닙니다. srcset이 있어도 잘못된 sizes 값 때문에 필요 이상으로 큰 후보가 선택될 수 있습니다.

3. LCP 이미지를 먼저 분리한다

PageSpeed Insights나 브라우저 성능 도구에서 LCP 요소가 이미지인지 확인합니다. 첫 화면의 대표 이미지라면 loading="lazy"를 적용하지 않아야 합니다. 최신 워드프레스는 LCP 후보에 로딩 우선순위를 자동 조정할 수 있으므로 테마와 최적화 플러그인이 같은 이미지에 상충하는 속성을 추가하지 않는지 원본 HTML을 확인하세요. fetchpriority="high"와 loading="lazy"를 함께 넣지 않습니다.

측정값이 매번 흔들리면 한 번의 점수 대신 PageSpeed 3회 측정 기록법으로 중앙값과 반복되는 지적 사항을 확인하세요.

4. 크기 조절 후 압축하고 변환한다

먼저 테마의 실제 콘텐츠 폭과 고해상도 화면을 고려해 원본 픽셀을 줄입니다. 그다음 화질을 비교하며 압축하고 WebP 또는 AVIF 변환을 적용합니다. 형식 변환부터 하면 지나치게 큰 픽셀 수가 그대로 남아 효과가 제한될 수 있습니다. 이미지의 width와 height도 유지해 브라우저가 표시 공간을 미리 확보하도록 합니다.

5. 변환본이 실제로 전달되는지 검증한다

일괄 최적화가 끝나면 시크릿 창에서 같은 URL을 다시 열고 Network 패널의 응답 URL·Content-Type·전송량을 비교합니다. 원본 확장자 URL을 유지하면서 서버가 다른 형식으로 응답하는 구성도 있으므로 주소만으로 판단하지 마세요. 모바일과 PC에서 각각 선택되는 파일도 확인합니다.

6. 첫 화면 아래 이미지만 지연 로딩한다

지연 로딩은 화면 아래의 이미지를 늦게 요청해 초기 전송량과 네트워크 경쟁을 줄이는 기능입니다. 하지만 LCP 이미지와 첫 화면 안의 중요한 이미지를 늦추면 오히려 주요 콘텐츠 표시가 지연됩니다. 지연 로딩 플러그인, 테마와 워드프레스 코어가 중복으로 속성을 넣지 않는지도 확인하세요.

7. 캐시를 한 층씩 비우고 다시 측정한다

이미지를 교체하거나 변환한 뒤에는 페이지 캐시, CDN 캐시와 브라우저 캐시가 이전 HTML이나 파일을 계속 제공할 수 있습니다. 전체 삭제를 반복하기보다 변경한 URL부터 무효화하고 새 시크릿 창에서 확인합니다. 예전 사진이 계속 보인다면 이미지 캐시 원인 5분 구분법을 참고하세요.

변경 전후 기록표

• 테스트 URL과 모바일·PC 조건
• 가장 큰 이미지의 표시 폭과 실제 픽셀
• 전송 URL, Content-Type과 전송 용량
• LCP 이미지 여부와 lazy loading 적용 여부
• srcset·sizes와 브라우저가 선택한 파일
• PageSpeed 3회 중앙값과 반복 경고
• 화질 깨짐, 투명 배경과 모바일 레이아웃 이상 여부

최적화 후에는 본문 이미지뿐 아니라 카테고리 썸네일, SNS 공유 이미지, 검색 결과와 관리자 미디어 화면도 확인합니다. 현장 사용자 데이터는 즉시 바뀌지 않으므로 Search Console Core Web Vitals 반영 방식과 실험실 측정값을 구분하세요.

TIP

이미지 최적화 플러그인의 “일괄 변환”을 누르기 전에 원본 보관 방식, 저장 공간, 삭제 시 복원 여부를 확인하세요. 대표 이미지 몇 장으로 먼저 시험하고 페이지 캐시와 CDN을 포함한 실제 전달 결과가 정상일 때 범위를 넓히는 편이 안전합니다.

대체 텍스트는 속도 설정이 아니라 접근성과 이미지 의미 전달을 위한 정보입니다. 파일명이나 키워드를 반복하지 말고 이미지가 본문에서 수행하는 역할을 짧고 정확하게 설명하세요.

자주 묻는 질문

WebP로 바꿨는데 왜 속도가 그대로인가요?

너무 큰 원본이 전달되거나, 변환본이 실제 응답에 사용되지 않거나, LCP 이미지가 지연 로딩될 수 있습니다. Network 패널에서 선택된 파일과 전송량부터 확인하세요.

모든 이미지를 AVIF로 바꿔야 하나요?

필요하지 않습니다. 이미지 종류별 화질, 변환 시간과 실제 전송 용량을 비교하고 WebP나 기존 형식보다 이점이 있는 경우에 적용하세요.

첫 번째 본문 이미지는 항상 LCP인가요?

아닙니다. 테마의 제목, 배너, 대표 이미지와 화면 크기에 따라 LCP 요소가 달라질 수 있습니다. URL과 모바일·PC 조건별로 실제 측정해야 합니다.

공식 참고 자료

• 워드프레스 반응형 이미지 안내
• 워드프레스 이미지 로딩 최적화 설명
• web.dev 이미지 형식 선택
• web.dev LCP 최적화

핵심은 확장자를 바꾸는 것이 아니라 브라우저가 적절한 크기의 파일을 적절한 시점에 받도록 만드는 것입니다. 원본 크기, 반응형 후보, 형식, LCP 우선순위와 캐시를 한 단계씩 바꾸고 같은 조건으로 다시 측정하세요.