Чому папка uploads у WordPress така велика

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

Порахуймо

Завантажте одне JPEG розміром 4000×3000 і зазирніть у /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 — 2× версія medium_large
photo-2048x1536.jpg — 2× версія large

Це оригінал плюс сім похідних, і це лише від ядра. Завантаження на 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 — stop generating sizes this site never outputs
add_action( 'init', function () {
    remove_image_size( '1536x1536' );
    remove_image_size( '2048x2048' );
} );

// Drop medium_large too, if your theme doesn't use the 768px size
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 менший за ваш оригінал. Вимкнення big_image_size_threshold нічого не видаляє — воно лише змушує WordPress віддавати кожному відвідувачу повний оригінал на кілька мегабайтів. Це рішення щодо трафіку та якості, а не очищення сховища, і зазвичай воно тільки погіршує вагу сторінки. Інструмент вимкнення масштабованих зображень пояснює, коли це справді доречно; зменшення папки uploads — не той випадок.

Не видаляйте файли безпосередньо з uploads через SFTP. Список підрозмірів кожного вкладеного медіафайлу зберігається в його _wp_attachment_metadata. Видалення файлів вручну залишає биті посилання, а перегенерація не зможе відтворити розмір, якщо ви прибрали оригінал, з якого він походить. Видаліть оригінал — і це зображення зникне назавжди.

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

Не звинувачуйте базу даних. Важка папка uploads — це файли зображень, майже ніколи не БД. Оптимізація таблиць не зрушить це число.

Досі не вдається?

Якщо після перегенерації папка все ще більша, ніж очікувалося, прогоніть ваші реальні розміри зображень і зареєстровані розміри через калькулятор сховища і порівняйте його показник з du -sh wp-content/uploads. Велика різниця означає файли-сироти від старого шаблону (теми) чи видалених записів — не ядро, і не те, що виправить чергова перегенерація. Мала різниця означає, що математика просто така, яка є: сім із гаком файлів на завантаження, які працюють рівно так, як задумано.