Генерация размеров картинок в wp — смысл?

с учетом того, что wordpress нынче сохраняет картинки с 80% качеством — место на них уходит не так уж много, по сравнению с оригиналами.

Одна загрузка картинки https://yadi.sk/i/4bHkQYeX3LQDXS 152 килобайта, а картинка 73 килобайта. Среднячок по размеру — правда же? А итог в 2 раза больше тупого съеденного места. Математику начнем считать?

На одном сайте у меня в записи было до 50-ти скриншотов (фильмосайт) — подобное поведение привело меня к отказу от вп миниатюр (одну все же резал), и тема ее не регала. Да я проводил замеры как мне лучше и Тимура вариант с его классом меня здорово выручил.

Вот живой пример https://yadi.sk/i/V1jgWoLd3LQEDp — одна запись с фильмом. 53 скриншота (106 файлов) (предполагаю ваш вопрос — lazy load отлично работал и только когда надо миниатюры подгружал). Итог: 4 мегабайта места. Оригинал и миниатюра (необходимая очень). Что было бы еслиб тема фигачила другие размеры? правильно: более 8 мегабайт на запись. А вот скрипт камы нарезал мне в графике кинопремьер и других топ-подборках страниц введеных позже и нарезал он по запросу, а не как вп все подряд — хотя они лежат и не используются.

Знаете — место у меня заканчивалось и платив 200р за хостинг пришлось переходить на 500 р только тупо из-за места. Когда все я переиграл и сделал как писал выше — удалил тупые миниатюры и вернулся на тариф ниже. Ибо не 2000-е платить за то чем не пользуешься.

Я понимаю ваш опыт и прочее — но не нужно спорить что не бывает такой ситуации. Может быть вы не сталкивались с ней.

раздражают дубли уже одним своим присутствием.

🙂 Стесняюсь спросить — а Вы что, регулярно заходите на них любоваться пораздражаться? 🙂
Я вот как-то не припомню, чтобы мне понадобилось лезть на ФТП в uploads, кроме случаев миргации сайтов и то, если с их названиями были проблемы.
Или у Вас на сайте ежедневно появляется по сотне картинок с 20ю миниатюрами к каждой? Тогда, конечно, есть смысл озаботиться. Но не наличием, а правильным распределением.

Означает ли это, что отказ от лишних размеров (как сейчас у меня) лучше, чем генерация адекватных размеров на лету?

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

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

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

а я и отвечал применение:

А вот скрипт камы нарезал мне в графике кинопремьер и других топ-подборках страниц введеных позже и нарезал он по запросу

— топ менялся. График кинопремьер добавлялся — старые 80-х годов фильмы зачем мне под это дело нарезать? Вот и нарезались только 2011-2016 года фильмовые обложки (но опять же только те что имели дату премьеры — и были обязаны попасть в график кинопремьер) да и к старым фильмам только тем что входили в разные топы.

Означает ли это, что отказ от лишних размеров (как сейчас у меня) лучше, чем генерация адекватных размеров на лету?

— тут уж вам решать. Но про процессорное время не слушайте. Это все экономия на спичках если правильно время кеша картинок выставить. А вот лишний груз на диске — будете делать бекап — поймете как сотни тысяч картинок добавят гемороя. а могло же быть на порядок меньше файлов.

Тут спорщики конечно знатные — но опять же я привел реальный пример из практики и скрины к нему, а их же носит по каким то беспочвенным дебрям. Нет бы вовремя спор завершить — но «в интернетах кто-то не прав»

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

и какой гимморой то?
подождать несколько лишних секунд для генерации архива с бэкапом?
или вы папку uploads вручную по ftp качаете что ли?

забавно, конечно, выходит. место на сервере вы экономите, но на процессорное время и I/O кладете с большим прибором.