워드프레스 이미지 정리 전 용량 확인하는 방법

큰 이미지만 지우면 용량 문제가 풀릴 것 같지만, 썸네일과 WebP 파일도 서버 저장 공간을 차지할 수 있습니다. 먼저 호스팅 관리 화면에서 전체 사용량과 남은 공간을 적고, wp-content/uploads 폴더의 사용량을 따로 봅니다. 그다음 파일 크기를 큰 순서로 정렬해 원본과 썸네일, 별도로 저장된 WebP의 용량을 합치면 어느 이미지부터 살펴볼지 좁힐 수 있습니다.

워드프레스 이미지를 정리하기 전, 저장 공간과 업로드한 파일 중 어디서부터 용량을 살펴봐야 할까요?⠀

서버 전체 사용량과 uploads 용량 확인

다른 사이트는 잘 열리는데 내 사이트만 느리다면, 바로 이미지를 지우기에는 근거가 부족합니다.⠀

이미지와 관련 파일이 쌓여 서버 저장 공간이 부족해질 수 있다는 점부터 살펴봅니다.⠀

사진을 많이 올렸다는 기억만으로 지금 저장 공간을 얼마나 쓰는지 알 수는 없습니다.⠀

서버 저장 공간에 표시된 사용량을 볼 수 있다면, 이미지를 건드리기 전에 그 값을 적어 둡니다.⠀

이 값은 워드프레스 관리자보다 호스팅 관리 화면에서 찾는 편이 좋습니다. 호스팅에 따라 메뉴 이름은 다르지만, 저장 공간이나 디스크 사용량 항목에서 할당 용량·사용량·남은 용량을 봅니다. 전체 사용량에는 이미지 외의 백업, 메일, 데이터베이스 등이 포함될 수 있으므로 uploads 용량과 나누어 적습니다.

1. 호스팅 계정에 로그인해 해당 사이트의 관리 화면을 엽니다. cPanel을 사용하는 경우에는 Files → Disk Usage에서 디렉터리별 사용량을 살펴볼 수 있습니다. 제공 여부와 표시 방식은 호스팅에 따라 다릅니다.
2. 워드프레스 설치 폴더 아래의 wp-content/uploads까지 내려가 해당 폴더와 하위 폴더를 포함한 사용량을 봅니다. 설치 위치가 public_html이라면 public_html/wp-content/uploads가 예시 경로입니다.
3. 폴더 합계가 나오지 않으면 호스팅의 디렉터리 용량 계산 기능을 이용합니다. 그 기능도 없다면 SFTP로 해당 폴더를 내려받아 로컬에서 하위 폴더를 포함한 크기를 확인할 수 있습니다. 다운로드한 파일 크기의 합계는 서버가 계산한 실제 디스크 사용량과 조금 다를 수 있습니다.

cPanel의 Disk Usage 문서는 디렉터리별 사용량과 표시값의 차이를 설명합니다. 작은 파일도 디스크에서는 파일 크기보다 큰 공간을 차지할 수 있고, 최근 변경이 바로 반영되지 않을 수 있습니다. 그래서 파일 크기 합계와 호스팅 사용량이 정확히 일치해야 한다고 보지는 않습니다.

같은 문서에는 300바이트 파일이 실제 디스크에서는 4 KB를 차지할 수 있다는 예시도 있습니다. 모든 호스팅에 그대로 적용되는 기준은 아니지만, 작은 파일 여러 개를 합산했을 때 표시값이 달라질 수 있는 이유를 보여 줍니다. 파일 목록의 크기는 어떤 파일 묶음이 큰지 비교하는 데 쓰고, 실제로 남은 공간은 호스팅 사용량에서 다시 보는 편이 좋습니다.

변경 전 값을 남겨야 나중에 같은 화면의 사용량과 비교할 수 있습니다.⠀

평소 글에 올린 사진만 떠올리면 업로드한 다른 파일은 살펴볼 대상에서 빠집니다.⠀

저장 공간의 사용량을 본 뒤에는 실제로 어떤 파일을 올렸는지 목록으로 살펴봅니다.⠀

