워드프레스가 만든 썸네일 387개 중 150×150 123개는 30일 동안 요청 0건이었고, 이미지 전송량의 56.6%는 원본이었다

워드프레스는 이미지를 하나 올리면 150×150, 300, 768, 1024 폭짜리 파일을 같이 만듭니다. 이 사이트의 업로드 폴더에는 원본 124개와 그렇게 만들어진 파일 387개, 모두 511개 74.6MB가 있습니다. 이 가운데 실제로 요청되는 파일이 무엇인지 30일치 접속 로그로 세었습니다. 150×150 파일 123개는 30일 동안 한 번도 요청되지 않았고, 300 폭 파일은 123개 중 83개가 요청됐지만 전송량은 전체의 0.6%였습니다. 반대로 원본은 124개 중 120개가 요청됐고, 이미지 전송량 1,557.6MB 중 881.9MB(56.6%)를 차지했습니다. 축소본을 만드는 이유가 원본을 덜 내보내기 위해서인데, 이 사이트에서는 원본이 가장 많이 나가고 있었습니다.

크기별 파일 수와 요청 수

8월 23일 0시부터 9월 22일 0시까지 30일 동안 /wp-content/uploads/ 아래로 온 요청 7,777건 중 실제 있는 파일에 대한 요청은 5,192건입니다. 나머지 2,585건은 뒤에서 따로 봅니다.

150×150은 관리자 화면의 미디어 목록에서만 쓰는 크기라 방문자 요청이 0인 것이 정상입니다. 그래도 파일 123개, 3.2MB가 디스크에 있고 백업에도 들어갑니다. 300 폭은 srcset에 들어가 있어서 좁은 화면이나 검색 봇이 가끔 고르지만, 151건이 전부입니다. 실제 부하는 768 폭과 원본 두 곳에 있습니다. 768 폭은 홈 화면과 목록에 쓰는 크기라 요청 수가 가장 많고, 원본은 요청 수는 그보다 적은데 하나가 356KB라 전송량에서는 1위입니다.

원본이 나가는 두 가지 경로

원본 요청 2,474건의 referer를 보면 어디에서 원본을 부르는지 나옵니다.

워드프레스·서버 사이트는 홈 화면에서 원본을 1,224번 불렀습니다. 홈 화면의 글 목록은 768 폭 파일을 쓰도록 되어 있는데도 그렇습니다. 이유는 8월에 올린 대표 이미지의 폭에 있었습니다. 요청이 가장 많았던 원본 두 개는 8월 21일에 올린 696×500과 740×500짜리 PNG입니다. 폭이 768보다 작으면 워드프레스는 768 폭과 1024 폭 파일을 만들지 않고, 홈 화면은 768 폭이 없으니 원본을 그대로 씁니다. 그 원본이 각각 406KB, 391KB입니다. 30일 동안 첫 번째 파일이 186번 70.8MB, 두 번째 파일이 162번 61.0MB 나갔습니다. 9월부터 대표 이미지를 1200×630으로 맞추면서 768 폭 파일이 생겼고, 그 뒤 올린 글의 홈 화면 요청은 768 폭으로 갑니다.

글 본문에서는 원본이 기본값이다

글 본문 상단의 대표 이미지는 테마가 src에 원본을 넣고 srcset에 300, 768, 1024 폭을 붙입니다. sizes 값은 auto, (max-width: 768px) 100vw, 768px이라 폭 768px 자리에 이미지가 들어가는데, 픽셀 밀도가 2배인 화면은 1,536px짜리를 찾다가 그보다 큰 1200 원본을 고릅니다. 글 본문 원본 요청 447건 중 상당수가 이 경로입니다. 1024 폭 요청 566건도 같은 srcset에서 나온 것으로, 1024×538 파일 11개 중 10개가 492번 불렸습니다. 1024 폭 파일 52개 중 12개는 한 번도 요청되지 않았는데, 대부분 본문 그래프에서 나온 것으로, 그래프는 원본 폭이 1100이라 srcset에서 1024 폭을 고를 이유가 적고, 하나는 발행하지 않은 글의 대표 이미지입니다.

