Чому зображення у WordPress виглядають розмитими після завантаження (і як це виправити)

У дев’яти випадках із десяти ваші зображення насправді не розмиті — WordPress зменшив їх під час завантаження й тепер віддає обрізану копію. Починаючи з WordPress 5.3, будь-яке зображення, ширше або вище за 2560px, без попередження замінюється на версію -scaled, обмежену 2560px по довшій стороні, і саме цей менший файл ваш шаблон (тема) розтягує, щоб заповнити hero-блок, повноширинний блок або retina-дисплей. Виправлення полягає в тому, щоб довести, що сталося саме це, а потім або підняти поріг, або перестати завантажувати зображення, яким потрібно бути більшими за блок, у якому вони розташовані.

Чому це відбувається

Коли ви завантажуєте фото, WordPress запускає wp_create_image_subsizes() (у wp-admin/includes/image.php). Якщо довша сторона перевищує big_image_size_threshold — за замовчуванням 2560px — викликається _wp_image_meta_replace_original(), генерується your-photo-scaled.jpg, і метадані вкладення переписуються так, що розмір full тепер вказує на зменшену копію. Ваш справжній оригінал зберігається на диску як your-photo.jpg і на нього посилається wp_get_original_image_path(), але жоден елемент на фронтенді його не віддає. Кожен проміжний розмір і кожен кандидат srcset генерується зі зменшеного файлу 2560px, а не з того, що ви завантажили.

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

Інша половина тієї ж проблеми — це srcset, який обирає надто малий розмір. Якщо ваш шаблон (тема) повідомляє ширину контенту, що не відповідає реальному відрендереному блоку, WordPress віддає браузеру проміжний файл -1024x683 або -1536x1024, і той розтягується. Причина та сама — блок відображення більший за наявні пікселі — але тригер інший.

Перевірте, що WordPress насправді віддав

Не вгадуйте. Клацніть правою кнопкою по розмитому зображенню, відкрийте його в новій вкладці й подивіться на ім’я файлу в URL. Якщо воно закінчується на -scaled.jpg або суфікс із розмірами на кшталт -1024x683.jpg, ви це підтвердили: браузер рендерить зменшену похідну, а не ваше завантаження. Ви також можете перевірити елемент і прочитати currentSrc, щоб побачити, який саме кандидат обрав браузер.

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

На сервері ви можете вивести список усіх обрізаних файлів:

find wp-content/uploads -name '*-scaled.*'

Як це виправити, по порядку

1. Якщо вашим зображенням справді потрібно бути більшими за 2560px (великі hero-блоки, retina, галереї друкарської якості), підніміть поріг:

// functions.php or a small mu-plugin
add_filter( 'big_image_size_threshold', function () {
    return 3840; // longest edge, in pixels
} );

Або вимкніть обмеження повністю:

add_filter( 'big_image_size_threshold', '__return_false' );

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

3. Якщо ваше джерело вже ≤2560px і все одно розмите, проблема не в порозі — блок відображення більший за зображення. Завантажте більше джерело або зменшіть контейнер. Для retina-чіткості ваше джерело має бути приблизно вдвічі ширшим у CSS-пікселях за блок, який воно заповнює.

4. Тільки після наведеного вище повторно згенеруйте мініатюри, щоб проміжні розміри були узгодженими — але розумійте, що це прибирання, а не ліки.

Чого не варто робити

Не викручуйте якість JPEG на 100. WordPress стискає до якості за замовчуванням 82 через wp_editor_set_quality, і половина порад в інтернеті радить вам це перевизначити:

add_filter( 'wp_editor_set_quality', function () { return 90; } );

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

Не вимикайте -scaled рефлекторно. Вимкнення обмеження (для цього є інструмент) — правильне рішення, якщо ви віддаєте зображення понад 2560px, але якщо ваша справжня проблема в тому, що розтягується надто малий проміжний файл, вимкнення нічого не змінить, і ви без причини втратите економію трафіку. Спершу діагностуйте.

Не звинувачуйте кеш і не генеруйте мініатюри першими. Регенерація читає з того ж обрізаного джерела, тож не може відновити деталі. Очищення CDN чи кешу сторінок не торкнеться файлу, який від початку був малим на диску.

Не хапайтеся за CSS шаблону (теми) чи object-fit. Жодне стилізування не додає пікселів. Якщо віддане ім’я файлу закінчується на -scaled або суфікс із розмірами, проблема у файлі, а не в розмітці.

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

Якщо ви підтвердили, що відданий файл — це ваше завантаження в повній роздільній здатності — без -scaled, без суфікса з розмірами — а воно все одно м’яке, перевірте, чи не переписує якийсь плагін ваш src на стиснений проксі (оптимізатор, CDN-ресайзер зображень або бібліотека відкладеного завантаження). Прогоніть зображення через інструмент розмірів зображень, щоб підтвердити, що WordPress має генерувати, а потім порівняйте це з тим, що браузер насправді завантажує. Коли ці два не збігаються, винуватець — щось між WordPress і браузером.