uploads가 전체 사용량에서 차지하는 비중이 작다면 이미지 정리만으로 확보할 수 있는 공간도 제한됩니다. 반대로 uploads가 큰 비중을 차지한다면 월별 폴더 중 용량이 큰 곳부터 살펴볼 이유가 생깁니다. 파일이 크다는 사실은 점검 순서를 정하는 근거이지, 바로 삭제해도 된다는 뜻은 아닙니다.

미디어 목록과 서버 파일 크기 함께 확인

워드프레스 미디어 라이브러리는 사이트에 업로드한 파일을 관리하는 곳입니다.⠀

관리자 화면에서 미디어 라이브러리를 열어, 정리하려던 이미지가 목록에 있는지 살펴봅니다.⠀

미디어 → 라이브러리에서 이미지를 열면 파일명과 파일 URL을 찾을 수 있습니다. 화면이나 버전에 따라 파일 크기도 표시되지만, 여기서 보는 한 항목의 크기를 원본과 파생 파일 전체의 합계로 보지는 않습니다. 파일 URL의 /uploads/2026/10/ 같은 부분을 읽으면 서버에서 찾아갈 폴더를 좁힐 수 있습니다.

처음에는 느려진 페이지에 보이는 사진부터 지우고 싶을 수 있습니다.⠀

목록에 있는 파일과 페이지에 보이는 사진을 구분해 보면, 손댈 대상을 좁힐 수 있습니다.⠀

삭제할 파일을 고르기 전에 목록에서 파일명과 URL을 읽고, 서버에서 크기를 함께 살펴봅니다.

1. 호스팅 파일 관리자를 엽니다. cPanel에서는 Files → File Manager가 예시 경로입니다. 또는 호스팅에서 안내한 서버 주소·포트·계정으로 SFTP 클라이언트에 접속합니다. 접속 정보는 워드프레스 관리자 계정과 다를 수 있습니다.
2. 워드프레스 설치 폴더에서 wp-content/uploads/연도/월을 엽니다. 연도·월 폴더를 사용하지 않거나 업로드 위치를 바꾼 사이트에서는 미디어의 파일 URL과 호스팅 설정을 기준으로 실제 위치를 찾습니다.
3. 파일 목록의 크기 또는 Size 열을 눌러 큰 파일부터 정렬합니다. 정렬 범위가 현재 폴더라면 uploads 전체를 정렬한 결과는 아니므로, 용량이 큰 월별 폴더를 차례로 봅니다.
4. 큰 파일을 찾으면 같은 이름에서 파생된 파일도 모아 크기를 적습니다. 합산할 때는 바이트나 KB처럼 단위를 하나로 맞추고, 같은 파일을 두 번 더하지 않습니다.

파일 관리자에서 설치 위치를 여는 방법은 cPanel의 File Manager 문서에서도 확인할 수 있습니다. SFTP 목록에 보이는 폴더 크기는 하위 파일까지 합한 값이 아닐 수 있으므로, 폴더 합계는 디렉터리 용량 계산 결과와 구분합니다.

서버 저장 공간의 사용량과 목록에 보이는 파일을 함께 놓고 정리 대상을 고릅니다.⠀

미디어 목록의 ‘첨부되지 않음’만으로 사용하지 않는 파일이라고 판단하지는 않습니다. 본문에 URL로 넣은 이미지, 대표 이미지, 테마나 페이지 빌더에서 쓰는 파일도 있기 때문입니다. 해당 게시글과 대표 이미지 설정을 살펴보고, 모바일 화면에서 다른 크기의 이미지가 쓰이는지도 확인한 뒤 정리 여부를 정합니다.

페이지에서 어떤 이미지를 살펴볼지 아직 정하지 못했다면 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유에서 확인할 게시글부터 고를 수 있습니다. 다만 한 페이지에서 요청되지 않았다는 사실만으로 사이트 전체에서 쓰지 않는 파일이라고 결론 내리지는 않습니다.

미디어 유형별 파일과 용량 확인

미디어 라이브러리에는 이미지 외에 PDF, 오디오, 동영상도 들어갑니다.⠀

사진을 정리하려고 목록을 열었다면 파일 이름을 살펴보고 이미지와 다른 파일을 구분합니다.⠀

검색에서 본 조언대로 이미지를 지우기 시작하면 다른 업로드 파일은 그대로 남습니다.⠀

저장 공간의 사용량을 따질 때는 사진 목록만 보고 전체 업로드 파일을 짐작하지 않습니다.⠀

