Компания Google опубликовала дополнение для Firefox с реализацией инструмента Lighthouse. Lighthouse входит в состав штатных инструментов для web-разработчиков, входящих в состав Chrome (вкладка "Audits"), и даёт возможность на основе собранных метрик проанализировать производительность и качество web-страниц и web-приложений. Код распространяется под лицензией Apache 2.0. Firefox-дополнение подготовлено основной командой разработчиков Lighthouse и использует при построении отчётов API PageSpeed Insights...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52421
Прочитал как "Google выпустил Firefox…", перечитал, выдохнул...
Вспомнил анекдот про бобра.
Ну да, ну да. Грузить шрифты с левых сайтов из веба чтобы когда на удаленном хосте они слетят сайт был нечитаем, ипользовать next-gen форматы чтобы поломать совместимость со всем чем только можно кроме самого распоследнего хрома. Сплошные best practices. А за Progressive Web App как позитивный показатеь _веб-страницы_ вообще расстреливать нужно.
Что не так с Progressive Web App ? И что была рекомендация хранить шрифты или js на сторонних CDN ?
В предпоследнем пункте мы отчетливо видим что web font load этой хренью определяется. Тем не менее как негативный или хотябы сомнительный показатель он нигде не отмечен, стало быть считается нормой. Так вот - нихрена это не норма.Эти ваши жирные и неповортливые "Web Appz" (читай - вся страница - один сплошной жабаскрипт) могут быть полезны и даже необходимы в определенных редких слйчаях. Но именно что в определенных и редких. Эта же хрень замахнулась на то чтобы говорить всем и каждому как правильно делать их сайты и страницы. Вот так и получаем саеты на которых 2 строчки статичного текста и 10 Мб скриптов, загружающихся полминуты.
Есть же всякие https://decentraleyes.org/ в чём проблема? А как вы видите себе сайты, они должны раздавать все ресурсы с себя?
В том, что это ещё и ресурсы жрёт.
Какие именно? 99% ресурсов тратится на подгрузки из сети. Но если всё закэшировать, никаких проблем не будет. Сабж как раз вариант превентивного кеширования, странички грузящиеся по 5 секунд напрягают.
1мб js != 1мб img .А желание заюзать кеш стороджа, в том, что основной кеш в браузере быстро опустошается.
Одна из причин.
Кешировать ты можешь и со своего сайта примерно с тем же эффектом, как из с централизованного cdn.> There are so many libraries and versions, and browser caches are smaller than you think, so for you to be lucky enough to gain from this seems unlikely. Additionally Safari has a unique HTTP cache per domain visited, for privacy reasons (called a double-keyed cache) and Chrome soon will have too, ending any argument there.
https://www.tunetheweb.com/blog/should-you-self-host-google-.../
Там автор помнится обещал прикрутить возможно самому указывать источники чтобы всегда было всё актуальное. Сделано?
> В предпоследнем пункте мы отчетливо видим что web font load этой хренью определяется. Тем не менее как негативный или хотябы сомнительный показатель он нигде не отмечен, стало быть считается нормой. Так вот - нихрена это не норма.
> Эта же хрень замахнулась на то чтобы говорить всем и каждому как правильно делать их сайты и страницы.У вас противоречие себе отклеилось. Первая цитата вас сетует на то, что гугл не помечает вебшрифты как плохие или хорошие, вторая цитата вас сетует на то, что гугл указывает всем как правильно делать сайты. Либо первое высказывание неверно, либо второе, либо оба.
я сам противник ожирения сайтов. И на некоторых по 10 шрифтов грузится . Хотя по факту используется 3-9 иконок.Которые можно заменить да хоть jpg, настолько жирные шрифты лепят.
Web App, не подразумевает кучу js или забивания кеша, на мобиле.
Но если пользователь посещает ваш сайт часто, и просматривает больше 3 страниц, то web app может ускорить открытие и экономию трафика.
Многие сайты и без web App содержат много хлама, т.е. объем js/css часто завышен раз в 10-20.
Дело дошло до того что браузеры начали "замораживать" вкладки.
Это не так, если приложение построено правильно, то там lazy loading и страница подгружается кусками во время переходов по ссылкам, в том числе так же подгружаются куски js, кроме core (ядра). Это эффективно т.к. изначально подгружается "движок", а потом "шаблоны" (легкие куски страниц). Если бы каждая страница была чистым html, то "шаблоны" были бы толстыми потому что all inclusive. Другими словами, если сайт маленький, то толстых фреймворков не нужно, т.к. расход трафика будет выше. Если сайт большой, пользователь долго на нем седит и лазит по большому количеству страниц, то расход трафика будет меньше если PWA и Angular, React фреймворки.
В том, что когда Web пытается работать как App, то, что должно работать как Web ломается, при этом не работая нормально как App. Хрестоматийный пример тому мобильный хабр.
> Грузить шрифты с левых сайтов из веба чтобы когда на удаленном хосте они слетят сайт был нечитаемРазве браузер не переключится на дефолтные?
Переключается. Но "современные веб-дезенеры" верстают свои поделки только под свой 'литный шрифтец (зачастую имеющий левые размеры). И когда шрифтец по той или иной причине не подгружается вся верстка сезжает в канаву, сает становится нечитаем.
Пример такого сайта можно? А то лишь бы поныть.
Перевод: продвигайте наших слонов.
я конечно не веб-макака, но думаю там можно делать fallback-и в случае недоступности cdn на локальный кеш шрифтов. Если так, то практики с точки зрения производительности (а не безопасности) более-менее адекватные
> Грузить шрифты с левых сайтов из вебаЭто вы где такое вычитали? Никто не заставляет вас использовать CDN, можете хранить шрифты у себя. Даже Google Fonts позволяет загружать шрифты для этих целей.
> когда ... они слетят сайт был нечитаем
На такой случай есть "fallback" с переключением на другие шрифты (скорее всего набор более-менее подходящий системных или по умолчанию).
Кстати, предупреждение на скриншоте — что пока шрифт не загрузится, текст остаётся невидим, когда как есть другие тактики, в которых до загрузки шрифта всё содержимое будет показано в "fallback" шрифтах: это не очень красиво, когда шрифт два раза меняется при загрузке страницы, но всяко приятнее видеть контент много раньше.
> ипользовать next-gen форматы чтобы поломать совместимость
Лол. Webp позволяет прилично так сэкономить трафика без серьёзной потери качества. Очень полезно на мобилках с трафиком, а на них встретить юзверей с диназаврами сложно.
Для совместимости существует тег Picture (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...) или можно использовать JS.
> поломать совместимость со всем чем только можно кроме самого распоследнего хрома
Webp поддерживается Firefox с 65 версии, Picture с 52* (*38 за флагом), а старые браузеры без его поддержки просто будут использовать Img внутри.
Каким образом вы умеете заставлять браузеры делать сайт нечитаемым, если не доступны шрифты по ссылкам? Все типы шрифтов браузерами замнеяются на схожие по размерам и керлингу, никакого сдвига быть не может в принципе на сайте из-за смены шрифтов.
Приглад особистого кабінету у pautina.ua. Я використувую свій шрифт на усіх сайтах. І вимкнув використання шрифтів сайтами. В результаті, меню злівої сторони накладається на текст. Вмість сайта якимось чином не враховує ширину лівого меню, і підповзає під нього, розтягуючись на всю ширину екрану.
Говнокодеры из гугла все никак не успокоятся? У них там план по выдаче говноподелок не первыполнен еще?
Google выпускает "гоvнокод" исключительно потому, что там не работает такой первоклассный разработчик, как ты.
А что, гугл уже свою 50-центовую киберармию создал? Сколько ты за этот тред заработал на вылизывании их зaдницы?
а зачем нам кормить полезных идиотов, даже на пятицентовик?Они любому нашему выcepу и так будут аплодировать, добровольно и с песнями.
Поясните, плиз, человеку далёкому от веб-дизайна - я так понимаю, это что-то типа профилировщика, а разве у фф своего такого раньше не было?
Гугл считает, что ему виднее, как правильно профилировать.
Не совсем, это анализ сайта на соответствие стандартам (в т.ч. насколько он пригоден для людей с ограниченными способностями, но там куча вещей) , анализ скорости загрузки и прочих параметров.По итогу анализа выдается отчет с рекомендациями по улучшению, с ссылками на те самые стандарты и прочими примерами того как можно сделать лучше.
По факту преследуется 2 цели - повысить доступность сайта и повысить за счет этого его рейтинг в выдаче.
>> повысить за счет этого его рейтинг в выдаче.только если пользователи используют google Chrome
Самая хохма в том, что никто ( из "не посвященных" ) доподлинно не знает алгоритма определения рейтинга в выдаче.. даже сами поисковые конторы начинают что-то невнятно кудахтать, когда их прямо спрашивают о подобных вещах..Потому, это едва ли аргумент.
Проблема этой поделки в том, что это не "лучшие практики веб-разработки", а "лучшие практики веб-разработки ПО МНЕНИЮ ГУГЛА".
Проблема этой поделки в том, что это не "лучшие практики веб-разработки по мнению пользователя опеннета под ником segesg", а "лучшие практики веб-разработки по мнению гугла".
Выпусти свой инструмент, будут лучшие практики веб-разработки по мнению Васяна с опеннета.
А кто там жабоскрипт придумал, не напомните?
Brendan Eich initially, plus other key contributors to the ECMAScript specification
Я не понимаю, чем местные мамкины диванные победители конкурсов стограмма по скорости работы жс страниц недовольны.
Памагити
Так я и не понял какая гуглу выгода для чужого браузера проектировать расширение. Или они туда телеметрии напихали?
Они таким образом показывают: смотрите, наши стандарты единственно правильные, ориентируйтесь только на них.
Именно поиск Гугла решает судьбу сайта, так что no way
> изучить актуальность применения web-технологий и пригодность web-приложения для людей с ограниченными возможностями.Когда добавят тестирование на пригодность при плохом и нестабильном канале?
И ведь раньше умудрялись ту же информацию передавать в сотню байт WAP, не заставляя скачивать пару-тройку МБ фреймворков "для экономии трафика запросами только нужного" (и которое не отрубалось в середине процесса вбивания данных из-за таймаута скрипта автодополнения, заодно блокируя возсожность ввода).
Ну на счёт сотни байт в wap это ты загнул.
Помню, приходилось оптимизировать размер wml-страниц под очень популярный телефон c100 (самсунг, кажись). Так вот его браузер не переваливал страницы больше 3Кб.В итоге страницы с русским текстом (даже если заменить буквы, похожие на латинские, на эти латинские) занимали примерно экрана три. А экраны эти, напомню, полтора сантиметра на два сантиметра примерно.
Это, конечно, не 1мб div'ов и js'а ради показа одного экрана бесполезной информации с тонной бесполезных менюшек.
Но и с сотней килобайт - это просто неправда.
>Ну на счёт сотни байт в wap это ты загнул....
>Но и с сотней килобайт - это просто неправда.
>>Ну на счёт сотни байт в wap это ты загнул.
> ...
>>Но и с сотней килобайт - это просто неправда.Да, я описАлся. @Аноним84701 писал о сотне байт. И вот это, я утверждаю, не правда.
>>>Но и с сотней килобайт - это просто неправда.
> Да, я описАлся. @Аноним84701 писал о сотне байт. И вот это, я
> утверждаю, не правда.Там изначально было "сотню-другую", но после пары-тройки "улучшизмов" формулировки, "другую" куда-то исчезла.
А вот за сотню КБ (т.е. в году эдак 2003 отстегивания от ~ 0.5 до 2$ моб. оператору), "дезигнеру" неплохо бы досталось на орехи ;)
Сейчас надо, чтобы Мозилла выпустила приложение, которая бы провела аудит Гугла, по вопросам приватности.
Пусть сама себя аудирует. Сторонний аудит вот уже есть: https://digdeeper.neocities.org/ghost/mozilla.html
А сторонний аудит гугла ?
Откуда ты знаешь, может авторы этого софта проплачены Гуглом. И их аудит неправилен.
А кому это нужно?! Гуголь никогда не скрывал, что не является крупнейшим рекламным и поисковым рендером. При чем тут приватность. Он никогда и не врал об этом. В отличие от других (не будем тыкать пальцем)
Здравствуй новый дядя зонд?
Правильно. Гугл таким способом повысит рейтинг в выдаче себе.
Остальные будут идти, как всегда... лесом.