Управлять приоритетом выставляя атрибуты defer и fetchpriority теоретически можно. Но сформулировать какую-то простую и универсальную методику я не могу. Помещение скриптов в конец страницы фактически то же самое управление приоритетом загрузки. Оно интуитивно понятно и воспроизводимо даже начинающими кодерами в проектах любого уровня легаси бардака.
Defer и fetchpriority скорее подходят для тонкой поднастройки очереди загрузки при решении узких мест производительности, нежели для массового применения. При этом уже есть <link rel="prefetch"> и <img loading="lazy">. То есть, fetchpriority - не решает какую-то новую задачу, а является новой надстройкой. Из хорошего fetchpriority реализует новую парадигму мышления в вопросах очерёдности загрузки. Раньше очерёдность была привязана к порядку объявления объектов на странице, а сейчас к системе приоритетов, которой можно вручную управлять, выставляя атрибут fetchpriority.
За ссылку на документацию по приоритету загрузки - огромное спасибо! Уже произвёл несколько тестов, теперь буду думать, как применять эту технологию на практике и доносить её до массового кодера. Прям реально полезный материал для размышлений.
Если загружать скрипты с аттрибутомdefer то они всё равно будут откладывать загрузку картинок, пускай и меньше. Плюс браузер паралельно может загружать только 6-8 файлов. Если скриптов много, то их загрузка заблокирует загрузку картинок.
Размещая скрипты перед </body> , мы управляем очередью загрузки скриптов. Метод дедовский, но альтернатив ему нет.
Пример, который вы требуете, что должен проиллюстрировать? Системы авторизации надо подключать во время открытия всплывающего окна авторизации. Вот нажал пользователь на кнопку "Войти" в этот момент всплывает форма с вводом логина и пароля, а так же подгружаются сервисы авторизации. Пользователи пользуются формой авторизации на сайте с частотой меньше 0.5% и подгружать их сразу и на каждой странице - нерентабельно.
Они так пишут в своей документации. Но я читал об этом обсуждения и все сходятся во мнении что подключать рано их нет смысла. Единственное имеет смысл яндекс метрику подключать сразу, из-за её инструмента вебвизор, чтобы все действия пользователя успеть записать.
Все данные которые используют счётчики берутся из API браузера. Поведенческие данные, такие как скрол страницы у гугл аналитикс не обязательно прям на пол секунды раньше собирать.
Верно. Я, например, когда каптчу подключаю на сайт, делаю это на событие onfocus любого из полей формы. Получается, что каптча грузится в момент когда пользователь начал ввод данных.
В DOMContentLoaded обычно вызываются инициализирующие скрипты. Например тот же jQuery(document).ready это событие DOMContentLoaded. Следовательно, если вы подключите какой-нибудь тяжеловесный картографический сервис, то он может отложить инициализацию плагина слайдера. Поэтому все сторонние сервисы, если они не на первом экране прокрутки расположены, нужно подключать именно в window.onload.
Лучше всего использовать не 512х512, а векторную SVG иконку. Она прям вообще идеальная.
И помимо телефонов есть приветственные экраны браузеров (и десктоп, и мобильная), где иконки используются. Это когда браузер открывается и на стартовой странице отображаются недавно посещёные сайты. Это довольно частое применение иконок из webmanifest.
Касательно того, что тема изезженая. Тут согласен. Мусолят её часто, при этом мало кто дополняет материал какими-то новшествами.
В идеале, приложение должно использовать векторную SVG иконку, чтобы сгенерировать из неё любой размер. Но ещё часто для приложений нужно указывать цвет фона. Так же бывает, что в некоторых приложениях иконка нужна с отступами от краёв. Поэтому сложности с тем, чтобы унифицировать все иконки есть.
API, о котором вы говорите, можно назвать файл webmanifest. Сейчас более менее всё устаканилось и все используют его, но ещё 5 лет назад каждый производитель свой формат придумывал. Например apple свой touch bar, microsoft для интерфейса metro, яндекс браузер для табло.
В посте написано, почему желательно делать все виды иконок - чтобы программа, их использующая, не масштабировала их самостоятельно. В первой вашей ссылке автор указывает 2 картинки 192 и 512 пикселей. Какой-нибудь android телефон возьмёт ближайшее разрешение в 192 пикселя и сделает из него 180. И картинка будет мутной.
Также есть ещё легаси фавиконы для Windows Metro и Mackbook панели. Плюс базовый /favicon.ico нужно определённым образом создать (размер 32 пикселя и сжатие PNG).
К тому же есть сервис который в 1 клик все размеры подготовит. В нём что 3, что 30 иконок - одни и те же трудозатраты по интеграции.
Пробовал 2 недели назад делать по документации из вебархива не заработало. Так же посмотрел сайты для которых доступна установка красивой иконки и не нашёл у них в коде страницы метатегов из документации.
Лет 15 назад был на Yet Another Conference от Яндекса на ВДНХ, где они как раз презентовали свой браузер. Так вот на этой конференции они говорили, что сами рисуют все картинки для своего табло. Подозреваю, что сейчас они придерживаются той же практики.
Также нашёл вот этот ответ https://otvet.mail.ru/question/267031090. Там парень пишет (по всей видимости из команды разработки), что такая опция сейчас недоступна.
Подозреваю, эту возможность отключили из-за того, что пользователи не выполняли дизайнерские гайдлайны. Например, один сайт мог крупную иконку указать из-за чего всё табло не гармонично смотрелось. Где-то видел пост на эту тему.
Сама по себе тема небольшая и нюансов в ней не более десятка. Просто собрал всё в 1 кратком посте, чтобы не приходилось изучать несколько источников.
К тому же в посте описаны пара новых нюансов про сокращение файла favicon.ico и то, что он размером 32 пикселя должен быть, которых я нигде не встречал.
Аанализатор использования кода в хромиуме предназначен больше для отладки и перфоманс аналитики. А наш сервис поможет легко, просто, машинально, рутинно и последовательно вычищать неиспользуемый JavaScript. Просто тестируйте сайт, если что-то сломалось в консоль об этом появится маяк (строчка текста вида "QSU_462"). Находите этот маяк в коде проекта и раскомменируйте код рядом с ним. Потом продолжаете тестирование и так по кругу.
В итоге пришёл к тому, что нужен оптимизирующий компилятор
Такие инструменты, как правило имеют высокий порог входа и используются в каких-нибудь крупных корпорациях, где объёмы кода проекта настолько огромны, что такие средства - производственная необходимость.
Наш сервис может освоить и студент только изучающий JavaScript. И применять его можно рутино, без предварительной подготовки. А конечный эффект будет лучше, чем от компилятора. Так как удаление кода ещё и сокращает его объём, что ускоряет чтение кода.
Последние лет 5 или больше даже не задумывался над такой проблеммой.
Проблема замусоренного JavaScript кода ситуативная, нежели повсеместная. Чем более проект легаси, тем больше в нём мусорного кода. Особенно от этого страдают компании, чей профиль не связан с IT (ритейл, производство). Им программисты достаются по остаточному принципу и текучка специалистов достаточно высокая. Код быстро замусоривается.
Если удалишь что-то используемое - то Typescript тут же ругнется.
В том то и дело что сервис помогает быстро вернуть то, что удалил и маякует об это в консоли браузера. Преимущество в том, что восстановление зря удалённых кусков кода происходит машинально, без погружения в код. Просто увидел маяк, нашёл его в коде, раскоментировал. И так сотню раз.
Если конечно вы стандартные import/export юзаете. Вы же их юзаете?
Там используется стандартный хромиум браузер. Страницы открываются в нём и JavaScript код исполняется в нём. И браузер возвращает информацию, какие куски кода отработали, а какие нет.
Verdana есть только на виндовс. На андройд и iOS его нет. Более того, вы не можете установить его на свой сайт для пользователей других ОС без лицензии. То есть, Verdana - платный шрифт (если лицензия ещё продаётся).
Шрифты для сайтов нельзя брать из стандартных наборов так как наборы шрифтов у разных ОС не совпадают. То есть, нет одного шрифта, чтобы он был по умолчанию установлен и на виндовс, и на линукс и и на андройд. Поэтому директива local() не применима.
Управлять приоритетом выставляя атрибуты defer и fetchpriority теоретически можно. Но сформулировать какую-то простую и универсальную методику я не могу. Помещение скриптов в конец страницы фактически то же самое управление приоритетом загрузки. Оно интуитивно понятно и воспроизводимо даже начинающими кодерами в проектах любого уровня легаси бардака.
Defer и fetchpriority скорее подходят для тонкой поднастройки очереди загрузки при решении узких мест производительности, нежели для массового применения. При этом уже есть
<link rel="prefetch">и<img loading="lazy">. То есть, fetchpriority - не решает какую-то новую задачу, а является новой надстройкой. Из хорошего fetchpriority реализует новую парадигму мышления в вопросах очерёдности загрузки. Раньше очерёдность была привязана к порядку объявления объектов на странице, а сейчас к системе приоритетов, которой можно вручную управлять, выставляя атрибут fetchpriority.За ссылку на документацию по приоритету загрузки - огромное спасибо! Уже произвёл несколько тестов, теперь буду думать, как применять эту технологию на практике и доносить её до массового кодера. Прям реально полезный материал для размышлений.
Спасибо. Опечатку исправил.
Если загружать скрипты с аттрибутом
deferто они всё равно будут откладывать загрузку картинок, пускай и меньше. Плюс браузер паралельно может загружать только 6-8 файлов. Если скриптов много, то их загрузка заблокирует загрузку картинок.Размещая скрипты перед
</body>, мы управляем очередью загрузки скриптов. Метод дедовский, но альтернатив ему нет.В документации яндекса и ВК (ссылки в предыдущем комментарии) называется авторизация.
Просто запрос действительно настолько простой. Сервисы популярные и встречаются на каждом втором сайте. Поэтому подумал, что я неправильно понял.
Вот документация яндекс и ВК. Вот такие скрипты надо подгружать только по требованию, например когда открывается всплывающее окно авторизации.
Пример, который вы требуете, что должен проиллюстрировать? Системы авторизации надо подключать во время открытия всплывающего окна авторизации. Вот нажал пользователь на кнопку "Войти" в этот момент всплывает форма с вводом логина и пароля, а так же подгружаются сервисы авторизации. Пользователи пользуются формой авторизации на сайте с частотой меньше 0.5% и подгружать их сразу и на каждой странице - нерентабельно.
Они так пишут в своей документации. Но я читал об этом обсуждения и все сходятся во мнении что подключать рано их нет смысла. Единственное имеет смысл яндекс метрику подключать сразу, из-за её инструмента вебвизор, чтобы все действия пользователя успеть записать.
Все данные которые используют счётчики берутся из API браузера. Поведенческие данные, такие как скрол страницы у гугл аналитикс не обязательно прям на пол секунды раньше собирать.
Верно. Я, например, когда каптчу подключаю на сайт, делаю это на событие onfocus любого из полей формы. Получается, что каптча грузится в момент когда пользователь начал ввод данных.
В DOMContentLoaded обычно вызываются инициализирующие скрипты. Например тот же jQuery(document).ready это событие DOMContentLoaded. Следовательно, если вы подключите какой-нибудь тяжеловесный картографический сервис, то он может отложить инициализацию плагина слайдера. Поэтому все сторонние сервисы, если они не на первом экране прокрутки расположены, нужно подключать именно в window.onload.
Я бы ещё добавил, что событие window.onload - ключевое при загрузке страницы и всё что можно вызывать в нём или сразу после него, лучше так и сделать.
Есть ещё сторонние сервисы, вроде систем аналитики, каптч и карт. Они блокируют загрузку, если их неправильно вызывать.
Согласен. За 30 лет фавиконы следовало бы стандартизировать.
Лучше всего использовать не 512х512, а векторную SVG иконку. Она прям вообще идеальная.
И помимо телефонов есть приветственные экраны браузеров (и десктоп, и мобильная), где иконки используются. Это когда браузер открывается и на стартовой странице отображаются недавно посещёные сайты. Это довольно частое применение иконок из webmanifest.
Касательно того, что тема изезженая. Тут согласен. Мусолят её часто, при этом мало кто дополняет материал какими-то новшествами.
В идеале, приложение должно использовать векторную SVG иконку, чтобы сгенерировать из неё любой размер. Но ещё часто для приложений нужно указывать цвет фона. Так же бывает, что в некоторых приложениях иконка нужна с отступами от краёв. Поэтому сложности с тем, чтобы унифицировать все иконки есть.
API, о котором вы говорите, можно назвать файл webmanifest. Сейчас более менее всё устаканилось и все используют его, но ещё 5 лет назад каждый производитель свой формат придумывал. Например apple свой touch bar, microsoft для интерфейса metro, яндекс браузер для табло.
В посте написано, почему желательно делать все виды иконок - чтобы программа, их использующая, не масштабировала их самостоятельно. В первой вашей ссылке автор указывает 2 картинки 192 и 512 пикселей. Какой-нибудь android телефон возьмёт ближайшее разрешение в 192 пикселя и сделает из него 180. И картинка будет мутной.
Также есть ещё легаси фавиконы для Windows Metro и Mackbook панели. Плюс базовый /favicon.ico нужно определённым образом создать (размер 32 пикселя и сжатие PNG).
К тому же есть сервис который в 1 клик все размеры подготовит. В нём что 3, что 30 иконок - одни и те же трудозатраты по интеграции.
Пробовал 2 недели назад делать по документации из вебархива не заработало. Так же посмотрел сайты для которых доступна установка красивой иконки и не нашёл у них в коде страницы метатегов из документации.
Лет 15 назад был на Yet Another Conference от Яндекса на ВДНХ, где они как раз презентовали свой браузер. Так вот на этой конференции они говорили, что сами рисуют все картинки для своего табло. Подозреваю, что сейчас они придерживаются той же практики.
Также нашёл вот этот ответ https://otvet.mail.ru/question/267031090. Там парень пишет (по всей видимости из команды разработки), что такая опция сейчас недоступна.
Подозреваю, эту возможность отключили из-за того, что пользователи не выполняли дизайнерские гайдлайны. Например, один сайт мог крупную иконку указать из-за чего всё табло не гармонично смотрелось. Где-то видел пост на эту тему.
Сама по себе тема небольшая и нюансов в ней не более десятка. Просто собрал всё в 1 кратком посте, чтобы не приходилось изучать несколько источников.
К тому же в посте описаны пара новых нюансов про сокращение файла favicon.ico и то, что он размером 32 пикселя должен быть, которых я нигде не встречал.
Аанализатор использования кода в хромиуме предназначен больше для отладки и перфоманс аналитики. А наш сервис поможет легко, просто, машинально, рутинно и последовательно вычищать неиспользуемый JavaScript. Просто тестируйте сайт, если что-то сломалось в консоль об этом появится маяк (строчка текста вида "QSU_462"). Находите этот маяк в коде проекта и раскомменируйте код рядом с ним. Потом продолжаете тестирование и так по кругу.
В итоге пришёл к тому, что нужен оптимизирующий компиляторТакие инструменты, как правило имеют высокий порог входа и используются в каких-нибудь крупных корпорациях, где объёмы кода проекта настолько огромны, что такие средства - производственная необходимость.
Наш сервис может освоить и студент только изучающий JavaScript. И применять его можно рутино, без предварительной подготовки. А конечный эффект будет лучше, чем от компилятора. Так как удаление кода ещё и сокращает его объём, что ускоряет чтение кода.
Проблема замусоренного JavaScript кода ситуативная, нежели повсеместная. Чем более проект легаси, тем больше в нём мусорного кода. Особенно от этого страдают компании, чей профиль не связан с IT (ритейл, производство). Им программисты достаются по остаточному принципу и текучка специалистов достаточно высокая. Код быстро замусоривается.
В том то и дело что сервис помогает быстро вернуть то, что удалил и маякует об это в консоли браузера. Преимущество в том, что восстановление зря удалённых кусков кода происходит машинально, без погружения в код. Просто увидел маяк, нашёл его в коде, раскоментировал. И так сотню раз.
Там используется стандартный хромиум браузер. Страницы открываются в нём и JavaScript код исполняется в нём. И браузер возвращает информацию, какие куски кода отработали, а какие нет.
Verdana есть только на виндовс. На андройд и iOS его нет. Более того, вы не можете установить его на свой сайт для пользователей других ОС без лицензии. То есть, Verdana - платный шрифт (если лицензия ещё продаётся).
Serif - это не шрифт, а семейство шрифтов.
Шрифты для сайтов нельзя брать из стандартных наборов так как наборы шрифтов у разных ОС не совпадают. То есть, нет одного шрифта, чтобы он был по умолчанию установлен и на виндовс, и на линукс и и на андройд. Поэтому директива local() не применима.