PDF나 동영상이 보인다면 이미지 정리 대상과 섞지 않고 따로 읽어 둡니다.⠀

미디어 라이브러리의 유형 필터로 이미지·문서·오디오·동영상을 나누어 보고, 서버 목록에서는 확장자와 크기를 함께 봅니다. 사진이 많더라도 실제로는 동영상 몇 개가 더 큰 공간을 차지할 수 있습니다. 유형별로 큰 파일을 먼저 적어 두면 이미지 정리로 확보할 수 있는 공간을 과대평가하지 않게 됩니다.

목록에서 이미지라고 생각했던 파일이 다른 형식이라면 삭제 대상을 다시 고를 필요가 있습니다.⠀

원본과 썸네일 용량 비교

이미지와 함께 썸네일도 쌓여 서버 저장 공간 부족에 영향을 줄 수 있습니다.⠀

원본 이미지만 염두에 두고 용량을 살피면 썸네일은 계산에서 빠집니다.⠀

워드프레스의 반응형 이미지 문서는 업로드한 이미지에서 여러 크기의 파일을 만들고 화면에 맞는 이미지를 제공하는 구조를 설명합니다. 생성되는 크기와 개수는 원본 크기, 테마, 플러그인, 이미지 크기 설정에 따라 달라집니다. 썸네일이 여러 개 있다는 사실만으로 불필요한 파일이라고 보지는 않습니다.

큰 원본을 찾는 일은 필요할 수 있지만, 저장 공간을 살필 대상이 거기서 끝나지는 않습니다.⠀

원본 이미지와 썸네일을 구별해 놓고, 어느 쪽을 정리하려는지부터 정합니다.⠀

페이지에 보이는 사진 한 장을 기준으로 저장된 파일까지 한 장이라고 가정하지 않습니다.⠀

서버의 파일 목록을 볼 수 있다면 원본 옆에 썸네일 파일이 있는지 살펴봅니다.⠀

예를 들어 garden.jpg 옆의 garden-150x150.jpg와 garden-1024x683.jpg는 크기별 파생 파일을 찾을 때 살펴볼 이름입니다. 다만 이름은 단서일 뿐입니다. 같은 이름으로 시작하는 다른 사진이 섞이지 않았는지 미디어 항목과 파일 경로도 함께 대조합니다. -scaled 파일이 있다면 업로드 원본과 자동 축소본을 각각 계산합니다. 이 경우 원본도 보관되는 구조는 워드프레스의 이미지 생성 함수 문서에서 확인할 수 있습니다.

아래는 파일 크기를 합치는 방법을 보여 주는 계산 예시입니다. 이 사이트에서 직접 측정한 값이나 평균 압축률은 아닙니다. 실제 파일 수와 크기는 사진 내용과 생성 설정에 따라 달라집니다.

파일명 또는 묶음(예시)	구분	크기(예시)
garden.jpg	업로드 원본	2,400 KB
garden-150×150.jpg	작은 썸네일	20 KB
garden-300×200.jpg	크기별 파생 파일	50 KB
garden-1024×683.jpg	크기별 파생 파일	250 KB
garden.jpg.webp	별도 저장된 원본 대응 WebP	1,500 KB
위 파생 파일 3개의 대응 WebP	별도 저장된 WebP 3개	합계 200 KB
전체 8개 파일	원본 1개＋파생 JPEG 3개＋WebP 4개	4,420 KB

이 예시에서는 원본만 보면 2,400 KB이지만, JPEG 파생 파일 320 KB와 WebP 1,700 KB까지 더하면 4,420 KB입니다. 원본만 계산하면 2,020 KB가 빠집니다. WebP가 각각 더 작더라도 JPEG를 남긴 채 별도로 저장하면 전체 저장 용량은 늘 수 있다는 점을 함께 봅니다.

파일마다 KB 표시를 반올림하는 도구도 있으므로 정확한 합계가 필요하면 바이트 값을 더한 뒤 단위를 바꿉니다. 폴더 사용량에 이미 포함된 WebP를 다시 더하지 않도록 저장 위치도 함께 적습니다.

WebP 저장 방식과 변경 후 용량 확인

