Comments 107
На момент написания данной статьи, это всего 80%. Вполне не плохо, но еще слишком мало чтобы использовать повсеместно.
Во-первых, не "всего", а целых!
Во-вторых, уже можно использовать повсеместно, просто нужно настроить распознавание user-agent.
Ну а обвинять одних разработчиков гугла из-за того, что другое подразделение выпустило такой инструмент — как то странно. Представьте, сколько у них всего сервисов, проектов и команд.
Дело в том, что сайты, относящиеся к проекту devsite, сейчас плавно переводят на lit-element в замен устаревшего Polymer и не сказать, что этот перевод проходит безболезненно всё-таки Custom Elements ещё далеки от идеала и на данный момент поставлена задача обновления кодовой базы, а не оптимизация.
Ну и не забывайте, что для SSR на Custom Elements приходится прогонять через Headless Google Chrome это тоже знаете ли время до ответа сервера, учитывая очередь на отрисовку.
Я ради интереса сейчас запустил этот же тест несколько раз в результате получил стабильный показатель 95%. А сообщение на которое было обращено внимание явно основано на статистике — ключевое в сообщении: "Согласно данным, собранным за последние 30 дней".
Насчёт претензий по формату картинок отмечу, что видимо с переносом на новый фреймворк они меняют структуру проекта и на данный момент не сервят картинки с googleusercontent, который динамически перекодирует. У них на данный момент даже правила кеширования изображений не настроены.
Во-вторых, уже можно использовать повсеместно, просто нужно настроить распознавание user-agent.
Правильно распознавать user-agent — задача мягко говоря не категории «просто».
Давайте будем честными, с небольшим оверхедом даже в CSS это можно сделать через srcset или picture. Кроме того, вообще через js это вообще самая простая задача. Любой новичек может это нагуглить максимум со второй попытки. Я не программист, но даже я знаю, как это делается
Более того, я вам сразу скажу, что любой распознаватель, который есть в мире (и который написали лично вы) — скорее всего не работает правильно во всех случаях, и очень хорошо, если работает правильно в 99% случаях. Скорее всего — меньше. А затем еще есть user-agent spoofing.
dady_KK предлагает использовать тэг picture. Мы выдаем ссылки на картинку во всех возможных форматах, а браузер сам решает, какой формат ему загрузить. Никаких строк парсить не надо
Graceful degradation же. IE увидит тэг <img> со ссылкой на png. Браузеры, которые понимают picture, обработают это корректно и предпочтут webp. В статье на MDN показан пример как это сделать.
Использовать анализ user-agent — это дает получить трудно обнаруживаемые баги, это усложняет отладку (когда по одному URL один разработчик видит одну картинку, а другой — другую). Серьезно, представьте ситуацию, когда 2 разработчика по одному и тому же URL видят разный результат, и представьте, каково это отлаживать? Как это поднимать у себя локально? Я локально использую встроенный в PHP сервер без nginx, например.
Далее, если перед вашим сервером поставят кеширующий сервер, и он начнет кешировать картинки не глядя на user-agent, как опять же, это обнаружить и отлаживать?
Вы почему-то предлагаете добавить тупой "сисадминский" костыль, который потом усложнит жизнь разработчикам. Причем в лучших традициях сисадминов, вы это нигде не задокументируете — пусть ищут сами. На мой взгляд, сервер просто должен отдавать то, что указано в URL, а выбор картинки должен делаться за счет указания нескольких вариантов в srcset. К тому же это пригодится вам для отдачи картинок с разными размерами под разные разрешения экрана.
Далее, если перед вашим сервером поставят кеширующий сервер, и он начнет кешировать картинки не глядя на user-agent, как опять же, это обнаружить и отлаживать?
Откровенно говоря, кеширующий сервер игнорирующий заголовки не только эту боль принесёт. Это вообще хороший источник проблем на ровном месте :(
на сайте сервиса компании лично настраивал отдачу webp вместе png/jpg, nginx смотрит на наличие нужного в Accept, и если там есть image/webp отдает wepb вместе png/jpg.
единственное что нужно что был зеркальный файл.
довольно просто, и не надо смотреть на эти 80% после этого.
Вопрос только в целесообразности. Есть сервисы с ужасным дизайном и/или не очень оптимизированные, но ими пользуется огромное количетсво людей из-за контента.
Сомневаюсь, что очередным из многих интернет-магазином будут пользоваться, если он загружается вечность.
Так же знаю сайт одной гейм компании playtika, у которой в начале загружается огромное видео в сумме на 8 МБ. А весь сайт весит 14 МБ. Видимо им важнее произвести впечатление, чем быть ближе в выдаче, т.к. в гугле по запросу "playtika" они на 4 месте:)
Ну вообще png для некоторых видов графики более предпочтителен и будет иметь меньший объем байт.
Firefox не передаёт Accept webp...
Именно, недавно разбирался с этим, Firefox этого не передавал. Видимо теперь с 70 версии передаёт.
ФФ:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Хром:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
А делать заранее все webp-ки на все 8млн вариантов изображений (при этом эти 8млн jpg тоже надо сначала сделать) — это не выход. Исходный массив изображений регулярно обновляется и меняется.
Спасаемся за счет сервиса на Golang на котором мы написали свой конвертер, он успевает делать до 100..150 полноценных картинок (баннеры и изображения товаров) в секунду. Мелкие иконки он быстрее делает, но их можно просто кешировать.
Но да если у вас на странице грузится 100+ картинок, то webp может дать и значительный прирост.
P,S, гугл не смотрит на ваши циферки по pagespeed, если вас беспокоит влияние на ранжирование. Важна конечная скорость загрузки на клиенте, а это выясняется через GA.
гугл не смотрит на ваши циферки по pagespeed, если вас беспокоит влияние на ранжирование. Важна конечная скорость загрузки на клиенте, а это выясняется через GA.
В консоли гугла не так давно появился пункт меню: Скорость загрузки (экспериментальная функция).
303 URL с низкой скоростью
28 URL со средней скоростью
0 URL c высокой скоростью
Ранжирование по низкая/средняя/высокая идет по параметрам гугл спид тест.
Экспериментальная. Это значит, что гугловцы сами пока не уверены, адекватные ли там данные и можно ли их использовать == ознакомительная информация.
Во-вторых, спидтест универсальный, а значит, очень ненадежный инструмент. Его можно показывать вебмастерам, но использовать как фактор ранжирования… Ну вы серьезно считаете, что используются данные о том, как быстро загружается сайт на токийском сервере при ранжировании московского магазина?
i.prntscr.com/GOnfwODERVGM8-_D7piDQQ.png
i.prntscr.com/-ixKldb5QO2DOvlu9ggYUA.png
developers.google.com/web/tools/chrome-user-experience-report
PageSpeed там предлагается смотреть, если недостаточно данных по сайту по принципу «мы хз, что у вас со скоростью, попробуйте хотя бы так прикинуть».
А по методологии измерения видно, что для гугла важна не субъективная скорость каким-то там сервисом, а объективная, из пользовательских браузеров.
Золотые слова, это первое что придёт в голову разработчику, который знает что такое webp и следующее по счету — разработчику, который не знал, но прочитал первую попавшуюся статью по оптимизации и это будет самое простое и верное решение, пусть и с лишней писаниной в коде (когда форматов и медиа запросов куча).
Инструмент это плохой. Посмотрите на образцы JPEG, которые он предлагает как "оптимизированные". Они сжаты с плохим качеством. Какой-то дурак из Гугла просто прописал в скрипте 85 как степень сжатия картинок. Я специально экспериментировал, подбирал сжатие, чтобы не было артефактов на разных типах картинок, а эта хрень просто выдает некачественную картинку на 10% меньшего размера и утверждает, что сайт недостаточно оптимизирован.
При этом вы можете заменить свои джипеги на тяжеленный PNG, который весит в 10 раз больше, и эта штука ничего не заметит. То есть сайт, сделанный каким-нибудь учившимся по видеоурокам инвалидом получит больше очков, чем оптимизированный профессионалом.
Также, эта фигня в упор не замечает веб-шрифты, хотя они, в отличие от джипегов, тормозят показ содержимого на странице. Выкиньте веб-шрифты со своего сайта прямо сейчас! 95% пользователей используют Windows, и в ней есть несколько десятков встроенных высококачественных шрифтов, сделанных профессионалами, и незачем грузить пользователю ненужный ему контент, веб-шрифты без ручного хинитнга, которые размазываются под Windows иногда до нечинаемой степени. Удалите их прямо сейчас и поставьте Тахому.
То же самое касается рекламы. Она тормозит сайт, но он ее в упор не видит.
Плюс Гугл рекомендует мутные практики вроде вставки в страницу CSS, относящегося к части страницы, попадающей в первый экран. Во-первых, а что такое "первый экран"? Как вы его высоту определяете? Во-вторых, как вы собираетесь извлекать этот CSS из 500 Кб свалки файлов, расскажите? В-третьих, а что, второй экран пользователю не нужен? Мутный совет, который придумал какой-то идиот, перепечатал другой идиот, скопировал бездумно разработчик Гугла, который требует больших затрат времени и который может утяжелить страницу.
Эта фигня требует кешировать статические файлы на 15 дней, но как их тогда обновлять? Хинт: добавьте к ссылкам на них текущее время (image.png?t=20190101120000). Так вы сделаете посетителям хуже, так как браузер их не сможет кешировать эти файлы, но Гугл станет доволен и уберет свои претензии. Потому что этот скрипт тупой, как пробка, как и его разработчики.
Еще этот чудо-инструмент может вменить вам недостаточную оптимизацию скриптов Яндекс-метрики, Гугл-аналитики и Google Adwords.
Увы, владелец сайта часто доверяет этому сомнительному инструменту, а не разработчику. Хотя, на мой взгляд, им должны пользоваться только люди, способные сами найти все эти проблемы и знающие плюсы и минусы разных способов оптимизации, а не кто попало, верящий Гуглу на слово бездумно.
Чтобы добавлять версию или время изменения, нужно затрачивать время на работы по переделке системы деплоя. Если ваша цель не оптимизировать сайт, а получить хорошие цифры в тесте, то дешевле и быстрее обмануть этот глупый тест и не портить сайт и не усложнять жизнь разработчикам.
Контрольные суммы ненавижу, их невозможно запомнить и различать на глаз. Их делают люди-роботы для подобных себе.
Выкиньте веб-шрифты со своего сайта прямо сейчас! 95% пользователей используют Windows, и в ней есть несколько десятков встроенных высококачественных шрифтовЭто могло быть правдой в 2007-ом.
Сейчас я бы ожидал, что только треть пользователей используют Windows, ещё треть имеют IOS и треть — Android.
Во-первых, а что такое «первый экран»? Как вы его высоту определяете?Возьмите с запасом 1100px. Подаваляющее большинство мобильных имеет высоту меньше.
Во-вторых, как вы собираетесь извлекать этот CSS из 500 Кб свалки файлов, расскажите?Можно руками разметить scss так, чтобы инлайн часть собиралась отдельно от асинхронно-загружаемой части. Но вроде как есть и автоматические инструменты для этого.
В-третьих, а что, второй экран пользователю не нужен?Предполагается, что пока пользователь радостно изучает содержимое быстро загруженного первого экрана, ваши 500 Кб css успеют загрузиться и второй экран станет доступен.
Многовато яблочников как-то.
Ну в данном случае, видимо, речь о всемирной среднепотолочной статистике.
Ну так пользователям мобильных устройств с медленным и платным трафиком ваши веб-шрифты нужны еще меньше. Влепите для них sans-serif, или какой-нибудь встроенный в Андроид шрифт и сэкономьте время на загрузку страницы и парсинг шрифта дохлым чипом на ARM.
У большинства, я думаю, не дорогущая iOS, а какой-нибудь дешевый старый андроид с 512 Мб памяти, в которой не так много лишнего места для веб-шрифтов.
Можно руками разметить scss так, чтобы инлайн часть собиралась отдельно от асинхронно-загружаемой части. Но вроде как есть и автоматические инструменты для этого.
Нету. Реальность в том, что у вас есть сайт с 300-500 Кб CSS, который несколько лет создавался без разделения кода для первого экрана. Более того, на разных страницах "первый" экран содержит разные элементы и разные стили. Вы для каждого раздела сайта планируете свой набор CSS вынести?
Далее, часто верстальщики используют тяжелые фреймворки вроде bootstrap, где все связано и классы наследуют друг друга. Вы сможете разгрести этот бутстрап и вынести из него только нужное на первом экране?
Далее, если у вас есть веб-шрифты, то наличие CSS для первого экрана не поможет отобразить его, так как веб-шрифты еще в этот момент не загрузились.
Есть А/Б тестирование, когда разным людям показываются разные варианты шапки. Есть приветственные попапы, которые появляются при загрузке сайта. Вы все это сможете учесть?
Далее, если у вас на первом экране есть поле поиска, то стили для выпадающих из него подсказок должны быть включены в стили для первого экрана или нет?
Нужно ли в стили первого экрана включать стили для мобильной версии?
Далее, сайт эволюционирует и дорабатывается, как вы собрались поддерживать актуальность разделения стилей на первый экран и все остальное?
Далее, на первом экране часто бывают бесполезные меню и баннеры, и я сразу проматываю страницу к тексту статьи. Не логичнее ли тогда приоретизировать стили для текста статьи, а не никому не нужную шапку? Более того, можно верстать сайт так, чтобы в HTML сначала шел текст статьи, а только потом сайдбары, шапки, подвалы и прочий ненужный хлам. Тогда даже до загрузки CSS можно будет начинать читать статью (при желании можно заембедить вручную в страницу пару правил для ограничения ширины текста и добавления полей, которые отменяются после загрузки основного CSS, а при большом избытке времени можно предусмотреть сверху отступ для того, чтобы при загрузке шапки страница не прыгнула). Как вам моя идея?
Это у верстальщиков лендингов, наверно просто делается. На реальном сайте это сложная задача, требующая много времени, которую сложно поддерживать, сложно вписать в архитектуру сайта. Дорого и бесполезно. Какой-то дурачок, который сложнее лендинга ничего в жизни не верстал, придумал эту идею и все теперь с ней носятся. И этого дурачка, наверно, взяли в Гугл и приглашают на всемирные фронтенд-конференции.
Это актуально только для сайтов вроде Гугла с простой версткой, на которые очень часто заходят. Но вы не Гугл и вам это не нужно.
И, кстати, другой дурачок-верстальщик лендингов придумал скрывать текст сайта до полной загрузки ресурсов или делать прелоадеры, что замедляет время до появления контента, а при отвале яваскрипта отставляет пользователя с белым экраном.
Нету. Реальность в том, что у вас есть сайт с 300-500 Кб CSS, который несколько лет создавался без разделения кода для первого экрана. Более того, на разных страницах «первый» экран содержит разные элементы и разные стили. Вы для каждого раздела сайта планируете свой набор CSS вынести?Если у вас стили много лет лежат в файле all.css, то при наличии ресуров есть смысл переверстать сайт с учётом современных реалий. Если ресурсов на это не хватает — проще отрицать то, что быстро загружаемый сайт при прочих равных выигрывает по посещаемости у медленно загружаемого.
С другой стороны, если вы свои ресурсы потратите не на вёрстку, а на создание более качественного контента, чем у конкурентов, то неважно, что страницы вашего сайта будут на секунду дольше грузиться, посетители дождутся.
Все эти рекомендации прежде всего актуальны для e-commerce и прочих высококонкурентных областей. Там люди приходят с поиска за определённым товаром, открывают несколько вкладок с одним и тем же товарным предложением. Если ваша страница медленно грузится, а у конкурента всё летает, то посетитель может успеть оформить заказ в другой вкладке, не дождавшись, пока all.css на вашей странице загрузится и распарсится.
Нужно ли в стили первого экрана включать стили для мобильной версии?В первую очередь для мобильной это и актуально. Именно с мобильных сайт будут открывать в тоннеле метро, на даче и в других местах, где скорость интернета неидеальна.
Далее, сайт эволюционирует и дорабатывается, как вы собрались поддерживать актуальность разделения стилей на первый экран и все остальное?Если у вас нормальная структура кода и вы разделение стилей реализуете при помощи разметки кода, проблемы с поддержкой не будет.
Плюс Гугл рекомендует мутные практики вроде вставки в страницу CSS, относящегося к части страницы, попадающей в первый экран. Во-первых, а что такое «первый экран»? Как вы его высоту определяете? Во-вторых, как вы собираетесь извлекать этот CSS из 500 Кб свалки файлов, расскажите? В-третьих, а что, второй экран пользователю не нужен? Мутный совет, который придумал какой-то идиот, перепечатал другой идиот, скопировал бездумно разработчик Гугла, который требует больших затрат времени и который может утяжелить страницу.
Если вы чего-то не знаете или не понимаете, лучше спросить, ну или погуглить. )
1. Существуют системы аналитики, GA или Я.Метрика, которые собирают статистику разрешений экрана. Можно посмотреть там сколько это — «первый экран». Но даже если без низ, то как правило речь о первой 1000px страницы сайта.
2. Существуют автоматизированные сервисы, которые из вашей помойки выберут нужное. Например jonassebastianohlsson.com/criticalpathcssgenerator
3. Второй экран нужен, но, как я уже говорил, вы не поняли суть методики. Речь о том, что для в начале мы грузим только маленький css необходимый для чтобы показать экран или даже не грузим, а просто вставляем в секцию head. Стили для второго и далее, т.е. полный, грузим позже. Этакий Lazy loading для css.
Если я вас не убедил, посмотрите выступления Виталия Фридмана на тему ускорения загрузки сайта. Возможно вы измените свое мнение.
Это всё от лукавого — собираем все стили в all.css и все скрипты в all.js и отправялем эти два файла http/2 server push-ем. И не надо никаких извращений с Lazy loading для css.
У больших сайтов они будут очень развесистые, и пока они загрузится на мобильник или плохом интернете, будет белый экран у пользователя.
У меня сайт на Битрикс — сами понимаете сколько там всего :) Так вот файлы объединённые скриптов и стилей занимают по 80кб каждый. А так как они отдаются http/2 server push-ем то загружаться в браузер посетителю они начинают ещё до фактической загрузки страницы и успевают загрузиться отнюдь не позже всех других файлов если timeline смотреть. Никаких белых экранов не возникает даже на медленном интернете.
Представьте себе facebook сделанный таким образом ;)
Но есть же отложенная загрузка кода аналитики?
Во-вторых, как вы собираетесь извлекать этот CSS из 500 Кб свалки файлов, расскажите?
Без особых проблем:
Это было рекомендациями последние лет 5. С прошлой недели данные из pagespeed insights появились в Google search console. Мне подсказывает интуиция, что эти данные в скором времени станут влиять на ранжирование
Ну вот, зашёл, чтобы написать этот комментарий, а его уже написали)
Они дают рекомендации как ускорить сайт, но сами не хотят ускоряться — их право. Можно жить так. Кто-то вообще бухает, а кто-то колется.
Насколько оправданы эти рекомендации, если даже их создатели(являясь при этом так же целевой аудиторией) считают что эффективнее потратить ресурсы на что то другое и этим рекомендациям не следовать?
По-моему, ответ довольно очевиден.
Если вы делаете сервис типа developers.google.com (т.е. с достаточно уникальным узкоспециализированным контентом, низкой или вообще отсутствующей конкуренцией, отсутствием прямой связи между посещениями страниц и доходом и вообще отсутствием понятия "конверсия") — рекомендации не оправданы. Можете спокойно жить с оценкой 40-60. Ибо те, кому надо — будуть пользоваться сервисом даже если он 10 секунд страницу будет грузить. А те, кому не надо — не будут пользоваться, даже если страница загрузится за 100 мс. Лучше сконцентрироваться на других направлениях развития сервиса.
Но если вы делаете условный амазон, то уменьшение времени загрузки даже на несколько сотен, а то и десятков мс уже может иметь вполне заметное влияние на конверсию. И там есть смысл выжимать скорость по-максимуму и следовать советам PageSpeed. Возле которых, к слову написано, что следование или не-следование им не обязательно повлияет на скорость загрузки и (как следствие) оценку PageSpeed, так что следовать им все равно нужно с умом.
Проверка PageSpeed должна идти самой последней в работе вебмастера по оптимизации "скорости" сайта.
Ибо если ты всё делаешь правильно просто исходя из здравого смысла и логики то по окончании работ по оптимизации запускаешь PageSpeed и видишь свои 95-100 зелёненькие просто для чувства глубокого морального удовлетворения :)
А потом вешаешь метрики, аналитики, живосайты, и получаешь 40 в лучшем случае.
Месье понимает толк в извращениях? Внедрять на свой сайт бяку которая сама по себе со сторонних серверов что-там подгружает ?
- Зачем Метрика и ГА? настраиваем вебморду к goaccess которому скормили логи apache / nginx и радуемся жизни (Ну или используем Битрикс с его встроенным модулем Вебаналитики :) )
- Зачем jivosite? Ставим на сервер openfire, на сайт Candy, на телефон Conversations — и имеем нормальную "обратную связь" без всякого стороннего мусора.
Стоп. Я писал про openfire+candy+conversations как замену jivosite — это прошу прощения не хомяк-блог это бизнес только ставит! Причем jivosite платный! Вместо того чтобы тащить на сайт бяку за ежемесячную плату разве не проще нанять спеца и сделать собственное решение ?
Большинству проще поставить готовое решине в несколько кликов.
Что нужно, чтобы поставить jivosite? Насколько я знаю, надо зарегистрироваться, настроить внешний вид чата и вставить подготовленный скрипт в html. Готово.
Что нужно, чтобы "Ставим на сервер openfire, на сайт Candy, на телефон Conversations"? Как миниум 3 отдельных приложения + специалист, который в этом разбирается.
Зачем Метрика и ГА?
Крупные проекты очень много чего разом делают при помощи таких инструментов. Там целые отделы маркетинга этим занимаются. Это очень серьёзные инструменты, а не просто счётчики.
Мы проверяем поддержку webp примерно таким кодом, а дальше грузим webp или png
Про srcset не слышали? Браузер сам умеет все это определять.
Разве не picture+scset? Мы не вставляем изображение в DOM, мы из них делаем opengl текстуры.
По webp / На сервере прописала определение браузера. Если точно понимает webp, отдаю его, если нет или сомнительно — jpg или png. По статистике скачивания webp/jpg — примерно 97/3;
А вот если вашему сайту нужно как-то выделится среди конкурентов и залезть повыше в поиске, то тут уже все средства хороши.
Как данная "статья" смогла набрать 23 плюса? Любой кто пользовался этим сервисом, наверняка прогоняли сервисы Гугла через него. Но я вижу разницу между сервисами и обычными сайтами, поэтому этот открытие ничего не доказывает.
Разработкой JPEG XL занимаются автор FLIF/FUIF и Google, работа основывается на форматах FUIF и Google PIX. Там огромное количество плюшек, но моё любимое — можно пережимать все существующие JPEG/PNG/GIF без потерь в качестве в JPEG XL и обратно. Формат разарабатывается таким образом, чтобы на сервере можно было хранить только один файл в формате JPEG XL, и если браузер слишком старый, сервер сможет на лету быстро перепаковать данные в JPEG/PNG/GIF (с увеличением объёма передаваемых данных, но зато всё будет работать). Вторая классная фишка для веба — JPEG XL планируется быть «responsive by design» (как FLIF/FUIF), то есть само изображение на сервере может быть под HiDPI дисплеи, а браузер сможет загрузить только первую половину файла, чтобы получить изображение с обычной плотностью пикселей.
Полагаю, раз Google является одним из разработчиков, то поддержка JPEG XL должна будет появиться во всех основанных на Chromium браузерах. У Mozilla нет причин не поддержать новый формат (JPEG XL разрабатывается как свободный от отчислений). Разве что Apple под вопросом, но в любом случае для JPEG XL предусмотрен отличный fallback для браузеров без его поддержки, для всех браузеров, без усложнения разметки страниц с указанием кучи версий изображений. На странице просто ссылаемся на файл в формате JPEG XL, а сервер сам по заголовкам видит, умеет ли браузер в этот формат, и если нет, то отдаёт изображение в устаревшем формате типа JPEG/PNG/GIF.
Это вряд-ли, т. К. Поддержка Гуглом это ещё не всё. Сколько Гугл поддерживает webp, а массово внедрять его стали совсем недавно. Avif же поддерживается консорциумом, и будет декодироваться железками, и как минимум заявлена поддержка во всех популярных браузерах, разве что кроме safari, но я думаю это вопрос времени.
— У Microsoft был свой движок.
— Mozilla не поддержерживала WebP, так как он не давал весомого преимущества перед нормально оптимизированными JPEG, ну и плюс Google много лет уже сопротивлялся добавлению поддержки APNG. Чудесным образом, когда таки удалось убедить Google поддержать APNG, после этого поддержка WebP появилась достаточно быстро в Firefox =)
— Для перехода на WebP и поддержки браузеров без поддержки WebP, нужно явно хранить по две копии изображений, плюс усложнять разметку на клиенте. Плюс пережатие из JPEG с потерей качества.
Сейчас:
— Microsoft переходит на Chromium/Blink.
— У Mozilla нет поводов не поддержать такой явно превосходящий остальных (но это надо будет ещё проверить на практике) свободный формат как JPEG XL.
— При переходе на JPEG XL, на сервре можно хранить только файлы в формате JPEG XL (так как получить обратно JPEG можно быстро, и без потерь в качестве, если файл сжимался с флагами совместимости с JPEG или был получен путём пережатия из JPEG без потерь). Разметку в HTML усложнять не нужно — решение о том, нужно ли отдать JPEG XL as is, или нужно отдать изображение в легаси форматах, может приниматься сервером на лету, основываясь на заголовках запроса.
Да ну, это какой-то извращенный сисадминский костыль, который будет не задокументирован и доставит кучу боли разработчику при попытке разобраться, почему у одних по ссылке картинка отображается, а у других нет.
Сисадмины любят влепить какой-нибудь костыль, естественно, никак его не документировать, причем влепить его только на проде, но не в dev-среде, а разработчикам потом мучайся.
Логичнее использовать srcset, а не страшные админские костыли на стороне nginx.
У меня вообще складывается впечатление, что разработчики JPEG XL услышали все мои хотелки, и решили собрать их в один супер-формат для картинок =) Главное, чтобы у них всё получилось. Меня несколько смущает, что у них очень короткий цикл разработки этого формата — они всё за один год буквально хотят успеть. На мой взгляд, лучше бы всё же взяли больше времени на проработку. Чтобы не вышло как с Brotli, который быстренько приняли в HTTP, а буквально чуть позднее стало ясно, что Zstd подошёл бы лучше на эту роль (немного более производителен и гибок), но Brotli уже никто менять не будет, так как он в принципе тоже достаточно хорош.
загружается за 60мс
А как измеряли, если не секрет? Как-то очень уж маловероятно выглядит. 60 мс одни только задержки сети и сервера съедят. А со всякими парсингами и отрисовками даже для статической html уже все 150-200 мс наберутся. И без всяких js анимаций с картинками, подстраивающимися под размер окна.
Лицемерие google. PageSpeed Insights