Ускорение сайта на вордпресс

А пункт а) в моём ответе Вы прочитали :) ?

Я так и написал же что это одна из причин почему я конвертацию на лету и не использую.

Вот зачем это допускать, если этого в реальности нет (в см если нормально оптимизировать jpg/png)? Да, при весе страницы в пару метров может и будет профит на десяток кб. Но как-то смешно об этом говорить. А уж если вспомнить всякие скрипты и стили..

? Ты о чем?

Там особых проблем не вижу. Уносите файлы webp из проекта на другой рут, эти файлы не попадают в бекап. При первом обращении скриптом создаете из оригинала и пишете в рут для вебп. Второе обращение - статичный файл.

  server_name ~^(.*?)\.?(?<d_name>[^\.]+)\.lcl$;

  set			$sub_name   	$1;

  root    /var/www/$d_name/public;

....

  location @nowebp {

    include uwsgi_params;

    uwsgi_pass unix:///run/uwsgi/semantic.sock;

  }  

  location ~\/(.*)\.webp$ {

    root    /var/www/webp;

    try_files $uri @nowebp;

  }

В вышеприведенном питон обработает. У меня Фласк предсказуемо сказал Not Found для этого роута. Но никто не мешает строк несколько дописать и что то сделать, сказав в результате другое и любой контент/контент-тайп отгрузить. А чтобы переконвертить в вебп не так то много строк надо (подставить вместо пхп, то что удобнее).

Потенциальные риски: атака, когда кто то 100500 рандомных вебп попросит. Но, тут тоже варианты есть, их надо предусмотреть.

danforth, это же реализовано?

Я принимал решение по вебп так:

- штук, точно не помню, но 3-значное картинок из загрузок, сгруженного с телефона сжал в одну папку, конвертировал в вебп в другую. Сравнил размеры. Вебп победил. Но, не очень то и существенно.

- попытался открыть (на центосе сижу) , хрен ни один из вьюверов поставленных не справился. Гимп? И тот не але.

Посчитал, что пока рано. Но, это было давно. Может сейчас по другому 🍿

Нельзя судить по нескольким картинкам. Особенно, если они в качестве 90+, где webp лажает, но оно и не для веба.

Я давал цифры реального юзанья:

Вдали от роутера мобилы бывает тормозят нещадно. Если хочется с них поиметь по максимуму, а картинки весят прилично, и не в 90+ качестве, то разумно глянуть в сторону webp. Почти бесплатно можно ускорить загрузку.

Не у всех сервера порнухой забиты. :)

Я 4 храню, ну или сколько в конфе пропишут

  'thumbs' => [
        'xs'         => '200x150', /* thumbs xsmall - phones       (<768px)) */

        'sm'         => '300x200', /* thumbs small - tablet        (≥768px, <992px) */

        'md'         => '400x300', /* thumbs medium - desctop      (≥992px, <1200px) */

        'lg'         => '600x450', /* thumbs large - large-desctop (≥1200px,) */

        #'web'        => '800x533'  /*   */

  ],

У себя! Не забывай, что "рекомендации" читаются теми в тч у кого не просто шаред, а и квалификация уровня "нажать кнопки в админке".

Но и у себя - нафига эти извращения (и это ж доп риски) я плохо представляю. Нет, не отрицаю что где-то может и есть целесообразность таких инкрементных бекапов, но я просто не вижу смысла. Вот пытаюсь, но не нахожу.

ВООТ!! Вот же в чем фикус-пикус! И зачем, спрашивается, делать 2 разных формата, раздувать копиями диски (и не забывай про миниатюры), париться и рисковать с бекапами, городить подмены форматов и тд. если профита в доли процента суммарно у весу страницы.

Дурная работа, риски, расходы.

---------- Добавлено 26.02.2020 в 22:25 ----------

Разумно - это оптимизировать jpg и показывать миниатюры, а не масштабируемые картинки.

А 90 для веба явно дофига. Иногда и 65 хватает. Хотя я чаще ориентируюсь на 75-80.

Цифры выше - максимально ужатые картинки и thumbs.

В таком случае webp и дает результат подобный моему.

Ещё раз - это ты думаешь что максимально ужатые. А как оно на самом деле... Я уверен что если их нормально оптимизировать, что будет приблизительно так::

А может даже webp и проиграет.

В таком случае webp лишний :) О том и речь. Причем "лишний" не просто как "пустое место", а именно как "лишний груз".

Реализация ленивой конвертации вы выше правильно скинули, она делается через fallback location nginxа.

На том сайте который я кидал в этой теме для примера такого нет, для демонстрации я скачал несколько картинок, и просто в консоли циклом конвертнул их в webp. Сам nginx настроен по другому:

map $http_accept $webp_suffix {
        default         "";
        "~*webp"        ".webp";
}

location /images/ {
         try_files $uri$webp_suffix =404;
}

А файлы лежат по схеме:

/images/image.png
/images/image.png.webp
...

Любая атака на холодный кеш точно так же работает. Если злоумышленнику получится найти 100500 несконвертированных картинок, и он по ним пойдет, то да, будет плохо. Но есть множество способов как положить неподготовленный сервер и без этих ухищрений. А подготовленная команда разработчиков если и будет делать сброс кеша и файлов, то она точно знает как это правильно сделать.

Вот ради интереса на одном из серверов отключил webp, второй оставил с webp для сравнения, разница в трафике видна на картинке. На графике мегабайты (не мегабиты), таких серверов у нас 30+ штук. В пике они отдают 100МБ/сек. Экономию можете посчитать сами.

Много ума не требуется, чтобы джипеги сжать. И если хоть капельку недожмешь, то тот же Pagespeed ругаться будет.

Webp не для хранения фоток с телефона, с десятками мегапикселей и почти лосслесс качеством.