WebP 파일을 원본과 썸네일에 더해 별도로 저장하는 방식이라면, 이 파일들도 서버 저장 공간 부족에 영향을 줄 수 있습니다.

서버의 파일 목록을 볼 수 있다면 원본을 살핀 자리에서 WebP 파일도 찾아봅니다.⠀

WebP가 같은 폴더에 보이지 않는다고 생성되지 않았다고 판단하지는 않습니다. 변환 도구가 별도 폴더에 저장하거나 외부 서비스에서 제공할 수도 있습니다. 먼저 사용 중인 도구의 저장 위치와 원본 보관 설정을 읽고, 그 위치까지 용량 확인 범위에 넣습니다.

저장 위치가 다르면 합산 범위도 달라집니다

실제 저장 방식	용량을 계산할 범위	정리 전에 살필 점
JPEG·PNG를 보관하고 WebP를 별도 생성	원본·크기별 파생 파일＋WebP 저장 폴더	원본 URL과 대체 이미지 제공에 기존 파일이 필요한지 봅니다. 별도 폴더의 WebP를 uploads 합계에 빠뜨리지 않습니다.
변환 후 기존 파일을 실제로 제거하는 방식	현재 남은 WebP와 파생 파일, 보관된 백업	화면에서 WebP가 제공되는 것과 기존 파일이 삭제된 것은 다릅니다. 기존 URL 참조가 갱신됐는지 봅니다.
WebP 파일 자체를 업로드	업로드한 WebP＋생성된 크기별 WebP	대응 JPEG가 반드시 있는 것은 아닙니다. WebP의 파생 파일도 빠뜨리지 않습니다.
외부 이미지 서비스에서 변환·제공	호스팅에 남은 원본·파생 파일·로컬 캐시	외부에서 제공하는 WebP가 호스팅에도 저장되는지는 서비스 설정에 따라 다릅니다.

도구별 차이를 보여 주는 예로 WebP Express의 제작자 문서를 보면, JPEG·PNG 요청에 WebP를 제공하거나 HTML의 이미지 주소를 바꾸는 방식이 있습니다. 별도 저장 경로로 wp-content/webp-express/webp-images가 쓰이는 구성도 있습니다. 이 도구를 사용한다면 설정 → WebP Express에서 작동 모드와 변환 범위를 먼저 봅니다. 이는 설명용 예시이며, 이 사이트가 해당 도구를 사용한다는 뜻은 아닙니다.

외부 변환의 비교 대상으로는 Cloudflare의 이미지 변환 문서를 볼 수 있습니다. 이 방식은 원본 서버에서 이미지를 가져와 변환하고, 결과를 Cloudflare의 캐시에 보관해 제공합니다. 따라서 방문자에게 WebP가 내려온다는 사실만으로 워드프레스 호스팅에 같은 WebP 파일이 저장됐다고 보지는 않습니다.

별도 저장은 파일 목록에서 생성 결과를 직접 찾기 쉽지만, 원본을 남기면 저장 공간이 추가로 필요합니다. 외부 변환은 변환본을 외부 캐시에서 제공할 수 있지만, 호스팅에 남은 원본 용량은 그대로일 수 있습니다. 두 방식 모두 전송량을 줄일 수 있어도 호스팅 저장 공간이 줄어드는 조건은 다릅니다.

앞의 garden 묶음에 이 차이를 적용하면 계산 범위가 더 분명해집니다. 아래는 공식 문서의 저장 구조를 바탕으로 기존 예시 값을 나눈 것으로, 두 도구를 직접 설치해 비교한 결과는 아닙니다.

• 같은 월별 폴더에 별도 저장한 경우(예시): JPEG 4개와 WebP 4개가 함께 있으므로 해당 묶음의 파일 크기 합계는 4,420 KB입니다. 폴더 합계에 WebP가 이미 들어 있다면 다시 더하지 않습니다.
• uploads 밖의 별도 폴더에 저장한 경우(예시): uploads에는 JPEG 4개, 합계 2,720 KB가 남고, 별도 WebP 폴더에는 4개, 합계 1,700 KB가 있습니다. uploads만 보면 전체 묶음 중 1,700 KB가 빠집니다.
• 외부에서만 변환본을 보관하는 경우(예시): 로컬 WebP와 로컬 캐시가 없다는 조건이라면 호스팅에서 합산할 묶음은 JPEG 4개, 2,720 KB입니다. 외부 응답의 WebP 전송량을 이 값에 더하지 않습니다.

