Жорик вам правильно сказал, проблемы возникают в практических задачах и в конкретных обстоятельствах, а они могут быть весьма различные.
Приведу такой пример. Был корпоративный сайт и там сделали реализацию с переводом на wepb. Всё было вполне типично - поставил ТЗ программисту реализовать перевод jpg в webp, сделали вариант налету и вроде как нормально. На тот момент как раз набирали обороты по поисковому развитию, но в поиске по картинкам всегда индексировалась только первая титульная картинка.
Потом уперлись в ситуацию, что webp пережимает картинки и там где для широкоформатных фотографиях было важно качество вылезали артефакты сжатия. Потом клиент написал: "Мол, слушайте, а почему при сохранении картинки файл с каким-то странным расширением webp и потом не запускается вместе с остальными картинками?" - пришлось объяснять про webp.
Потом программист написал - может быть на вариант jpg вернемся? Начали вручную с визуальным контролем обрабатывать широкоформатных картинки, оказалось прогрессивное сжатие jpeg визуально лучше и жмёт значимо лучше, чем скриптом webp, откатились назад, обработали картинки, через неделю в поиске по картинкам стали появляться не только титульные, но и другие.
По факту вернулись на jpg. Да, вручную провозились с фотографиями, но оно того стоило, в результате закрыли все волнующие проблемы.
При этом я не хочу сказать, что webp плохо индексируется и ранжируется (были случае когда webp также без проблем индексировались и выводились), возможно так совпало, да и мы на сайте выполнили другую размерность фотографий, словом, зависит от задачи и конкретных рабочих обстоятельств.
Совершенно верно. Решение определяет под задачу и зависит от обстоятельств конкретной задачи.
Возможности формата webp вы без труда сможете найти, а вот ситуации практического применения - здесь случаи бывают разные.
Я например всё чаще имею дело с Битриксом и командным сопровождением, в этом случае прогрессивное jpeg более универсально, ибо там даже фотоколлекция нередко готовится под клиента (и например его контент-менеджера), а в варианте своего личного сайта - готовый плагин налету обрабатывает jpg в wepb (где-то целиком все картинки, где-то выборочно).
Осваивайте работу с Директом, потом расширите свои навыки и до работы с Авито.
Сейчас нужны универсалы, способные обеспечить клиенту трафик, а внутри конкретные рабочих обстоятельств вы уже сами будете решать, чему отдавать предпочтение.
Плюсую. Раньше тоже категорично упирался в webp, но в ситуации, когда это не WP с плагином, а например Битрикс и идёт точечная работа с каждым файлом, и файл надо жать с визуальной оценкой качества, и с граф. файлами работаешь не только ты (а коллеги могут не уметь работать с webp), то лучше использовать прогрессивное сжатие jpeg, где в ряде случаев действительно jpg жмётся лучше (я в своё время был неожиданно удивлён).
Так что всё зависит от рабочих обстоятельств, о которых сказал выше.
Хочу попробовать использовать только webp без jpg.
С какими недостатками можно столкнуться при таком подходе?
Поделитесь своим опытом и мнением.
Это вопрос обстоятельств. Если у вас личный сайт и его настройкой/управлением/развитием занимаетесь только вы, он на WordPress и вам нужен сам факт перевода jpg в webp, то ставьте соответствующий плагин (есть бесплатный) и это самый быстрый и оптимальный путь.
Вариант кастомных решений. Ищите на Кворке умельцев, кто напишет скрипт и под API-ку к AI будут формировать запросы, забирать результаты и раскладывать вам по рабочим папкам.
Если это инфо сайт, то - да, схема рабочая. Если коммерция, то можно внести корректирующие изменения.
Тикет систему пробовали использовать?
Так я и не ставил вопросов. Это обмен мнениями. И я не предлагал меня переубеждать, равно как и у меня нет намерений переубеждать вас, это не более, чем публичное рассуждение, - равно как и у вас :)
Не понял фразы. Наверное кто уже не раз обжёгся?