있지도 않은 파일을 찾는 2,585건

업로드 폴더 요청 7,777건 중 2,585건(33.2%)은 없는 경로였습니다. 404가 1,455건, http에서 https로 보내는 301이 979건, 403이 79건, 500이 51건입니다. 없는 경로는 154가지인데, 폴더 자체를 여는 /wp-content/uploads/가 859건으로 가장 많고 나머지는 대부분 PHP 파일입니다.

업로드 폴더는 파일을 쓸 수 있는 폴더라서, 다른 경로로 심어 둔 PHP 파일이 있는지 스캐너가 이름을 돌려 가며 확인하는 것입니다. file1.php, users.php, panel.php가 거의 같은 건수인 것은 같은 스캐너가 한 묶음으로 돌리기 때문입니다. .git 폴더를 뒤진 요청과 마찬가지로 지금은 모두 404이고, 이 사이트의 업로드 폴더에 PHP 파일은 없습니다. 폴더 목록 859건은 아파치가 목록을 보여 주지 않으니 404 394건, 301 388건, 403 77건으로 끝났습니다.

한 번도 요청되지 않은 파일 182개

511개 중 182개(35.6%)는 30일 동안 요청이 없었습니다. 123개는 위의 150×150이고, 나머지 59개는 300 폭 40개, 1024 폭 12개, 768 폭 3개, 원본 4개입니다. 용량으로는 7.3MB, 전체의 9.7%입니다. 원본 하나에 딸린 파일을 한 묶음으로 보면 124묶음 중 99묶음은 원본과 축소본이 모두 요청됐고, 21묶음은 원본만, 2묶음은 축소본만, 2묶음은 아무것도 요청되지 않았습니다. 원본만 요청된 21묶음은 모두 7월과 8월에 올린 것으로, 하나같이 150×150과 300 폭만 있고 768 폭이 없는 이미지들입니다. PNG 열 장을 줄였을 때 전송량이 0.5%만 줄었던 것도 같은 이유였습니다. 그때 줄인 것은 파일 크기였고, 정작 홈 화면이 부르는 것은 축소본이 없는 원본이었습니다.

정리

• 이미지 전송량의 56.6%가 원본입니다. 8월 대표 이미지 폭이 768보다 작아 축소본이 안 만들어졌고, 홈 화면이 원본을 그대로 씁니다. 해당 이미지를 1200 폭으로 다시 올리면 홈 화면 요청은 768 폭으로 바뀝니다.
• 150×150 파일 123개는 요청 0건입니다. 삭제해도 방문자 쪽 변화는 없지만 관리자 미디어 목록이 원본을 불러오게 되므로, 지우기보다 생성을 끄는 쪽이 맞습니다.
• 업로드 폴더 요청의 3분의 1은 PHP 파일을 찾는 스캐너입니다. 업로드 폴더에서 PHP 실행을 막는 규칙이 없다면 이 로그가 그 규칙을 넣을 근거입니다.

측정 방법

업로드 폴더 511개 파일의 경로와 크기를 읽고, 파일 이름 끝의 -폭x높이로 크기 종류를 나눴습니다. 원본 124개에는 이미지가 아닌 로그 파일 1개가 들어 있고, 요청되지 않은 원본 4개 중 하나가 그 파일입니다. 접속 로그 다섯 개에서 경로에 /wp-content/uploads/가 든 줄을 뽑아 존재하는 파일과 맞춰 요청 수, 응답 크기, referer, 상태 코드를 셌습니다. 기간은 로그의 첫 줄 8월 23일 0시 1분부터 마지막 줄 9월 22일 0시 6분까지입니다. 전송량은 로그의 응답 크기 합이라 206 부분 응답 234건과 304 응답 62건도 그대로 들어 있습니다. 이미지 폭은 file 명령으로 확인했고, 홈 화면과 글 본문의 img 태그는 curl로 받아 srcset과 sizes를 봤습니다. 화면 픽셀 밀도에 따른 선택은 로그에 남지 않아 브라우저 규칙으로 설명한 것입니다.