변환 작업을 외부 서버에서 했다는 설명만으로 마지막 경우에 해당한다고 판단하지는 않습니다. 외부에서 변환한 결과를 내 호스팅으로 내려받아 보관하는 구성도 있기 때문입니다. 계산 범위를 정할 때는 변환한 장소보다 완성된 파일이 남는 장소가 더 직접적인 단서입니다.

원본만 정리하라는 조언을 보면 곧바로 큰 파일부터 고르게 됩니다.⠀

개인적으로는 WebP 파일이 보이는 자리에서 원본과 함께 살필 대상을 고르는 편이 낫다고 봅니다.⠀

이 판단은 원본과 WebP를 함께 보관하는 구성을 전제로 합니다. 방문자에게 WebP가 보이더라도 원본 URL이 제공 규칙의 출발점으로 쓰일 수 있기 때문입니다. 반대로 기존 파일을 실제로 대체한 구성이라면 남아 있는 파일과 백업을 기준으로 계산합니다.

원본 이미지, 썸네일, WebP 파일이 모두 보인다면 그 이름을 각각 구별해 둡니다.⠀

변경 뒤에는 파일과 페이지를 함께 봅니다

파일을 바꿀 때에는 백업해 둔 뒤 하나만 변경하고, 앞서 적은 저장 공간 사용량과 다시 대조합니다.⠀

여기서 하나는 임의의 썸네일 파일 하나를 지운다는 뜻보다, 이미지 한 항목을 시험 대상으로 삼는 편이 좋습니다. 변경 전에는 해당 원본과 파생 파일, 별도 WebP를 복원할 수 있게 보관합니다. 미디어 항목을 삭제하거나 변환 설정을 바꾼다면 데이터베이스와 도구 설정도 복원 범위에 넣습니다. 같은 호스팅 안에 둔 백업은 여전히 저장 공간을 차지하므로, 확보한 용량을 비교할 때 함께 계산합니다.

사용하지 않는다고 확인된 미디어는 서버 파일만 따로 지우기보다 미디어 라이브러리에서 정리하는 편이 관리 기록과 맞추기 쉽습니다. 다만 변환 도구가 별도로 만든 WebP까지 처리하는지는 도구별로 다릅니다. 사용 여부가 불분명한 파일은 크기가 크더라도 정리 대상으로 확정하지 않습니다.

1. 같은 경로의 크기를 다시 봅니다. 변경한 이미지 묶음과 uploads, 별도 WebP 폴더의 합계를 다시 계산합니다. 휴지통이나 호스팅内의 백업에 파일이 남아 있다면 실제 공간이 아직 줄지 않았을 수 있습니다.
2. 호스팅 사용량의 갱신을 기다립니다. 관리 화면을 다시 열고, 제공되는 재계산 기능이나 호스팅이 안내한 갱신 주기를 따릅니다. 바로 줄지 않았다는 이유로 다른 파일을 연달아 지우지는 않습니다.
3. 이미지가 쓰인 대표 페이지를 봅니다. 해당 게시글, 글 목록의 대표 이미지, 모바일 화면에서 사진이 정상적으로 보이는지 확인합니다. 삭제한 이미지라면 의도한 위치에서만 사라졌는지도 봅니다.
4. 새 요청에서도 확인합니다. 페이지 캐시와 CDN 캐시를 갱신한 뒤 브라우저 개발자 도구의 Network에서 캐시를 사용하지 않도록 설정하고 다시 불러옵니다. 관련 이미지 요청에 404 같은 오류가 없는지, WebP를 제공하려던 경우 응답의 Content-Type이 image/webp인지 봅니다.

WebP Express처럼 원래 JPEG 주소로 WebP를 제공하는 방식에서는 주소 끝이 .jpg여도 응답은 WebP일 수 있습니다. 이때는 파일명보다 응답의 Content-Type을 보는 이유가 있습니다. 이 확인 방법도 WebP Express의 검증 안내에 설명되어 있습니다.

변경 기록은 아래처럼 같은 범위와 단위로 남기면 비교하기 쉽습니다. 다음 값은 앞의 계산 예시에서 사용하지 않는 이미지 한 묶음을 정리했다고 가정한 값이며, 직접 측정한 결과는 아닙니다.

