Суть то вопроса ясна и даже решение в теории тоже понятно. Но вопрос то в реализации, в коде непосредственно. Если бы я её знал, то не обратился бы с этим вопросом, очевидно же.
Подождите, причём здесь разрешение экрана и плотность пикселей?
Мы ведём речь о всех разрешениях и плотностях пикселей. Вопрос заключается в том, как подгрузить для Chrome и других формат картинок именно «webp», а для FireFox и Safari jpg или png.
А как решить вопрос с css? Если есть backgroung? Или подгрузка картинки через lazyloading? Тег picture спасёт только от конкретных мест, где стоит тег img.
Я не коим образом не хотел обделить верстальщиков, но всё же по факту вёрстка сайтов дело куда более проще чем графика, 3d или разработка тех же игр.
А свободное время можно уделять на другие занятия отличные от коддинга — спорт, творчество и тд.
Чистая работа и теория с практикой. Никаких обид и перехода на личности)
Читая мой ответ всё время держите в голове, что я делал оптимизацию ИСКЛЮЧИТЕЛЬНО для GP Speed (дальше GPS).
И внизу ещё есть комментарий, на который я дал развёрнутый ответ, может там будет что-то для Вас тоже интересно.
В первую очередь приведу пример двух сайтов. В первом ничего из моих советов не применено, во втором все пункты выполнены. drive.google.com/open?id=1EcFVkhNQki8J2ZGwKxPyMu-U_3TfJdVS; drive.google.com/open?id=1iUctTHwwbw80vK6Z-stKVvVJDpFrwFnL
1) async — он необходим для того, что бы отработать замечание из GPS которое звучит так: «Сократите время выполнения кода JavaScript», а так же «Минимизируйте работу в основном потоке».
2) Шрифты будут хоть на незначительное время, но быстрее загружаться. Как и говорил, вместе 180ms у меня сейчас 70-90ms.
3) В DOM структуре сайта остаётся и тег img и alt описание, и title. Вы просто не подгружаете её пока не видите. Робот поисковика всё-равно её увидит. (я не разработчик поисковиков, но думаю что это так). Потому что я в google картинка и Яндекса есть наши картинки, если сузить поиск, хотя бы прописав её alt или ссылку на сайт.
Почему именно этот, потому что он проверенный мною и у меня ни разу не было с ним проблем.
4) По поводу webp, нам пришлось отключить pagespeed на нашем сервере, не смотря на то, что он все картинки преобразовывал в webp из-за того, что по сухим цифрам на GPS скорость при включенном pagespeed на 10 баллов меньше. И так было со всеми сайтами. От 10 до 5 баллов плюс после отключения.
5) Опять-таки, увеличение структуры DOM из-за 50 лишних узлов плохо не повлияет на скорость загрузки страницы и на оценку в GPS. А вот 5 лишних svg иконок могут попасть в раздел «Оптимизация, и там будут просить их отложить, скрыть, использовать формат нужны и тд. Как только я начал на сайте все svg переводить в код, то ни разу больше не было рекомендаций от GPS по этому поводу.
Спасибо за критику и комментарий. Я выше уже ответил человеку на развёрнутую критику, прочитайте мой ответ. Он по сути и Вас тоже касается.
Но Вам я немного дополню по пунктам.
1) JS. Я там одним предложением, которое вы не поняли (Простите, не понял о чем вы, что за скрипт на первом экране?) и имел ввиду то, что Вы описали 6-ю пунктами) Просто вы более обширно обозначили что нужно добавлять async на свой риск и учитывать выполнение скрипта в разных время и в разных местах.
А по поводу первого экрана — просто пример клиент хочет пустить зимой снег на СТАРТОВЫЙ экран, прям на header. Так вот этому скрипту можно и не задавать async, как вы и сказали. Но если он захочет его пустить где-нибудь в середине или в конце, то ОБЯЗАТЕЛЬНО нужно ему дать async.
GTM я думаю всё и так знают что работает стабильно и загружается асинх. по этому я не упоминал это.
Во 2-3 пункте js прям хорошие толковые советы, я их даже допишу в статью, если буду делат «часть 2, с Вашего позволения. Но мы с Вами и так понимаем, что это достаточно банальные вещи. Я же это делаю для совсем новичков.
2) CSS
1.1 А с чего вы это взяли? Я и на localhost и на сервере проверил в самхы разных разрешениях весь сайт. Ничего ни разу не подгружалось и не перерисовывалось. Всё согласно УЖЕ ЗАРАНЕЕ подгруженным media запросом становилось на свои места. По этому это замечание не имеет место быть.
1.2 Тут я же не понял. В чём проблема и по очереди загружать. У меня ещё не встречалось такого, что бы целый файл css не нужен был с самого начала. Это что же за элемент или случай такой, ради которого нужен отдельный css, который нужно подгружать позже… в общем не понятно. Страница загрузилась и весь css загрузился по очереди, точка.
1.3 LoadCSS.js протестирую. Пока не работал с этим.
2.1-2.2 Совершенно верно. Я показывал это руководству, это не проблема. У нас лендинги, по этому перезагрузка страницы у нас вообще не производится. Разве что пользователь сам её сделает. И всё скачен, но благо это длится 1-4 секунды. Не красиво, но таково требование. По этому сначала стартовый экран, а потом уже main.css. И да, мне нужно было об этом упомянуть в статье, о скачках.
ШРИФТЫ
1-4 font-display ну и что, что он 25%. Прописать то всё-равно нужно и дальше продолжать оптимизировать этот аспект. Пусть себе висит в @ font
-face и помогает где может, он ничего не нарушит. И пока грузится страница используется ВСТРОЕННЫЙ в браузер шрифт и ничего второго не рендерится. Он ообще не на сервере находится, нечему рендерится. И даже если там что-то при каждом открытии любого сайта рендерится (arial, robots, sans-serif и тд), то это даже не заметно, там милисекунда и готово. тут дело вкуса — во время подгрузки шрифта пустое место или отображение текста хоть как-то. И напомню, что это отдельное замечание в GPSpeed, для которого эта статья и предназначалась.
5 Это тоже протестирую.
Подключение шрифтов. 2 Вы быстрее пробежите 40 метров или 200? А зачем тогда заставлять main.css бегать в лишнюю папку, и там искать файлы? Пусть они сразу будут вплотную друг к другу. И да, по цифрам я уверен, лично проверил. Хоть это и милисекунды, но так ведь и добивается оптимизация, по крупицам.
ИЗОБРАЖЕНИЯ
1 — 2.1 lazysizes.js — не работал с этим, протестирую.
Спасибо за критику и комментарий. Я внимательно прочитал и с частью из сказанного Вами согласен. Но Вы, видимо, не поняли мой главный посыл статьи. Я там прямо указал, что это оптимизация сайта для GooglePage Speed (PageSpeed Insights — Google Developers, называйте как хотите, главное что бы мы понимали о чём речь). Я НЕ говорил, что это самые грамотные, самые толковые советы для оптимизации сайта по самым лучшим решениям 2019 года, и которые спасут и Вашу вёрстку и сайт. Нет. Я лишь увидел, что после обновления GPSpeed сайт, который имел 90/100 получил оценку в 63/86 баллов. И после того как я применил всё сказанное в моей статье к этому сайту, то вернул на компьютере стабильно 100, а на телефоне колеблется от 86 до 93 (видимо зависит ещё от скорости и загруженности сервера и собственно компьютера и сети в момент проверки).
Вы спросите почему я так топлю за эти баллы, так это просто требование руководства))
1) Кеширование, Gzip, правильное расположение скриптов это даже упоминать не надо, давно уже должно быть у всех по дефолту)). Но лишний раз можно напомнить, для совсем новичков.
2) Карты да, тут можно либо подключать её по кнопке, например, вообще делать отдельной страницей (на сам Яндекс или Google).
3) Sprite я использую не только для иконок, а даже для картинок размером до 200кб. Когда их много в одной секции и на них нету никакого функционала (например в секции положительных сторон компании, где обычный текст, и картинка для красоты, но она 400px d ширину). В результате мы убрали лишние запросы на сервер, и одна большая картинка будет меньше весить, чем те по отдельности.
Спасибо за совет. Но здесь сработает только для тех, кто подключает шрифты отдельным файлом, например, fonts.css. А я предпочитаю подключать их напрямую чистым кодом в main.css. Но я обязательно проверю Ваш способ, может так будет даже лучше.
Да, есть решения:
1) Определить какие именно картинки двигают контент по мере подгрузки и дать их родителям фиксированную ширину. Этим вы полностью избавите от этих скачков.
Плюсы — скорость решения, гарантия избавления себя от этой проблемы.
Минусы — адаптив, ведь придётся убирать фиксированные размеры. И это может быть не очень грамотно, но мы сейчас ведё речь об оптимизации, а не красоте вёрстки.
2) Изначально делать дизайн и вёрстку так, что бы картинки не были главными в определении размера блока. Пусть либо текст, либо какой-нибудь другой контент будет больше картинки в блоке.
3) Использование sprite. Там ведь изначально есть заданная ширина и высота, потому что там не картинка как img, а background.
С нетерпением жду от Вас статью на эту тему! Не хочется ждать ещё целый год обновления пользователей Mozilla Firefox.
(если статья ещё не скоро будет, то буду крайне признателен, если в личку дадите необходимую информацию или же её крупицы)
Мы ведём речь о всех разрешениях и плотностях пикселей. Вопрос заключается в том, как подгрузить для Chrome и других формат картинок именно «webp», а для FireFox и Safari jpg или png.
А свободное время можно уделять на другие занятия отличные от коддинга — спорт, творчество и тд.
Читая мой ответ всё время держите в голове, что я делал оптимизацию ИСКЛЮЧИТЕЛЬНО для GP Speed (дальше GPS).
И внизу ещё есть комментарий, на который я дал развёрнутый ответ, может там будет что-то для Вас тоже интересно.
В первую очередь приведу пример двух сайтов. В первом ничего из моих советов не применено, во втором все пункты выполнены. drive.google.com/open?id=1EcFVkhNQki8J2ZGwKxPyMu-U_3TfJdVS; drive.google.com/open?id=1iUctTHwwbw80vK6Z-stKVvVJDpFrwFnL
1) async — он необходим для того, что бы отработать замечание из GPS которое звучит так: «Сократите время выполнения кода JavaScript», а так же «Минимизируйте работу в основном потоке».
2) Шрифты будут хоть на незначительное время, но быстрее загружаться. Как и говорил, вместе 180ms у меня сейчас 70-90ms.
3) В DOM структуре сайта остаётся и тег img и alt описание, и title. Вы просто не подгружаете её пока не видите. Робот поисковика всё-равно её увидит. (я не разработчик поисковиков, но думаю что это так). Потому что я в google картинка и Яндекса есть наши картинки, если сузить поиск, хотя бы прописав её alt или ссылку на сайт.
Почему именно этот, потому что он проверенный мною и у меня ни разу не было с ним проблем.
4) По поводу webp, нам пришлось отключить pagespeed на нашем сервере, не смотря на то, что он все картинки преобразовывал в webp из-за того, что по сухим цифрам на GPS скорость при включенном pagespeed на 10 баллов меньше. И так было со всеми сайтами. От 10 до 5 баллов плюс после отключения.
5) Опять-таки, увеличение структуры DOM из-за 50 лишних узлов плохо не повлияет на скорость загрузки страницы и на оценку в GPS. А вот 5 лишних svg иконок могут попасть в раздел «Оптимизация, и там будут просить их отложить, скрыть, использовать формат нужны и тд. Как только я начал на сайте все svg переводить в код, то ни разу больше не было рекомендаций от GPS по этому поводу.
Но Вам я немного дополню по пунктам.
1) JS. Я там одним предложением, которое вы не поняли (Простите, не понял о чем вы, что за скрипт на первом экране?) и имел ввиду то, что Вы описали 6-ю пунктами) Просто вы более обширно обозначили что нужно добавлять async на свой риск и учитывать выполнение скрипта в разных время и в разных местах.
А по поводу первого экрана — просто пример клиент хочет пустить зимой снег на СТАРТОВЫЙ экран, прям на header. Так вот этому скрипту можно и не задавать async, как вы и сказали. Но если он захочет его пустить где-нибудь в середине или в конце, то ОБЯЗАТЕЛЬНО нужно ему дать async.
GTM я думаю всё и так знают что работает стабильно и загружается асинх. по этому я не упоминал это.
Во 2-3 пункте js прям хорошие толковые советы, я их даже допишу в статью, если буду делат «часть 2, с Вашего позволения. Но мы с Вами и так понимаем, что это достаточно банальные вещи. Я же это делаю для совсем новичков.
2) CSS
1.1 А с чего вы это взяли? Я и на localhost и на сервере проверил в самхы разных разрешениях весь сайт. Ничего ни разу не подгружалось и не перерисовывалось. Всё согласно УЖЕ ЗАРАНЕЕ подгруженным media запросом становилось на свои места. По этому это замечание не имеет место быть.
1.2 Тут я же не понял. В чём проблема и по очереди загружать. У меня ещё не встречалось такого, что бы целый файл css не нужен был с самого начала. Это что же за элемент или случай такой, ради которого нужен отдельный css, который нужно подгружать позже… в общем не понятно. Страница загрузилась и весь css загрузился по очереди, точка.
1.3 LoadCSS.js протестирую. Пока не работал с этим.
2.1-2.2 Совершенно верно. Я показывал это руководству, это не проблема. У нас лендинги, по этому перезагрузка страницы у нас вообще не производится. Разве что пользователь сам её сделает. И всё скачен, но благо это длится 1-4 секунды. Не красиво, но таково требование. По этому сначала стартовый экран, а потом уже main.css. И да, мне нужно было об этом упомянуть в статье, о скачках.
ШРИФТЫ
1-4 font-display ну и что, что он 25%. Прописать то всё-равно нужно и дальше продолжать оптимизировать этот аспект. Пусть себе висит в @ font
-face и помогает где может, он ничего не нарушит. И пока грузится страница используется ВСТРОЕННЫЙ в браузер шрифт и ничего второго не рендерится. Он ообще не на сервере находится, нечему рендерится. И даже если там что-то при каждом открытии любого сайта рендерится (arial, robots, sans-serif и тд), то это даже не заметно, там милисекунда и готово. тут дело вкуса — во время подгрузки шрифта пустое место или отображение текста хоть как-то. И напомню, что это отдельное замечание в GPSpeed, для которого эта статья и предназначалась.
5 Это тоже протестирую.
Подключение шрифтов. 2 Вы быстрее пробежите 40 метров или 200? А зачем тогда заставлять main.css бегать в лишнюю папку, и там искать файлы? Пусть они сразу будут вплотную друг к другу. И да, по цифрам я уверен, лично проверил. Хоть это и милисекунды, но так ведь и добивается оптимизация, по крупицам.
ИЗОБРАЖЕНИЯ
1 — 2.1 lazysizes.js — не работал с этим, протестирую.
Вы спросите почему я так топлю за эти баллы, так это просто требование руководства))
2) Карты да, тут можно либо подключать её по кнопке, например, вообще делать отдельной страницей (на сам Яндекс или Google).
3) Sprite я использую не только для иконок, а даже для картинок размером до 200кб. Когда их много в одной секции и на них нету никакого функционала (например в секции положительных сторон компании, где обычный текст, и картинка для красоты, но она 400px d ширину). В результате мы убрали лишние запросы на сервер, и одна большая картинка будет меньше весить, чем те по отдельности.
1) Определить какие именно картинки двигают контент по мере подгрузки и дать их родителям фиксированную ширину. Этим вы полностью избавите от этих скачков.
Плюсы — скорость решения, гарантия избавления себя от этой проблемы.
Минусы — адаптив, ведь придётся убирать фиксированные размеры. И это может быть не очень грамотно, но мы сейчас ведё речь об оптимизации, а не красоте вёрстки.
2) Изначально делать дизайн и вёрстку так, что бы картинки не были главными в определении размера блока. Пусть либо текст, либо какой-нибудь другой контент будет больше картинки в блоке.
3) Использование sprite. Там ведь изначально есть заданная ширина и высота, потому что там не картинка как img, а background.
(если статья ещё не скоро будет, то буду крайне признателен, если в личку дадите необходимую информацию или же её крупицы)