Почему папка uploads в WordPress занимает так много места

Папка uploads в WordPress занимает много места, потому что WordPress никогда не хранит по одному файлу на изображение. Каждая загрузка создаёт рядом с оригиналом фиксированный набор уменьшенных копий — семь штук для обычного снимка с камеры, ещё до того как шаблон или плагин добавят свои. Ничего не повреждено; вы просто видите то умножение, которое происходит при каждой отдельной загрузке. Решение — перестать генерировать размеры, которые вы всё равно не отдаёте, а затем пересоздать миниатюры, чтобы старые копии удалились с диска.

Посчитайте

Загрузите одно изображение 4000×3000 JPEG и загляните в /wp-content/uploads/2026/07/. Одного файла вы там не найдёте. Вы найдёте вот что:

photo.jpg — оригинал, нетронутый
photo-scaled.jpg — копия шириной 2560px, которую WordPress отдаёт вместо оригинала
photo-150x150.jpg — thumbnail
photo-300x225.jpg — medium
photo-768x576.jpg — medium_large
photo-1024x768.jpg — large
photo-1536x1152.jpg — размер medium_large в 2×
photo-2048x1536.jpg — размер large в 2×

Это оригинал плюс семь производных, и это только ядро. Загрузка на 3 МБ может лечь на диск как 5–6 МБ, ещё до запуска хоть одного плагина. Теперь добавьте шаблон, который регистрирует четыре собственных размера, и WooCommerce (ещё три) — и одна загрузка превращается в четырнадцать или пятнадцать файлов. Умножьте на медиатеку в несколько тысяч изображений, и размер папки перестаёт быть загадкой.

Если хотите узнать точное число для своих размеров и зарегистрированных вариантов, калькулятор объёма изображений сделает умножение за вас.

Почему так происходит

При загрузке wp_generate_attachment_metadata() вызывает wp_create_image_subsizes(), который перебирает все размеры, возвращаемые get_intermediate_image_sizes(), и записывает по файлу для каждого, который оригинал достаточно велик, чтобы создать. Ядро регистрирует thumbnail, medium, medium_large, large, а также retina-размеры 1536x1536 и 2048x2048, добавленные в WP 5.3. Любой шаблон или плагин, вызывающий add_image_size(), добавляется в тот же цикл — навсегда, для каждой будущей загрузки.

Файл -scaled появляется благодаря отдельному механизму: фильтру big_image_size_threshold, по умолчанию 2560px. Всё, что шире, получает уменьшенную копию, которая становится отдаваемым «полным» изображением, тогда как оригинал остаётся на диске. Так что большая загрузка хранит и гигантский оригинал, и версию на 2560px.

Посмотреть, что именно генерирует ваша настройка для конкретного изображения, можно с помощью инспектора размеров изображений.

Как это исправить, по порядку

1. Сначала измерьте, прежде чем что-либо трогать. Гадать — зря тратить время. Из корня сайта:

du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20

2. Снимите регистрацию с размеров, которые не отдаёте. Большинство шаблонов никогда не выводят размеры 1536 и 2048, а многие вообще не используют medium_large. Уберите их:

// functions.php — перестать генерировать размеры, которые этот сайт никогда не выводит
add_action( 'init', function () {
    remove_image_size( '1536x1536' );
    remove_image_size( '2048x2048' );
} );

// Уберите и medium_large, если ваш шаблон не использует размер 768px
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
    unset( $sizes['medium_large'] );
    return $sizes;
} );

3. Пересоздайте миниатюры, чтобы удалить старые копии. Снятие регистрации лишь останавливает будущую генерацию — файлы, уже лежащие на диске, остаются, пока вы не пересоздадите их:

wp media regenerate --yes

Свежие версии WP-CLI по ходу дела удаляют файлы для размеров, которые больше не зарегистрированы. Если вместо этого вы используете плагин Regenerate Thumbnails, включите его опцию «удалять незарегистрированные размеры» — без этой галочки старые файлы останутся.

4. Отыщите файлы-сироты. Смена шаблона никогда не убирает размеры, которые зарегистрировал старый шаблон. Удаление записей тоже не всегда удаляет их производные. После шага 3, если du -sh всё ещё намного больше того, что предсказывает калькулятор, у вас есть сироты — файлы на диске, на которые не ссылается ни одно вложение.

Чего делать не стоит

Не отключайте scaled-изображения ради «экономии места». Файл -scaled меньше вашего оригинала. Отключение big_image_size_threshold ничего не удаляет — оно лишь заставляет WordPress отдавать каждому посетителю полный многомегабайтный оригинал. Это решение про трафик и качество, а не про очистку диска, и обычно оно только увеличивает вес страницы. Инструмент отключения scaled-изображений объясняет, когда это действительно оправдано; уменьшение папки uploads — не тот случай.

Не удаляйте файлы прямо из uploads по SFTP. Список подразмеров каждого вложения хранится в его _wp_attachment_metadata. Удаление файлов вручную оставляет битые ссылки, а пересоздание не сможет восстановить размер, если вы удалили оригинал, из которого он получен. Удалите оригинал — и это изображение пропало навсегда.

Не выставляйте thumbnail/medium/large в 0 в разделе «Настройки → Медиафайлы» в надежде, что папка уменьшится. Обнуление размера останавливает будущую генерацию, но ничего не трогает из уже лежащего на диске, а интерфейс не может дотянуться до medium_large, 1536, 2048 или любого размера от шаблона/плагина — их там просто нет.

Не вините базу данных. Тяжёлая папка uploads — это файлы изображений, а не БД практически никогда. Оптимизация таблиц не сдвинет это число.

Всё ещё не помогло?

Если после пересоздания папка всё ещё больше ожидаемого, прогоните реальные размеры своих изображений и зарегистрированные варианты через калькулятор объёма и сравните его цифру с du -sh wp-content/uploads. Большой разрыв означает файлы-сироты от старого шаблона или удалённых записей — это не ядро и не то, что исправит очередное пересоздание. Небольшой разрыв означает, что математика такова, какая есть: семь с лишним файлов на загрузку, работающих ровно так, как задумано.