![Ускорение Сайтов :: Метод Лаб](/img/default-banner.jpg)
- 217
- 410 804
Ускорение Сайтов :: Метод Лаб
Russia
Приєднався 25 сер 2011
Этот канал посвящён производительности сайтов. На канале вы можете узнать, как корректно измерить скорость сайта и что делать потом с полученными результатами. А для настоящих фанатов скорости, я регулярно выпускаю ролики про новые техники оптимизации производительности, хитрые хаки, неожиданные трюки, неочевидные твики. Подписывайтесь, делитесь видео, оставляйте свое мнение в комментариях!
Насколько тормозит Docker? Тестируем сетевые режимы
Решили выяснить, какие накладные расходы добавляет Docker в различных сетевых режимах для сетевого приложения. Для теста мы взяли веб-сервер Angie и запустили его из пакета (в хостовой ОС) и в двух вариантах контейнеров: bridge-сеть и хостовая сеть (host).
Далее провели быстрый тест производительности. Результаты получили очень интересными.
Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml
Администрирование Linux-серверов: www.methodlab.ru/support/administrirovanie_serverov
Профессиональная поддержка сайтов: www.methodlab.ru/price/support.shtml
Тестирование скорости сайтов: xn--80aanaoiczhuihpc.xn--p1ai/
Сервис оптимизации картинок: www.fotorubka.ru/
Наш второй канал "Поддержка сайтов": ua-cam.com/channels/f1P_nESQ6hPlTwkH5Vik1A.html
Метод Лаб в Telegram: t.me/methodlab_tg
Группа "Ускорение сайтов" в VK: sitespeedup
Метод Лаб в VK: methodlab
Метод Лаб в Rutube: rutube.ru/channel/24617406/
Метод Лаб в Дзен: dzen.ru/method_lab
Далее провели быстрый тест производительности. Результаты получили очень интересными.
Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml
Администрирование Linux-серверов: www.methodlab.ru/support/administrirovanie_serverov
Профессиональная поддержка сайтов: www.methodlab.ru/price/support.shtml
Тестирование скорости сайтов: xn--80aanaoiczhuihpc.xn--p1ai/
Сервис оптимизации картинок: www.fotorubka.ru/
Наш второй канал "Поддержка сайтов": ua-cam.com/channels/f1P_nESQ6hPlTwkH5Vik1A.html
Метод Лаб в Telegram: t.me/methodlab_tg
Группа "Ускорение сайтов" в VK: sitespeedup
Метод Лаб в VK: methodlab
Метод Лаб в Rutube: rutube.ru/channel/24617406/
Метод Лаб в Дзен: dzen.ru/method_lab
Переглядів: 2 392
Відео
Zstd (Zstandard): новый стандарт сжатия текста. Полный тест
Переглядів 1,1 тис.4 місяці тому
Новый стандарт сжатия текстовых ресурсов Zstd (Zstandard): может ли он заменить Gzip и Brotli? Как его стоит применять на практике? В этом видео ответим на эти вопросы на основе тестов с помощью веб-сервера Angie. Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml Администрирование Linux-серверов: www.methodlab.ru/support/administrirovanie_serverov Профессиональная поддерж...
Jpegli: новая библиотека для оптимизации JPEG-изображений
Переглядів 8294 місяці тому
Недавно появилась новая библиотека для сжатия изображений в старый добрый формат JPEG. Ранее мы уже делали обзоры на MozJPEG и другие инструменты оптимизации, но Jpegli является продуктом разработки (внезапно!) JPEGXL. То есть сам формат в веб не пошёл, но его плоды всё еще полезны. Или нет? Разберёмся подробно в нашем обзоре. Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.s...
Причина торможения PHP в Битриксе
Переглядів 9597 місяців тому
Столкнулись с интересным случаем торможения PHP для Битрикса. На этот раз всё оказалось не так тривиально, как обычно. Источник проблемы удалось найти с помощью утилиты perf и сравнительного анализа с тестовым сервером. Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml Администрирование Linux-серверов: www.methodlab.ru/support/administrirovanie_serverov Профессиональная п...
Почему тормозит событие load?
Переглядів 5328 місяців тому
Интересный случай из практики ускорения сайтов. По данным WebPageTest нет никаких проблем, но событие Load наступает на 30 секунд позже, чем должно. Разбираемся, почему это может быть проблемой и как её решать. Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml Администрирование Linux-серверов: www.methodlab.ru/support/administrirovanie_serverov Профессиональная поддержка ...
Новый веб-сервер Angie: brotli из коробки
Переглядів 1,2 тис.10 місяців тому
Посмотрим на новый веб-сервер Angie, который создан на базе форка Nginx оригинальными разработчиками Nginx. Что интересно, при полной совместимости теперь мы можем поставить готовые пакеты сторонних модулей из репозитория Angine, в том числе и модули для поддержки Brotli. Сайт Angie: angie.software/ Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml Администрирование Linux...
Как мы ускоряем сайты в Метод Лаб
Переглядів 864Рік тому
В этом видео мы расскажем свой подход к ускорению сайтов. Ролик будет полезен заказчикам и ответит на многие вопросы перед заказом услуги. Настоящее ускорение сайтов: www.methodlab.ru/price/uskorenie_sajta.shtml Администрирование Linux-серверов: www.methodlab.ru/support/administrirovanie_serverov Профессиональная поддержка сайтов: www.methodlab.ru/price/support.shtml Тестирование скорости сайто...
Тормозека: почему тормозит сайт Бризекс?
Переглядів 468Рік тому
Рассмотрим очередной сайт коммерческой компании с точки зрения скорости. Найдём основные проблемы, проведём быстрое тестирование. На этом канале мы создаём максимально полезные видео по вопросам ускорения сайтов, веб-производительности и клиентской, а также серверной оптимизации. Профессионально занимаясь ускорением сайтов, мы накопили значительный опыт, которым готовы поделиться с нашими зрите...
JPEG XL - новый король форматов?
Переглядів 1,1 тис.Рік тому
Продолжаем разбирать новые форматы сжатия изображений. На этот раз изучим JPEG XL - новую версию самого популяного формата для фотографий. JPEG XL имеет полный набор возможностей: прозрачность, анимация, сжатие без потерь и с потерями, прогрессивная загрузка. Сможет ли новый формат конкурировать с WebP и AVIF? На этом канале мы создаём максимально полезные видео по вопросам ускорения сайтов, ве...
PageSpeed Insights: что нового в 2023 году?
Переглядів 2,5 тис.Рік тому
Вовращаемся с подробным обзором популярного инструмента тестирования скорости от Google: PageSpeed Insights. Посмотрим, что изменилось в последнее время и критически посмотрим на результаты его работы. pagespeed.web.dev/ На этом канале мы создаём максимально полезные видео по вопросам ускорения сайтов, веб-производительности и клиентской, а также серверной оптимизации. Профессионально занимаясь...
Обработка картинок в Nginx image filter module
Переглядів 1,4 тис.Рік тому
В этом видео поговорим про обработку фото средствами Nginx. На этом канале мы создаём максимально полезные видео по вопросам ускорения сайтов, веб-производительности и клиентской, а также серверной оптимизации. Профессионально занимаясь ускорением сайтов, мы накопили значительный опыт, которым готовы поделиться с нашими зрителями и подписчиками. Так что присоединяйтесь, будет интересно! Професс...
Chrome DevTools: обзор и новые возможности в 2022 году
Переглядів 2,9 тис.Рік тому
В этот раз возвращаемся к основам: анализу скорости сайтов в средствах разработчика браузера Chrome - DevTools. Здесь мы найдём большинство нужных средств анализа, диагностики и измерения различных метрик по скорости. Конечно, нам интересны изменения в инструменте Lighthouse как с точки зрения советов, так и метрик скорости сайтов. Посмотрим, что нового нам предлагает современная версия Chrome ...
MySQL 8.0: используем индексы для оптимизации. Часть 2
Переглядів 1,5 тис.2 роки тому
Продолжаем разбираться с индексами в MySQL 8.0. Погружаемся в тему глубже. Для тех, кто пропустил первую часть, ссылка указана ниже. Первая часть: ua-cam.com/video/mDpM2yjKGNU/v-deo.html На этом канале мы создаём максимально полезные видео по вопросам ускорения сайтов, веб-производительности и клиентской, а также серверной оптимизации. Профессионально занимаясь ускорением сайтов, мы накопили зн...
Собираем контейнер оптимизатора изображений
Переглядів 7752 роки тому
В процессе ускорения сайтов важный этап это оптимизация изображений. Необходимо использовать лучшие кодировщики для традиционных форматов (JPEG, PNG) и генерировать копии для современных (AVIF, WebP). В этом видео мы собираем образ контейнера Docker, который содержит наш оптимизатор и все необходимые компоненты. Не забывайте писать свои вопросы в комментариях. Попробовать оптимизацию картинок: ...
Быстрый анализ серверной скорости сайта
Переглядів 1,9 тис.2 роки тому
В этом видео разберём основные приёмы быстрого анализа серверной части веб-серера для оценки потенциальных проблем. Рассмотрим набор простых инструментов для поиска проблем и диагностики серверной производительности для ускорения работы сайтов. На этом канале мы создаём максимально полезные видео по вопросам ускорения сайтов, веб-производительности и клиентской, а также серверной оптимизации. П...
MySQL 8.0: используем индексы для ускорения запросов
Переглядів 7 тис.2 роки тому
MySQL 8.0: используем индексы для ускорения запросов
WebPageTest: новая версия лучшего теста скорости сайтов
Переглядів 1,3 тис.2 роки тому
WebPageTest: новая версия лучшего теста скорости сайтов
AVIF и WebP: cкорость декодирования новых форматов
Переглядів 1,4 тис.2 роки тому
AVIF и WebP: cкорость декодирования новых форматов
Тестируем Nginx c HTTP/3 и QUIC с доработками от VK.com
Переглядів 3,1 тис.2 роки тому
Тестируем Nginx c HTTP/3 и QUIC с доработками от VK.com
ProxySQL: быстрый кэш запросов в MySQL 8.0 и не только
Переглядів 3 тис.2 роки тому
ProxySQL: быстрый кэш запросов в MySQL 8.0 и не только
Автоматическая оптимизация изображений fotorubka.ru (с AVIF)
Переглядів 5912 роки тому
Автоматическая оптимизация изображений fotorubka.ru (с AVIF)
Прорыв в сжатии AVIF-картинок новый libavif
Переглядів 1,5 тис.3 роки тому
Прорыв в сжатии AVIF-картинок новый libavif
Обзор CDN-сервиса G-Core Labs для ускорения сайта
Переглядів 1,8 тис.3 роки тому
Обзор CDN-сервиса G-Core Labs для ускорения сайта
Какие метрики скорости сайта влияют на SEO?
Переглядів 8813 роки тому
Какие метрики скорости сайта влияют на SEO?
Веб-сервер OpenLiteSpeed - лучше Nginx?
Переглядів 2,4 тис.3 роки тому
Веб-сервер OpenLiteSpeed - лучше Nginx?
Как CDN Cloudflare и CDNVideo экономят на ускорении ваших сайтов
Переглядів 1,7 тис.3 роки тому
Как CDN Cloudflare и CDNVideo экономят на ускорении ваших сайтов
Фейковые баллы в Google PageSpeed: очередной развод на скорости сайтов
Переглядів 2,1 тис.3 роки тому
Фейковые баллы в Google PageSpeed: очередной развод на скорости сайтов
Сервис GTmetrix: стоит ли ему доверять тест скорости?
Переглядів 7353 роки тому
Сервис GTmetrix: стоит ли ему доверять тест скорости?
Кодер CAVIF: эффективное сжатие в AVIF, сравниваем с WebP
Переглядів 4993 роки тому
Кодер CAVIF: эффективное сжатие в AVIF, сравниваем с WebP
Ruby on Rails: как затормозить сайт на ровном месте
Переглядів 6313 роки тому
Ruby on Rails: как затормозить сайт на ровном месте
Подскажите пожалуйста, в ГА4 тоже есть такая возможность или можно что-то подобное настроить?
3:56
Очень годный материал, спасибо
Познавательно, спасибо.
Спасибо Николай!
да он и без сетевых нехило так тормозит...
Интересно, что у меня результаты отличаются ровно наоборот, но я использовал go-wrk, надобно еще поэкспериментировать, пока не нашел сильной разницы между сетями
Тут еще зависит от того какие настройки сети у вас в KVM? Потому что, по-умолчанию он эмулирует сетевуху rtl8139. И у вас из-за этого могут быть такие потери в производительности. Например, VMWare с сетью VMXNET3, использует маппинг памяти сетевого буфера виртуальной сетевухи между виртуалками и вы ограничены только скоростью обмена с памятью.
В этом тесте в сетевуху виртуалки результаты не упирались. Ну и для всех вариантов настройки виртуалки были одинаковыми, так что они здесь ни при чем.
очень полезное, такое бы еще для кубера помареть)
Спасибо за тест. Было бы интересно увидеть сравнение так же с docker rootless kit и macvlan-сетью. Вангую рутлес будет худшим.
интересно посмотреть на вариант если Коннект делать Unix domain socket (IPC) . В докер и без, это актуально если сервисы как в твоём случае на одной машине.
Unix-сокеты как-то тестировал, они немного быстрее, но не радикально.
Это еще что... а когда выносят mysql на отдельный хост или дисковую систему на СХД по сети. Удобно, модно, молодежно... ну да, сайт дико тормозит, что поделать :] Нет ничего быстрее, чем когда все локально, безо всяких KVM и докеров, напрямую работает. И mysql конечно только через сокеты. А еще tmp системную, tmp nginx и mysql можно делать на RAM-диск, можно логи даже писать на RAM-диск (если памяти конечно много имеется). Если сайтов не пара штук, а сотни, то лучше их делить на отдельные процессы apache/php/mysql чтобы всем более-менее равномерно доставалось всех кэшей. А не так (как к примеру обычно на shared хостингах) что одна гигантская mysql на тысячи сайтов и более посещаемые всегда перетягивают одеяло на себя, а менее посещаемые получаются почти всегда с "холодным стартом". С php opcache та же история.
Каким образом картинки приоретизируются?
Всёж не хватает для сравнения тестов под вирталкой(kvm).... А если касаться только сети, то так же бы не помешало проверить такие вещи как: macvlan, net namespace etc...
Что значит тестов под вирталкой? В этом тесте все работало уже в вируалке kvm.
@@NickLavlinsky ну я имел ввиду host vs виртуалка...
Да, это тоже можно протестировать.
Спасибо за обзор! К тестам напрашивается один вопрос - а на каком уровне дополнительной нагрузки потери становятся незначительными если это вообще происходит.
Большое спасибо за видео. Хотелось бы видеть от Вас тест производительности mysql также в контейнере и без, может даже в связке с php.
Сделаем.
Ежу понятно, что любая дополнительная операция требует процессорного времени. Попробуйте еще кубернетес. Докер и кубер были созданы для удобства - за удобство надо платить. Все логично и понятно
Да, вопрос в том, какого времени требует изоляция в контейнерах. Заявляется, что менее 10%.
Впринципе что и надо было доказать. Спасибо!
Примитивный тест на статике. Основная часть запросов это запросы к бизнес логике или базе. Какая разница как тормозит сервис по раздаче статики. Если статика это 10% от общего числа запросов. В чем смысл этих тестов? Экономия на спичках? У всего есть накладные расходы. Вопрос в том готов ты их платить или нет. Вы ещё протестируйте оверхед от виртуализации ))) а потом скажете что все лучше ставить на голом железе, только вот докер и кубер другую проблему решали
Конечно на голом железе лучше. Вопрос в том, насколько лучше. В этом и смысл тестов.
У сервисов раздачи статики обычно гораздо больше запросов чем у бизнес логики. Глупо игнорировать потребление этих ресурсов. К тому же скорость загрузки статики влияет на бизнес метрики, например даже самый быстрый сайт не начнет работать пока не загрузится его js скрипты.
Такие "примитивные" тесты как раз и нужны чтобы оценить этот оверхед и понять где экономия на спичках, а где уже серьезный импакт по бизнесу
Неожиданный результат. Я думал что докер привносит некоторые задержки, ну на 5-10% процентов. Но эти результаты меня удивили. А ведь я недавно спорил со своим коллегой, что докер привносит мизерную задержку. Я получается, был не прав??
Для меня тоже неожиданный. Я думаю здесь дело в типе нагрузки. В этом тесте мы минимально грузили процессор и больше тестировали системные вызовы. Видимо в этом сценарии накладные расходы становятся высокими в процентах.
Спасибо, интересно
еще бы такой же тест для Mariadb внутри Docker контейнера. Популярное решение на ispmanager - когда он изначально был установлен на с mysql 8. А проект нужно в рамках этого же сервер без переустановки - перенести на mariadb )
Без проблем, будем делать видео по сравнению форков и отдельно погоняем СУБД в контейнерах.
@@NickLavlinsky ok. гуд. еще бы людям рассказать про возможные утечки памяти в mariadb. не просто так они даже на своем сайте предлагают подключать сторонний менеджер памяти jemalloc или tcmalloc.
Насколько я понял, это аллокаторы не столько для уменшения утечек, сколько для ускорения выделения памяти. Ну и это одинаково относится и к другим форкам MySQL.
@@NickLavlinsky это тоже. где-то на хабре читал перевод... вроде утечки в основном возникают - так как в некоторых версиях mariadb/mysql со стандартным аллокатором полностью не освобождаются блоки памяти - которые отработали и уже не используются. и это приводит со временем к большому росту таких не освобожденных блоков, но надо тестить - так как не для всех версий mariadb/mysql и не для всех версий ОС - эта проблема актуальна. ) ps: хотя и взял за правило с mariadb всегда использовать сторонний аллокатор.(tcmalloc от google)
Очень интересно. Тоже не ожидал такого влияния) спасибо за тесты! Интересно, при увеличении количества контейнеров, через которые проходит запрос, задержка растёт линейно в зависимости от кол-ва контейнеров или всё-таки медленнее🤔 или быстрее😱
Имеете в виду фронт-бэк или балансировщик-фронт? Да, интересно. Здесь наверное еще нужно учитывать тип сети между контейнерами.
@@NickLavlinsky пожалуй, фронт-бек. Висит у нас, допустим, кучка микросервисов в контейнерах, редис, база и тому подобное. Я бы такое потестировал, прям интересно стало. Да и со схемой балансировщик-фронт тоже история любопытная. Допустим, проходит запрос сначала через балансировщик, а потом через редирект в третий контейнер. Сколько на дорогу тратить придётся.
Да, балансировщик-фронт-бэк-БД. На выходе 1 RPS.
Было бы интересно посмотреть результат работы Docker-контейнера с использованием режима (драйвера) macvlan.
Спасибо, это очень полезный контент
В MariaDB пока что не выпилили кэширование запросов.
Да, есть в актуальных версях.
Search Console жалуется на смещение контента, сервисы не показывают что есть смещение
Такое возможно, источники данных различные.
Wix-самый популярный сайт-билдер на Западе. Создан израильскими инженерами в 2006г. И постоянно совершенствуется. Поэтому оставьте эту тему.
Не оставим, будем развивать.
может имеется уже на канале видео со сравнением разных вариантов и версий mysql серверов? если ранее был только один сам, то теперь, как оказалось их не мало и что выбрать непонятно.
Пока нет, но можно сделать.
@@NickLavlinsky премного благодарен. подписываюсь чтобы не пропустить.
Сама установка и настройка рассказаны поверхностно. больше внимания в рассказе уделено кешу.
Да, всё верно.
Спасибо Николай! Очень полезный замер.
Спасибо, очень понятный гайд
Спасибо!
Класс! Аффтар пеши исчо
Смещение элементов важно именно для первого экрана или даже если элементы смещаются где-то внизу страницы то CLS тоже падает?
Только для первого экрана.
Какой же он новый если он с 2015 года
Поддержка в blink - 2 месяца
Zstd существует уже лет 5 Новый....
Поддержка в blink - 2 месяца
Интересно, что RPS у Zstd на 4-ом уровне компрессии (215 rps), лучше чем на 3-ем(212 rps). Я так понимаю, между ними особо разницы нет, и всё на уровне погрешности.
Да, это погрешность.
да, zip медленный алгоритм сам по себе. zstd специально проектироваося с учетом работы современного процессора и его старались сделать универсальным в том плане что одна программа может жать и со скорость 800 мб в сек и 40, в зависимости от настроек, чтобы не было мешанины из разных кодеков типа lz4 и lzma (или какой там в 7zip). разжимают они быстрее тоже.
на счет эффективности gzip просто срыв покровов. большое спасибо за интересный материал.
Благодарю, любопытный материал! Подскажите пожалуйста, есть ли у вас опыт настройки аналогичной оптимизации на сервере с панелями управления, такими-как Fastpanel и ISPmanager, если да, то можно ли как-то это настроить таким образом, чтобы связать данные настройки со встроенными регулировками в интерфейсе панели?
надо делать все руками, панели - зло
Если хотите получить лучший вариант настроек сервера вам придётся отказаться от панелей, это просто лишняя прокладка между администратором и софтом.
@@NickLavlinsky Благодарю за ответ, я это понимаю, но при таком варианте администрирование начинает съедать кучу времени, а если это не является основной деятельностью, то довольно сильно напрягает🙂 Но а всё-же, теоретически такое возможно сделать, если отбросить фактор того, что это лишняя прослойка, или будут конфликты какие-то?
@@Reklamnij_effekt Панель может в любой момент переписать ваш конфиг, в том числе может получиться конфликт и сервер не поднимется, так что я бы не советовал. Хотите простоту - используйте панель. Хотите оптимизации - делайте как положено, без панелей.
Я просто не могу перестать смотреть ваши видеоролики! Они такие информативные и интересные, что каждый раз я открываю для себя что-то новое. Спасибо вам за такой ценный контент, вы делаете отличную работу! Надеюсь, вы будете продолжать радовать нас своими увлекательными видео. Удачи и успехов вам!
Для фото-архива - JPEG XL, значительно выигрывает в скорости кодирования и в визуальном качестве, при сопоставимом размере с AVIF. а для инет фоток с низкой детализацией и разрешением, графики, анимации, скришотов и тп. AVIF, за счет лучшей работы с краями и плоскими областями, будет иметь некоторое визуальное преимущество. При этом, уступая в скорости кодирования и в отсутствии прогрессивного режима. Больше похоже, что Гуглу не понравился формат-конкурент для AVIF и Webp, превосходящий их вместе взятых.
Скорость кодирования для фотоархива вообще не важна. Размер у JPEG XL несопоставим с AVIF, а намного больше, смотрите обзор JPEG XL на этом канале. Прогрессивного режима в AVIF нет, всё верно. Так что JXL это довольно слабый конкурент AVIF, даже если бы получил поддержку в браузерах.
@@NickLavlinsky Повторюсь, речь идет не о фоточках для инета. Все сравнения и тесты, предпочитаю делать сам. Сравнивал фотографии с высоким разрешением и мелкой детализацией, с сопоставимым временем обработки и размером файла. Начиная от самых медленных режимов / настроек, расчитанных на получение наиболее качественных результатов, и заканчивая, настройками для достижения сопоставимой скорости обработки. Опять же, если цель - сделать фоточки для интернета, маленького размера, или, даже, высокого разрешения с максимальным сжатием, то AVIF, визуально, в общем и целом, лучше, за счет лучшей работы с краями и сжатием плоских областей. Если речь о фотоархиве, где речь идет о сохранении мелких деталей, в балансе "качество-скорость обработки" - JPEG XL, справляется лучше, как в сопоставимых по скорости и размеру условиях, так и на самых медленных режимах обработки. Соглашусь, что AVIF, где-то, немного выигрывает, за счет лучшего сохранения краев, но, в целом, JPEG XL, превосходит AVIF по мелким деталям и за счет меньшей замыленности. Даже на самых медленных режимах, AVIF замыливает плоские и средне-плоские поверхности, хотя и несколько лучше работает с краями, что дает ему некоторое преимущество, однако, опять же, в целом, уступает JPEG XL, за счет большей замыленности плоских и средне-плоских поверхностей. я не фанат JPEG XL, это два разных формата, для разных задач и условий использования. Пользуюсь AVIF ежедневно, но, для фотоархива, для фотографа, JPEG XL будет лучшим выбором, в соотношении размер - качество.
есть какое-то универсальное решение, скармливаем любую картинку а кодировщик принимает решение как его лучше конвертнуть в avif?
У нас есть.
наверно стоило провести чуть более сложное тестирование, например скриптом сгенерить 20 картинок с разным уровнем сжатия и сравнить их c такими же mozjpeg через какой-нибудь dssim, потому что 80% в одном могут отличаться от 80% в другом кодеке. это самое просто, датасет хороший подобрать все же сложнее, но в целом да, обычное любительское фото, скрин и т.д. cгодятся
Степень компрессии по качеству здесь как раз очень соответствует, в этом смысл. 20 разных уровней качества можете попробовать, но я не вижу смысла. Если тема вызывает интерес, можем прогнать базу из 10-100k картинок и посчитать статистику по размеру.
за выбор картинок однозначно лайк
еше aif все не освоили ) А прогресс идет. Спасибо за видео
Видимо, avif. Но для внедрения avif нужно больше телодвижений, так что не надо сравнивать.
ждите во всех вакансиях 3+ года с Jpegli ))
Вижу Лавлинского Николая - ставлю лайк!
Привет, а как это все установить? есть какой курс для этого?
Есть документация: docs.percona.com/percona-monitoring-and-management/setting-up/server/index.html