Есть ещё один момент. Webp разные участки картинки сжимает по-разному. Я когда тестировал на вот этом изображении, считал, сколько прожилок у листочков видно. Получалось, что при том же размере файла листочки были чуть-чуть "прожилистей". А avif в режиме 4:4:4, когда оно по размеру немного больше, чем jpeg, – совсем хороши. То есть, внутренний маньяк-перфекционист может быть доволен при переходе на новые форматы даже без экономии места.
Да, очень быстро, буквально, на третьей-четвёртой картинке мы напоролись на то, что webp даёт больший по размеру файл, чем guetzli. Не стали бы заморачиваться вообще, но понадобилась прозрачность вот для этой страницы.
А про скорость отрисовки даже думать не хочется... Помимо времени работы кодека имеет ведь значение и количество задействованных кодеков. Одно отдать в jpeg, другое – в webp, а третье – в avif, и у телефона уже есть много разнообразной работы.
Да, это здорово. Мы не стали в этом направлении идти из-за SSR. А заранее знать, что браузер умеет, а чего нет, невозможно. Точнее, можно вести коллекцию user agent и (почти) не ошибаться, но это не наш метод.
А 10 раз, это, наверное, от исходного изображения. А мы за точку отсчёта брали уже масштабированные картинки при помощи libjpeg-turbo.
Я, похоже, кусок своей мысли проглотил и предыдущий комментарий получился непонятным. Я имел в виду "получить кусок страницы с заглушкой вместо картинки, если что-то пошло не так". Событие не пришло, последовательность действий какая-нибудь неочевидная и т. д.
То есть, если всё хорошо, то да, ленивый скролл хорошо оптимизирует трафик. А вот если не все 100% сценариев учтены, то как узнать, что у кого-то так и остались заглушки?
Не боитесь получить кусок страницы с заглушкой вместо картинки? Это ведь надо как-то по особому отслеживать, даже с ходу не придумать как именно.
Был когда-то инцидент – разваливалась вёрстка в android browser 4.4 (возможно, до сих пор так и разваливается, не проверял, т.к. это уже музейный экспонат). Можно было узнать, что вёрстка развалилась, по вычисленной ширине страницы. Она была сильно больше, чем надо. При обнаружении можно было послать соотв. сигнал на сервер и посчитать, сколько таких в сутки имеем. Если меньше 10, то ничего не делаем :)
А тут просто не было, например, атрибута src, браузер и не знал, что надо что-то качать. Но размеры обложки фиксированные, поэтому ничего не поползло. Как узнать, что посетитель увидел дырку?
Можно, но браузер сейчас может грузить картинки параллельно с загрузкой javascript, причём это окончательные картинки (js их ни на что не поменяет). А так получаются строго две стадии: грузим страницу, потом грузим js и только потом грузим картинки. Или, что ещё хуже – грузим страницу со ссылками на одни картинки, браузер пошёл уже какие-то из них качать, а тут мы решили, что умнее, и подменили ему картинки на другие.
Кроме того, с SSR столько проблем, что лучше не усложнять.
У нас используется server side rendering. Поэтому разрешение дисплея надо знать до того, как содержимое уедет на клиента. Ради этого раньше была вся возня с cookie, в которой сохраняли pixel ratio. И вдвое больше вариантов кэшируемой страницы.
"Навар" от webp при обычных jpeg (сформированных libjpeg-turbo), конечно, выше. Guetzli динамически подбирает параметры cжатия jpeg так, чтобы потери были в тех местах, где они незаметны. Поэтому у Вас 25%, а у нас 15% – мы 10 процентных пунктов получили на guetzli.
А про расход CPU да, непреятно. Это у нас CPU условно бесплатное, т.к. сервера наши собственные, ядер и памяти много, счёт за электричество – константа. А вот если на ходу генерировать, да ещё и места нет для AVIF под все 100% изображений, то проблема.
Guetzli внедрили в 2017 году. Тогда оно никак не сказалось на посещаемости.
Webp и avif внедрили в ноябре 2022. Получить измеримый прирост конверсии на такой технической оптимизации вряд ли возможно. Да и на ранжирование в поисковиках это, скорее всего не повлияет.
Мы это делаем в формате "не увеличивать долг". Добавили вещь, которая утяжеляет сайт на X, запомнили, что надо это X чем-нибудь скомпенсировать. Потом устроили субботник и скомпенсировали.
Есть такая штука nuitka.
Человек делает как хобби проект компилятор Python в С, который бинарно совместим с CPython. Я пару лет назад скомпилировал нашу IT-систему (python, django, etc) Нюткой, оно реально работало. Но тогда компиляция заняла 40 минут, поэтому от дальнейших тестов отказался.
Кай пишет, что достиг больших успехов в статическом анализе кода на Python без всяких аннотаций. А, следовательно, скомпилированный код начинает по производительности всё сильнее обгонять CPython.
Жизненный цикл большинства библиотек для форм выглядит так:
восторг. Я сделал штуку, которая красиво и наглядно позволяет запрограммировать вот эти 5 форм.
полёт нормальный. Я сделал на ней ещё 5 форм, пришлось, конечно, кое-где подпилить, что-то дописать, но пока я могу запрограммировать этим способом всё, что мне нужно.
Упс, я наткнулся на сценарий, который в это API не укладывается. Выкидывать код жалко, переписывать 10 уже написанных форм некогда. Сделаю дополнительный "костыль".
Упс^2. Через 5 форм "костыль" стал по объёму кода больше, чем первоначальное решение. Но переписывать 15 форм по новому нельзя, на это времени никто не выделит.
Отчаяние, переписывание всего кода и т. д.
Из этого есть только один вывод: сделайте на Вашей библиотеке максимально сложную форму и убедитесь, что это --невозможно-- можно сделать.
Примеры:
Поле выбора (select / radio button), где выбирается что-то непростое, требующее парсинга. Например, дата. Сколько раз эта дата превращается из Date в текстовую строку и обратно? Где живёт нормализация этой даты? Если в форме выбирают какой-нибудь объект из списка, в скольких местах у нас делается преобразование идентификатора объекта в ссылку на сам объект?
А если этот список объектов динамически меняется?
Несколько полей, граничные значения динамически вычисляются исходя из значений других полей. Например, диапазон дат.
Исчезающие/появляющиеся поля. Например, способ оплаты, который исчезает, если у клиента 100% скидка. Как валидировать поле формы, которое исчезает из виртуального DOM-дерева, а потом снова снова появляется, если поменяли другое поле?
Группа полей, которую можно использовать повторно в нескольких формах. Попробуйте сделать группу "сумма" + НДС + значение НДС, в которой внутри проверяется, что НДС вычислен правильно. А теперь попробуйте сделать группу "купленный товар", внутри которой есть эта группа, и которую, в свою очередь, можно использовать в нескольких местах.
Форма, в которой валидация части данных делается асинхронным запросом на сервер.
Форма со вложенными формами.
Попробуйте в порядке упражнения сделать на своей библиотеке форму ввода данных из кассового чека. Дата-время, номер смены и т. д. А потом сделайте внутри неё формы для добавления товаров/услуг, там цены и НДС к ним, общая сумма из списка товаров --может-- должна совпадать с общей суммой чека, кассира нужно выбрать из списка, сверяясь с их сменами через AJAX. Товары пусть будут уникальными, НДС зависит от типа товара, но должна быть возможность задавать его вручную.
Скорее всего, от текущей реализации ничего не останется, придётся все данные выносить в redux или mobx, всю логику валидации нести туда же.
Хорошая игра, спасибо!
Одной мелочи не хватает: возможность сделать undo после того как «сгорел» (когда ни одного хода нельзя сделать). В сложных пирамидах приходится подглядывать в конце, чтобы случайно не получить тупик и не начинать разбирать сначала.
Алладин продаёт примерно по 1500 руб/шт (если сотнями брать, наверняка дешевле) токены, которые генерируют OATH / HOTP пароли. Дёшево и сердито. Есть приложения для iPhone и Android, которые бесплатно генерируют такие пароли. Если сделать TOTP, то совсем дёшево, можно Google authenticator использовать.
А то ведь разорят сотрудники контору своими смс-ками.
Есть ещё один момент. Webp разные участки картинки сжимает по-разному. Я когда тестировал на вот этом изображении, считал, сколько прожилок у листочков видно. Получалось, что при том же размере файла листочки были чуть-чуть "прожилистей". А avif в режиме 4:4:4, когда оно по размеру немного больше, чем jpeg, – совсем хороши. То есть, внутренний маньяк-перфекционист может быть доволен при переходе на новые форматы даже без экономии места.
Да, очень быстро, буквально, на третьей-четвёртой картинке мы напоролись на то, что webp даёт больший по размеру файл, чем guetzli. Не стали бы заморачиваться вообще, но понадобилась прозрачность вот для этой страницы.
А про скорость отрисовки даже думать не хочется... Помимо времени работы кодека имеет ведь значение и количество задействованных кодеков. Одно отдать в jpeg, другое – в webp, а третье – в avif, и у телефона уже есть много разнообразной работы.
Отрадно видеть, что не мы одни бьёмся с "проклятием python 2.7" :)
Да, это здорово. Мы не стали в этом направлении идти из-за SSR. А заранее знать, что браузер умеет, а чего нет, невозможно. Точнее, можно вести коллекцию user agent и (почти) не ошибаться, но это не наш метод.
А 10 раз, это, наверное, от исходного изображения. А мы за точку отсчёта брали уже масштабированные картинки при помощи libjpeg-turbo.
Я, похоже, кусок своей мысли проглотил и предыдущий комментарий получился непонятным. Я имел в виду "получить кусок страницы с заглушкой вместо картинки, если что-то пошло не так". Событие не пришло, последовательность действий какая-нибудь неочевидная и т. д.
То есть, если всё хорошо, то да, ленивый скролл хорошо оптимизирует трафик. А вот если не все 100% сценариев учтены, то как узнать, что у кого-то так и остались заглушки?
Не боитесь получить кусок страницы с заглушкой вместо картинки? Это ведь надо как-то по особому отслеживать, даже с ходу не придумать как именно.
Был когда-то инцидент – разваливалась вёрстка в android browser 4.4 (возможно, до сих пор так и разваливается, не проверял, т.к. это уже музейный экспонат). Можно было узнать, что вёрстка развалилась, по вычисленной ширине страницы. Она была сильно больше, чем надо. При обнаружении можно было послать соотв. сигнал на сервер и посчитать, сколько таких в сутки имеем. Если меньше 10, то ничего не делаем :)
А тут просто не было, например, атрибута src, браузер и не знал, что надо что-то качать. Но размеры обложки фиксированные, поэтому ничего не поползло. Как узнать, что посетитель увидел дырку?
Можно, но браузер сейчас может грузить картинки параллельно с загрузкой javascript, причём это окончательные картинки (js их ни на что не поменяет). А так получаются строго две стадии: грузим страницу, потом грузим js и только потом грузим картинки. Или, что ещё хуже – грузим страницу со ссылками на одни картинки, браузер пошёл уже какие-то из них качать, а тут мы решили, что умнее, и подменили ему картинки на другие.
Кроме того, с SSR столько проблем, что лучше не усложнять.
У нас используется server side rendering. Поэтому разрешение дисплея надо знать до того, как содержимое уедет на клиента. Ради этого раньше была вся возня с cookie, в которой сохраняли pixel ratio. И вдвое больше вариантов кэшируемой страницы.
"Навар" от webp при обычных jpeg (сформированных libjpeg-turbo), конечно, выше. Guetzli динамически подбирает параметры cжатия jpeg так, чтобы потери были в тех местах, где они незаметны. Поэтому у Вас 25%, а у нас 15% – мы 10 процентных пунктов получили на guetzli.
А про расход CPU да, непреятно. Это у нас CPU условно бесплатное, т.к. сервера наши собственные, ядер и памяти много, счёт за электричество – константа. А вот если на ходу генерировать, да ещё и места нет для AVIF под все 100% изображений, то проблема.
Guetzli внедрили в 2017 году. Тогда оно никак не сказалось на посещаемости.
Webp и avif внедрили в ноябре 2022. Получить измеримый прирост конверсии на такой технической оптимизации вряд ли возможно. Да и на ранжирование в поисковиках это, скорее всего не повлияет.
Мы это делаем в формате "не увеличивать долг". Добавили вещь, которая утяжеляет сайт на X, запомнили, что надо это X чем-нибудь скомпенсировать. Потом устроили субботник и скомпенсировали.
Человек делает как хобби проект компилятор Python в С, который бинарно совместим с CPython. Я пару лет назад скомпилировал нашу IT-систему (python, django, etc) Нюткой, оно реально работало. Но тогда компиляция заняла 40 минут, поэтому от дальнейших тестов отказался.
Кай пишет, что достиг больших успехов в статическом анализе кода на Python без всяких аннотаций. А, следовательно, скомпилированный код начинает по производительности всё сильнее обгонять CPython.
Жизненный цикл большинства библиотек для форм выглядит так:
Из этого есть только один вывод: сделайте на Вашей библиотеке максимально сложную форму и убедитесь, что это --невозможно-- можно сделать.
Примеры:
Попробуйте в порядке упражнения сделать на своей библиотеке форму ввода данных из кассового чека. Дата-время, номер смены и т. д. А потом сделайте внутри неё формы для добавления товаров/услуг, там цены и НДС к ним, общая сумма из списка товаров --может-- должна совпадать с общей суммой чека, кассира нужно выбрать из списка, сверяясь с их сменами через AJAX. Товары пусть будут уникальными, НДС зависит от типа товара, но должна быть возможность задавать его вручную.
Скорее всего, от текущей реализации ничего не останется, придётся все данные выносить в redux или mobx, всю логику валидации нести туда же.
Одной мелочи не хватает: возможность сделать undo после того как «сгорел» (когда ни одного хода нельзя сделать). В сложных пирамидах приходится подглядывать в конце, чтобы случайно не получить тупик и не начинать разбирать сначала.
А то ведь разорят сотрудники контору своими смс-ками.
постепенно повторим это по всему mail.ru
Ну не вешать же на meta + super + hyper :)
кстати, а при такой настройке window maneger нет конфликта? Ctrl+стрелка просто не доходит до браузера?