미디어 라이브러리에는 이미지가 한 장으로 보이지만, 서버의 업로드 폴더를 열어 보면 같은 이름에 크기가 붙은 파일이 여러 개 있습니다. 워드프레스가 업로드 시점에 등록된 크기마다 사본을 만들어 두기 때문입니다.
왜 미리 만들어 두나
요청이 올 때마다 이미지를 줄이면 서버가 매번 일을 하게 됩니다. 미리 만들어 두면 방문자에게는 이미 준비된 파일이 나가고, 무엇보다 다음 회차에서 다룰 반응형 이미지의 후보 목록이 이 사본들에서 만들어집니다. 즉 이 사본들은 낭비가 아니라 재료입니다.
크기는 두 곳에서 등록됩니다. 코어 기본값(썸네일 · 중간 · 큰 크기 등)과 테마와 플러그인이 추가로 등록하는 크기입니다. 후자가 문제를 만듭니다 — 테마를 바꿔도 옛 테마가 등록해 둔 크기로 만들어진 파일은 그대로 남고, 새 테마는 그것을 쓰지 않습니다.
안 쓰는 크기가 만드는 두 가지 비용
첫째는 디스크와 백업입니다. 이미지가 수천 장인 사이트에서 쓰지 않는 크기 하나는 수천 개의 파일이 됩니다. 백업 시간과 이전 작업 시간이 함께 늘어납니다.
둘째가 덜 알려져 있는데 더 성가십니다. 워드프레스는 반응형 이미지 후보 목록을 만들 때 존재하는 사본들에서 후보를 뽑습니다. 실제 레이아웃과 무관한 어정쩡한 크기가 잔뜩 등록돼 있으면 후보 목록이 지저분해지고, 브라우저가 고르는 결과도 우리가 의도한 것과 멀어집니다.
정리 순서
먼저 지금 등록돼 있는 크기가 무엇인지 목록으로 확인합니다. 그다음 각 크기가 템플릿에서 실제로 호출되는지 대조합니다. 쓰이지 않는 등록을 걷어낸 뒤, 마지막으로 기존 이미지의 사본을 재생성하면 새 기준으로 정리됩니다.
순서가 중요합니다. 등록을 지우기 전에 파일부터 지우면, 재생성 대상 목록을 잃어버립니다. 그리고 어느 단계든 시작 전에 업로드 폴더와 데이터베이스를 함께 백업합니다 — 되돌릴 수 있는 상태가 아니면 정리 작업을 시작하지 않습니다.
이 작업은 성능 최적화 아카이브의 다른 글들과 이어지고, 사본 정리와 재생성을 서버 작업까지 포함해 한 번에 맡기고 싶다면 최적화 지원 사업에서 다룹니다. 어떤 절차로 진행되는지는 작업 과정에 공개돼 있습니다.
다음 회차
재료가 정리됐으니 이제 그 재료를 쓰는 쪽입니다. 다음 회차는 srcset 과 sizes — 휴대폰이 데스크톱용 이미지를 내려받지 않게 하는 구조입니다.