Половина медиапапки — миниатюры, которые сайт не показывает

Мы считали, сколько тянуть с рабочего сервера на тестовый, и разложили папку медиа одного каталога по типам файлов. Больше половины — 6,39 ГБ из 12 — оказались копиями картинок, которые сайт не показывает нигде.

Это 11-я часть цикла «Сервер для WordPress».

Откуда лишние копии

При каждой загрузке картинки WordPress сразу режет её на все зарегистрированные размеры: свои встроенные и те, что объявила тема через add_image_size(). А наши темы выводят картинки через свой плагин миниатюр с отдельным кэшем, который режет размеры по требованию и сразу в современных форматах. Получалось два комплекта миниатюр, из которых сайт пользовался одним.

Сколько это

Что	Объём	Файлов
вся папка загрузок	12 ГБ
варианты размеров от WordPress	6,39 ГБ	34 485
оригиналы картинок	2,70 ГБ	6 211
видео	1,45 ГБ	124
PDF и прочее	1,10 ГБ	257

По размерам:

Размер	Объём	Кто объявил	Нужен?
975×548	1,64 ГБ	тема	не используется
560×315	0,65 ГБ	тема	не используется
300×169	0,25 ГБ	тема	не используется
1024 (large)	1,58 ГБ	WordPress	проверять
768 (medium_large)	0,97 ГБ	WordPress	проверять
1536	0,20 ГБ	WordPress	проверять
150×150 (thumbnail)	0,15 ГБ	WordPress	нужен админке

Три размера темы — 2,54 ГБ и 15 883 файла — объявлены в functions.php и не читаются нигде: ни функциями вывода миниатюр, ни по имени в коде темы и плагинов.

Как посчитать у себя

U=wp-content/uploads
# сколько весят варианты размеров
find $U -type f -regextype posix-extended -regex '.*-[0-9]+x[0-9]+\.(jpg|jpeg|png|webp|avif)$' \
  -printf '%s\n' | awk '{s+=$1;n++} END {printf "варианты: %.2f ГБ, %d файлов\n", s/1073741824, n}'
# какие размеры плодятся
find $U -type f -regextype posix-extended -regex '.*-[0-9]+x[0-9]+\.(jpg|jpeg|png)$' \
  | sed -E 's/.*-([0-9]+x[0-9]+)\..*/\1/' | sort | uniq -c | sort -rn | head

И поиском по теме и плагинам: add_image_size(, the_post_thumbnail(, wp_get_attachment_image и имена размеров строкой.

Порядок: сначала перестать плодить

1. убрать ненужные размеры из темы, а встроенные отключить фильтром intermediate_image_sizes_advanced. Если сначала удалить файлы, они вернутся с ближайшей загрузкой — у каталога с обменом 1С это ближайшая ночь;
2. удалить накопленное — по метаданным вложений, вычищая из них записи о размерах;
3. проверить, что новая загрузка (у нас — обмен с 1С) больше не создаёт лишних файлов.

add_filter('intermediate_image_sizes_advanced', function ($sizes) {
    foreach (['medium_large', 'large', '1536x1536', '2048x2048'] as $name) {
        unset($sizes[$name]);
    }
    return $sizes; // thumbnail и medium оставляем — их использует админка
});

Что проверить до удаления

• 150×150 нужен админке — медиатека рисует им превью;
• SEO-плагин берёт картинку для og:image. Проверьте, какой размер он отдаёт: curl страница | grep og:image. У нас — оригинал, без суффикса размера;
• поля ACF в формате «массив» отдают sizes со всеми размерами — поищите в шаблонах ['sizes']['имя'];
• выгрузки и фиды для маркетплейсов могут брать конкретный размер;
• удаление файлов не чистит метаданные: если что-то всё же обратится к размеру, получит битую ссылку, а не оригинал. Поэтому удалять нужно вместе с правкой меты вложения.

Результат на другом сайте

На втором каталоге с той же историей за один заход ушли 4,2 ГБ лишних размеров, 2,7 ГБ хвоста от плагина конвертации в WebP, который давно не использовался, и 4,4 ГБ картинок, оставшихся от обмена с 1С без ссылок на них. Свободного места на сервере стало больше на 13 ГБ.