Comments 65
Выжать PageSpeed 108 или больше пунктов невозможно)
Имеется в виду то что больше 100% выжать нельзя или были прецеденты когда выжимали более 100? Никогда такого не видел.
Получается: вам решать, стоит ли оно того, и прикручивать ли доп скрипты ради пользователей Mac OS или пусть вводят дату с клавы…
Как крайний случай: можно на уровне HTTP заголовков определять OS и если это Mac, то подставлять JS календарик, а всем остальным дефолтный.
Открываем: http://mol.js.org/app/demo/-/#demo=mol
И видим:
При этом, идя по чек листу:
- Используются ненативные датепикеры и прочие контролы.
- Нет минификации.
- Нет отложенной загрузки скриптов и стрилей, всё грузится сразу.
- Скрипты и стили не вкомпилены в страницу, а грузятся отдельными запросами.
- Кеширование ресурсов всего 10 минут.
- Тегов не очень много, но аттрибутов в них — много.
Однако:
- Не используются кастомные шрифты.
- Гзипоание есть.
Эта писькомерка замеряет полную загрузку страницы в браузере, а не только html.
К тому, что причина низкой скорости многих сайтов не в том, что не выполнены эти оптимизации, а в чём-то другом.
Да, целых 2 пункта из 100. И то может быть.)
Вон же выше я привёл пример, где нет этих оптимизаций, а число очков — 98.
Или вот читалка статей — 99:
Кто-то писал, что если поставить на body display:none, то результаты будут 100/100 — но это вообще плохой пример, если он работает, по сути хак)
большинства успешных аудитов за счет JavaScript, отложенная загрузка и так далее…
Нет там никакой отложенной загрузки. Вообще.
ваши примеры, это не примеры реальных сайтов
Это нереальные сайты?
а когда на ваш первый сайт захожу и начинаю быстрое пролистывание, то вижу пустоту и потом постепенно все прорисовывается… чтоб не быть голословным, беру открываю дебаг в хроме и перехожу во вкладку нетворк и начинаю листать и вижу как большинство объектов подгружаются во время прокрутки, тоесть не сразу прогружаются, а как раз во время прокрутки!
Это называется ленивый рендеринг и это не какая-то оптимизацися, это особенность фреймворка.
Мои клиенты тоже используя мой продукт смотрят на показатели гугл спида и радуются! Как вы говорите: ничего не делали и результат около 100…
И они тоже думают: это особенность cPortfolio)
Но правда заключается в том, что кто-то сделал это на фреймворке за вас, а вы пользуетесь… возможно даже не понимая как это работает и почему именно так…
А что тут рассказывать. Один фреймворк рендерит сразу всё, что замедляет открытие пропорционально размеру страницы. А другой рендерит лишь видимую область, что гарантирует высокую скорость старта без каких-то дополнительных приседаний.
Это нереальные сайты?можно и так сказать)
А вы включали Applied slow 4G
? Performance 89, Best Practices 79.
Непонятно, за что этому комментарию минусы. Реклама mol всем уже надоела, конечно, но в контексте этого поста ссылка вполне уместна. Хорошая демка, быстро загружается, всем бы так делать.
тест для мобильных и компьютеров 96
не используйте Jquery у себя в проектах и это значительно повысит скорость вашего сайтаВсе же этот совет отчасти из серии «не используйте си у себя в прогах, пишите на асме»© Простые вещи можно и напрямую JS сделать, но в jquery слишком много оптимальных решений для чуть более сложных вещей, что бы свой велосипед оправдывал себя вот прям так безапелляционно.
Но с другой стороны, если у вас на странице много чего, то влияние jquery может быть значительным…
И я с вами согласен, на jquery написано очень много классных плагинов!
Большая часть советов перекопированы с самого pagespeed, такое ощущение, что автор писать статью ради ссылки на портфолио. А если и есть советы, то они странны, мол jQuery замедляет. С таким же успехом можно написать, что и React замедляет страницу, пишите на чистом html.
jQuery и React нельзя ставить в один ряд и сравнивать их…
У них разные цели!
jQuery была создана лет 15 назад и главной ее целью было: сделать прослойку между нативным JavaScript и разработчиком и уберечь его от проблем несовместимости… Тогда действительно была проблема со стандартизацией и унификацией… у каждого браузера был свой JavaScript сильно отличающийся от других… По этой причине jQuery раньше было спасением… Даже элементарные операции порождали сотни условий и проверок, например, если вы хотели выбрать элемент по ID, то вам нужно было как минимум сделать такое:
if (document.getElementById) {
return document.getElementById(objID);
}
else if (document.all) {
return document.all[objID];
}
else if (document.layers) {
return document.layers[objID];
}
И это была вершина айсберга! Так было во всем… а Jquery в то время предложил свою унификацию $('#objID'), $('.objID') и т.д., и это очень упрощало жизнь разработчикам.
Сейчас же, у JavaScript появились стандарты, которым следуют браузеры и они их разрабатывают совместно. По этой причине, в большей степени Jquery прослойка уже лишняя, хотя очень полезная, когда нужен уже готовый плагин написанный кем-то 5 лет назад… Jquery скопилась огромная база плагинов, это огромный плюс! так что ее стоит использовать, но не для того чтоб выбирать объект по ID, а таких людей и проектов хватает)
React же, это полноценный фреймворк и цель его не прослойка между нативным JS и разработчиком, а создание пользовательского интерфейса на компонентной основе… тоесть это все равно, что сравнить небо и землю… и я конечно же не мог сказать: не используйте React…
но вы правы, чистый html быстрее)
Я прекрасно знаю что такое JQuery, но с чего вдруг он замедляет страницу? Я понимаю ещё там ветка 1.x весила много ради совместимости с ie8, но в текущей версии библиотека весит 86 кбайт, для сравнения react-dom весит 111 кбайт. Или вы считаете что PageSpeed занижает оценку из-за jQuery потому что он не модный?
Если сейчас посмотреть на гугл тест для cportfolio, то гугл тест ругается JQuery и пишет:
Устраните ресурсы, блокирующие отображение 0,15 s
…js/jquery.js(cportfolio.ru) 30 KB 780 ms
.../css?family=Roboto:100&display=swap&subset=cyrillic(fonts.googleapis.com) 1 KB 780 ms
И если я их уберу, скорее всего +1 будет, но может быть +0.9
И это не критично, по этой причине я их не убираю.
А вот год назад, гугл за такое -15 мог снять, по старым алгоритмам
А вы его хоть асинхронно подключаете? На любой большой скрипт в head не подключенный асинхронно PageSpeed будет ругаться, тут дело вовсе не в jQuery, а методе подключения.
>А вы его хоть асинхронно подключаете?
нет, и причину написал в другом комменте… сначала делал асинхронно для себя, но проблема еще в клиентах, которые вставляют свой код и у них фатальная ошибка появляется… проще оставить так, чем учить каждого клиента, отложенному исполнению кода.
Чтоб мы не помещали в тег head, все это блокирует прорисовку страницы, тоесть браузер ожидает пока прогрузится все из тега head, а уж потом начинает работать с body, и на это гугл спид обращает внимание.
Конечно можно поставить асинхронную загрузку jquery, тогда блокировки не будет, но после jquery идет код который вы написали или код плагина и есть шанс что браузер начнет его выполнять раньше чем jquery загрузится, тогда будет фатальная ошибка… можно еще делать отложенное выполнение jquery кода, что я тоже описал в статье… но это лишний гемор… так что, получается что jquery нужно загружать обычным способом в head, и он будет чуть блокировать… но это чуть относительное понятие, если например в Москве скорость инета классная, то пользователь не заметит задержки, ее не будет, а вот если вашим сайтом будет пользоваться человек из Лас-Вегаса, то он может почувствовать реальную задержку…
Конечно можно поставить асинхронную загрузку jquery, тогда блокировки не будет
Ну вот и корень всех ваших проблем с jQuery. Вы обвиняете jQuery, хотя по факту он прекрасно работает и загружается асинхронно. Самый простой способ избежать подобных фатальных ошибок — упаковать всё в один бандл с помощью webpack или подобных скриптов. Либо же использовать динамическое подключение зависимостей с каллбэком. Либо вообще банально сделать onload на скрипте с jQuery.
ее стоит использовать, но не для того чтоб выбирать объект по ID, а таких людей и проектов хватает)
да, некоторые веб аналитики часто используют такие конструкции для извлечения значений: return $().val() или тот же getElementById
А по вашему как по феншую это делать?
Суть чуть в другом… Если у вас проект, прекрасно поживает без jquery, и вы понимаете что вам нужно получить данные из поля или сделать выборку элементов по id или классу, то ошибкой будет подключать jquery для этого, вам вполне хватит нативного JavaScript.
document.getElementById('id');
document.querySelectorAll('.class');
Ну а вместо $('#id').val() использовать document.getElementById('id').value — одинаковое по функционалу, только не требует подключение дополнительной библиотеки.Но если у вас уже используется jquery в проекте и вы решили получить значение поля или выборку, то использование jquery нормально, тоесть конструкция $().val() в этом случае оправдана.
data-aload
Тут видимо используется какой-то внешний скрипт? data-атрибуты, насколько мне известно, целиком и полностью пользовательские.
Ну и рекламные блоки того же яндекса… как их?
Можете размещать их где угодно, но если вы размещаете в head, то они начнут грузиться на страницу до начала рендеринга страницы, если же вы их вставите в футере, то загрузка начнется после… Вам решать, где лучше, но влияние их минимальное!
>Ну и рекламные блоки того же яндекса… как их?
не использовал, не уверен, покажите вашу страницу с таким блоком
Ну в любом случае, с яндекс.метрикой и гугл.аналитикой вы ничего не можете сделать, так как они должны грузится сразу и их нельзя в отложенную или ленивую загрузку запихнуть… откладывается только то, что визуализируется ниже первого экрана
С одной стороны наверное они замедляют загрузку страницы, а с другой стороны не может ли поисковик «обидеться», что не стоит его метрики и тем самым понизить выдачу?
Сколько их ставить, это вам решать… может «обидеться»))
Но не только в обиде дело, и гугл и яндекс анализирует поведение пользователя на вашем сайте, количество отказов, время проведенное на нем, количество посетителей и так далее… и по этим показателям либо повышает ваш сайт в рейтинге, либо понижает… если вы убираете их счетчик, то они не могут эти показатели отследить и повышать или понижать вас не могут…
Атрибут data-aload это просто название, которое я применил в cPortfolio, мне показалось такое название более логичным и запоминающимся, хотя если вы используете библиотеку, в которой вместо атрибута data-aload, используется loading=«lazy» или class=«b-lazy» или любой другой, это сути не меняет…
Но спасибо что дали ссылку, может кому-то это поможет!)
Когда я изучал и внедрял в cPortfolio ленивую загрузку, то я взял 3 штуки топовых на тот момент и изучил их, каждую строчку кода) у каждого были свою плюсы или минусы… и потом самое лучшее из трех взял на вооружение и применил… мне лично не подходило: взять и использовать готовую, так как мне нужно было не только ленивая загрузка, а автозапуск видео, анимации при прокрутке и тому подобное… это нужно было все объединить в одно, а не вешать десятки библиотек для разных целей…
Замечу еще, что в ссылке которую вы указали, не используется атрибут data-original="" который в моем примере и я добавил когда-то в своем проекте для яндекса, чтоб этот урл считывал их бот, так как когда-то яндекс его рекомендовал для правильной индексации картинок ленивой загрузки…
Но data-original уже немного устаревшее, сейчас я в своем проекте использую микроразметку на тегах itemtype=«schema.org/ImageObject», itemprop=«contentUrl» и другие полезные атрибуты… и теперь поисковику не нужно угадывать в каком атрибуте находится реальный урл, так как есть уже стандарт микроразметки и все поисковики следуют ему…
Другие не помню…
Но, ссылку что вы дали, похоже, что именно эту библиотеку я тогда тоже встречал и возможно из-за нее решил такое название сделать атрибуту!)
Помню, что мне понравилась она тем, что очень маленькая и простая…
И решение с фоновыми картинками понравилось, своей простотой.
[data-aload] { background-image: none !important; }
А новичок просто потеряется во всем этом.
Или вот ссылка на коммент, в которой приводился пример фреймворка, в котором уже встроена отложенная и ленивые загрузки и вы об этом даже не думаете… как автор коммента сказал: ленивый рендеринг в этом фреймворке называется, но суть остается та же…
И в cProtfolio это тоже встроено.
Но если вам нужно, то просто погуглите, или тут в хабре поищите, найдете множество решений!
Разгоняем Google PageSpeed до 100 и больше