Як вимкнути -scaled зображення у WordPress (big_image_size_threshold)

Додайте фільтр на big_image_size_threshold, який повертає false, і WordPress перестане створювати -scaled копії під час завантаження. Поверніть число — і ви піднімете ліміт, а не приберете його. І те, і те кладеться у functions.php або в невеликий mu-plugin, і в обох випадках зміна діє лише на завантаження, зроблені після того, як фільтр запрацював.

// Disable the cap entirely — no -scaled copies at all.
add_filter( 'big_image_size_threshold', '__return_false' );

// Or just raise it. Longest edge, in pixels.
add_filter( 'big_image_size_threshold', function () {
    return 3840;
} );

Що насправді робить WordPress

Починаючи з WordPress 5.3, кожне завантаження вимірюється по довшій стороні. Якщо ця сторона більша за big_image_size_threshold — з коробки це 2560px — WordPress перекодовує зображення до цього ліміту, зберігає його як your-photo-scaled.jpg і переписує метадані вкладення так, що розмір full тепер вказує на зменшену копію.

Ваш оригінал не видаляється. Він лишається на диску під початковим іменем, записаний у метаданих вкладення, і доступний у PHP через wp_get_original_image_path(). Але на фронтенді його ніхто не віддає. Ні блоковий редактор, ні srcset, ні прев’ю в медіабібліотеці. Він просто лежить як архівна копія.

Усе далі по ланцюжку генерується зі зменшеного файлу, а не з того, що ви завантажили:

Розмір	З чого будується
full	копія -scaled
large, medium_large, medium, thumbnail	копія -scaled
Власні розміри з add_image_size	копія -scaled
Розміри шаблонів і плагінів, напр. woocommerce_thumbnail	копія -scaled
Кандидати srcset	копія -scaled

Саме цей факт і збиває з пантелику стількох людей.

Чому це звична причина скарги «моє чітке фото виглядає розмитим»

Одночасно відбуваються дві речі, і очевидна лише одна з них.

Очевидна — це роздільність. Ви завантажуєте фото на 4000px для героя на всю ширину. WordPress віддає браузеру 2560px. На звичайному екрані з контейнером у 1600px цього ніхто не помітить. На retina-екрані з подвійною щільністю той самий контейнер хоче приблизно 3200 реальних пікселів, отримує 2560, і браузер розтягує різницю. М’які краї, каша в деталях, розпливчастий текст усередині зображення.

Менш очевидна — перекодування. Копія -scaled не є обрізанням вашого файлу без втрат. WordPress декодує ваше завантаження, змінює розмір і стискає заново зі своїм власним налаштуванням якості JPEG. Якщо ваш оригінал уже був стиснутим JPEG з Lightroom чи телефона, це кодування другого покоління: артефакти стиснення поверх артефактів стиснення. Найбільше страждають дрібні деталі, зерно плівки й рівні градієнти. Це видно навіть тоді, коли розміри в пікселях виглядають достатніми.

Переконайтеся в цьому, перш ніж щось міняти. Відкрийте зображення в новій вкладці й подивіться на ім’я файлу в адресі. -scaled.jpg означає, що ліміт спрацював. Суфікс із розмірами, як-от -1536x1024.jpg, означає зовсім інше — srcset обрав завеликий проміжний розмір, і фільтр порогу тут не допоможе.

На сервері:

find wp-content/uploads -name '*-scaled.*' | wc -l

Якщо число велике, ліміт формував усю вашу бібліотеку.

Ще можна закинути файл у інструмент для вимкнення scaled зображень і побачити, чи конкретне джерело перетне поріг і в яких розмірах опиниться зменшена копія — ще до того, як ви оберете налаштування.

Чесний компроміс

Більшість статей каже, що вимкнення ліміту коштує місця на диску. Це навпаки, і тут варто бути точним.

Місце на диску на одне зображення трохи зменшується. З увімкненим порогом WordPress зберігає ваш оригінал і велику зменшену копію. З вимкненим у вас лишається тільки оригінал. Один файл замість двох.

Трафік і вага сторінки зростають, іноді суттєво. Зі знятим лімітом full — це ваше недоторкане завантаження. Усе, що посилається на повний розмір або рендерить його — лайтбокс, плагін галереї, посилання «переглянути оригінал», шаблон, який просить full для героїв — тепер віддає файл, який може важити 6MB замість 900KB. На мобільних це реальна проблема з Largest Contentful Paint, і CDN для зображень не завжди врятує, бо деякі з них пропускають файли понад певний розмір без обробки.

Споживання пам’яті під час завантаження зростає. Зміна розміру зображення на 6000px у PHP потребує значно більше пам’яті, ніж на 2560px. На дешевому шаредному хостингу з низьким лімітом пам’яті PHP вимкнення ліміту — цілком реальний спосіб почати ловити невдалі завантаження чи частково згенеровані мініатюри. Підняти поріг до 3840 замість того, щоб прибирати його, — безпечніша версія тієї самої зміни.

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

Як правильно застосувати зміну

1. Покладіть фільтр туди, де він виживе. functions.php у дочірній темі підходить. Однофайловий mu-plugin кращий, бо зміна шаблону не зможе тихо його скасувати.

<?php
/**
 * Plugin Name: Raise big image threshold
 */
add_filter( 'big_image_size_threshold', function () {
    return 3840;
} );

2. Завантажте уражені зображення заново. Це той крок, який пропускають, а потім вирішують, що фільтр не спрацював. Поріг перевіряється один раз — під час завантаження. Наявні вкладення назавжди зберігають свої старі метадані. Видаліть вкладення, завантажте його ще раз, а потім поправте посилання у своїх записах.

3. Не сподівайтеся, що перегенерація мініатюр щось урятує. wp media regenerate через WP-CLI перебудовує проміжні розміри з того файлу, який метадані називають повним, — а для вже обрізаного зображення це копія -scaled. Відновити відкинуті деталі вона не може. Корисна як прибирання після повторного завантаження. Марна як самостійне рішення.

4. Перевіряйте результат, а не припускайте його. Після повторного завантаження відкрийте зображення на фронтенді й ще раз подивіться на ім’я файлу. Немає -scaled — фільтр працює.

Коли вимикати не варто

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

Якщо в імені відданого файлу стоїть суфікс з розмірами, а не -scaled, то srcset обрав замалого кандидата. Зазвичай це розбіжність між оголошеною шириною контенту у вашому шаблоні й тим блоком, у якому зображення реально рендериться. Вимкнення ліміту тут не змінює нічого.

А якщо якийсь плагін переписує ваш src на оптимізатор чи проксі CDN, усе це не має значення, доки ви не перевірите, що саме віддає той проксі. Порівняйте те, що WordPress мав би генерувати, з тим, що браузер справді завантажує; коли ці дві речі не збігаються, дивіться, що стоїть між ними.