Как отключить -scaled изображения в WordPress (big_image_size_threshold)

Добавьте фильтр на big_image_size_threshold, возвращающий false, — и WordPress перестанет создавать копии -scaled при загрузке. Верните вместо этого число — и вы поднимете порог, а не уберёте его. Оба варианта кладутся в functions.php или в маленький mu-плагин, и оба действуют только на загрузки, сделанные после включения фильтра.

// 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 этого никто не заметит. На ретине с двойной плотностью тому же блоку нужно примерно 3200 реальных пикселей, он получает 2560, и браузер растягивает недостающее. Мягкие края, каша в деталях, расплывающийся текст внутри картинки.

Менее очевидная — повторное сжатие. Копия -scaled — это не сжатие без потерь. WordPress декодирует вашу загрузку, уменьшает её и заново сжимает со своим уровнем качества JPEG. Если оригинал уже был сжатым JPEG из Lightroom или с телефона, получается кодирование второго поколения: артефакты поверх артефактов. Сильнее всего страдают мелкие детали, зерно и плавные градиенты. Это видно даже тогда, когда пикселей формально хватает.

Убедитесь в диагнозе, прежде чем что-то менять. Откройте изображение в новой вкладке и посмотрите имя файла в адресной строке. -scaled.jpg означает, что порог сработал. Суффикс с размерами вроде -1536x1024.jpg означает другое: srcset выбрал слишком мелкий промежуточный размер, и фильтр порога тут не поможет.

На сервере:

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

Если число большое, порог формировал всю вашу медиатеку.

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

Честный размен

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

Место на диске на одну картинку немного уменьшается. С включённым порогом WordPress хранит и оригинал, и крупную уменьшенную копию. Со снятым — только оригинал. Один файл вместо двух.

Трафик и вес страницы растут, иногда сильно. Со снятым порогом full — это ваша нетронутая загрузка. Всё, что ссылается на полный размер или выводит его — лайтбокс, плагин галереи, ссылка «посмотреть оригинал», тема, запрашивающая full для обложек, — теперь отдаёт файл, который может весить 6 МБ вместо 900 КБ. На мобильных это реальная проблема с Largest Contentful Paint, и картиночные CDN спасают не всегда: часть из них пропускает файлы напрямую, если те больше определённого размера.

Расход памяти при загрузке растёт. Обработка изображения 6000px в PHP требует заметно больше памяти, чем 2560px. На дешёвом шаред-хостинге с низким лимитом памяти PHP снятие порога — вполне рабочий способ начать получать сбои при загрузке или недоделанные миниатюры. Поднять порог до 3840, а не убирать его совсем, — более безопасная версия того же изменения.

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

Как применить изменение по-человечески

1. Положите фильтр туда, где он выживет. functions.php в дочерней теме подойдёт. Mu-плагин из одного файла лучше, потому что смена темы не сможет молча его отключить.

<?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 должен генерировать, с тем, что реально грузит браузер; если они расходятся — смотрите на то, что стоит между ними.