확인 항목	변경 전(예시)	변경 후(예시)
uploads/2026/10 파일 크기 합계	500,000 KB	495,580 KB
garden 관련 8개 파일 합계	4,420 KB	0 KB
계산상 줄어든 파일 크기	변경 전 기준	4,420 KB
대표 페이지 표시	기존 화면 확인	다른 이미지 표시 정상, 관련 요청 오류 없음
호스팅 전체 사용량	관리 화면 값 기록	갱신 후 같은 화면에서 감소 여부 확인

이 예시는 WebP도 같은 월별 폴더에 있고, 백업은 호스팅 밖에 보관한 조건입니다. WebP가 별도 폴더에 있다면 줄어든 용량을 폴더별로 나누어 적습니다. 방문할 때 WebP를 다시 생성하는 설정이라면 페이지를 확인한 뒤 파일 합계도 한 번 더 봅니다. 지운 직후의 감소량만 보면 유지되는 절감량을 잘못 판단할 수 있습니다.

다시 생성된 파일은 절감량에서 빠집니다

WebP Express의 제작자 안내에는 아직 없는 WebP를 이미지 요청이나 페이지 방문 때 생성하는 방식이 설명되어 있습니다. 따라서 원본을 남긴 채 변환본만 지웠다면, 다음 요청에서 저장 공간이 다시 늘어날 수 있습니다. 앞의 표처럼 사용하지 않는 미디어 묶음을 정리한 경우와 구분해서 볼 필요가 있습니다.

예를 들어 앞의 garden 묶음에서 WebP 4개만 제거했다면 파일 합계는 4,420 KB에서 2,720 KB로 줄어듭니다. 이후 네 변환본이 모두 같은 크기로 다시 생성됐다는 조건에서는 4,420 KB로 돌아옵니다. 이는 요청 시 생성 방식에 기존 계산값을 적용한 예시이며, 다시 생성되는 파일 수와 크기를 보장하는 값은 아닙니다.

한 페이지가 네 크기를 모두 요청하는 것도 아닙니다. 모바일에서는 작은 파생 파일만 먼저 생성되고, 다른 화면이나 게시글에서는 다른 크기가 나중에 생성될 수 있습니다. 그래서 변경 직후와 대표 페이지를 열어 본 뒤의 파일 목록을 나누어 보면, 처음 줄어든 공간과 이후에도 남는 절감량을 구별하기 쉽습니다.

이미지 정리 전에는 원본과 함께 쌓인 썸네일, WebP 파일까지 보고 용량을 판단합니다.⠀

다음으로 서버의 파일 목록에서 WebP 파일 이름을 찾아보십시오. 원본 옆에 없다면 변환 도구의 저장 위치까지 살펴보고, 그 파일이 차지하는 공간과 현재 사용 여부를 함께 적어 두면 됩니다.

저장 공간이 줄어든 것과 페이지가 빨라진 것은 따로 확인할 일입니다. 용량 정리 뒤에도 속도가 걱정된다면 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에서 실제 이미지 요청과 남은 지연 원인을 나누어 볼 수 있습니다.

기술 설명에 사용한 공식 문서는 2026년 10월 9일에 확인했습니다. 경로와 설정은 cPanel과 WebP Express를 예로 들었으며, 파일 용량과 변경 결과는 계산용 예시입니다. 실제 사이트에서 검증할 때는 호스팅 종류, 워드프레스와 변환 도구의 버전, 원본 보관 여부, WebP 저장 위치, 확인 시점을 함께 기록하면 이후 비교에도 도움이 됩니다.

관련 글은 파일이 여러 개 생기는 구조부터 페이지에서 살펴볼 이미지, 정리 후 확인 순서로 이어집니다. 사용 여부 판단은 위의 미디어 항목·대표 이미지·모바일 화면 확인과 함께 진행하고, 속도 관련 글에서는 실제 이미지 요청을 살펴보면 됩니다.

• 사진 한 장인데 썸네일 파일이 여러 개 생기는 이유
• 이미지만 WebP로 바꿨는데 LCP가 달라지는 이유
• 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유
• 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법
• PageSpeed 점수, WebP 적용만으로 올라갈 수 있을까