Вы правы, это нечестно по отношению к человеку. В погоне за этими балами, позициями в поиске, все мы стали забывать, что сайты делаются прежде всего для человека. У нас в компании так же, когда приступаем к разработке проекта в первую очередь мысли о сео, продвижении. Пишется, закупается куча текстов, неинтересных и не ненужных нормальному человеку, впихиваются на страницу всякие "фразы", вызывающие отторжение при чтении, но зато так любимые яндексом. В общем про человека если и подумаем, то в самом конце если останется на него время.
А потом на сайт впиливается тонна рекламы, которая просто закрывает весь контент который там есть. И те же поисковые роботы на это никак не реагируют. Выдают захламленные рекламой сайты в начале списка. Вот просто, у меня в локальной сети стоит dns сервер для блокировки рекламы. У меня за сутки может быть до 50 тысяч заблокированных рекламных запросов. Это не нормально.
Дим, спасибо за видео, поставил лайк) Я думаю, это было бы полезно если это можно было бы настроивать конкретно для компонента, когда ты начал с ним взаимодействовать. Например, так сделано в одном из недавно вышедшем фреймворке ( не помню название ), который кличали убийцей реакта, там как раз весь изначальный js код - это одни обработчики кликов/скролов в компонентах для загрузки уже основного js бандла для этого компонента.
мне кажется, вы излишне драматизируете ) можно же сразу загрузить js для тоглера и еще каких-то мелочей для стартового куска страницы (про мобильную версию речь), а потом по событию загрузить остальное. Не?
ну всё просто, во первых определяем что это мобилка, минимальный js повесить на первый экран, там на меню и ещё что-то. Остальное уже если он начал скролить и тд, подгружем блочно необходимые скрипты
Я вот не понимаю, а в чем проблема в начале грузить скрипты на для активности на стартовом экране, а потом по любому эвенту догружать всё остальное, типа сложной логики, поиска и запросов?
ну вообще как я вижу, там все можно настроить до мелочей. Во-первых как я вижу, там можно выделять целые компоненты для отложенной гидратации, то есть у нас основной интерактивный контент, на который может нажать пользователь будет загружен. дальше гидратацию по ивенту на мобиле, как я понял, там для разных устройств (desktop, mobile), можно писать свои правила, то есть на мобиле это можно отключить или делать выборочной теми же компонентами. Поэтому если есть свободное время и необходимость в этих баллах, то думаю можно будет выделить на своем сайте места и случаи, где это можно применить.
Если дословно, вообще не гидрировать страницу, то это будет боль для юзера. А так в целом это хороший подход, но с уточнением. Если блоки скрыты и/или мы точно понимаем, что пользователь не воспользуется ими в момент загрузки, то такие блоки можно гидрировать по необходимости, каждый индивидуально. К примеру меню с большим списком категорий, которое изначально скрыто. Можем его гидрировать в момент открытия, даже на мобильном устройстве это норм отрабатывает. Или на странице 10 экранов, с 3 можно не гидрировать, только по скроллу или по позиции. Но страницу целиком - никогда)
А не проще поисковые системы научить нормально выполнять js и вести себя как браузер клиента? Или может пора уже забить на кучу метрик и делать сайты удобными, в первую, очередь для пользователя?
@@bassboosted1184 ну эта метрика тоже сделана не просто так. если мы долго выполняем js то на это время мы блочим main tread и ничего что в нем должно выполниться не выполнится пока наш js не закончит свою работу. а это влияет на интерактивность страницы и следовательно на пользовательский опыт
это хорошо в рамках оптимизации бандлов, но плохо в рамках поддержки проекта, а так же создает небольшие проблемы для дебага. этот путь IT уже прошло и из него родился адаптив. как и многое в современной разработке - хуже оптимизация, дешевле поддержка и развитие. хотя опять же, вопрос к целевой аудитории и ее техническим ограничениям
@@MrJaroslav682 на сколько я помню, гугл перестал учитывать десктоп версию в поисковой выдаче. по этому основные оптимизации идут с прицелом на мобилку. но опять же вопрос, если на сайте есть SSR, зачем роботу вообще отдавать хоть один рабочий скрипт?
Хмм, не нравится мне загрузка js после какого либо события от пользователя. Хотя и идея загрузки страницы через SSR, а только потом загрузки js для интерактива очень даже не плоха. Что если загружать js по событию window.onload (или ему подобный, смысл в том чтобы загружать js только после полной загрузки html, css и полного его рендера). То есть не ждать действия от пользователя, а загрузить js сразу после того как отрендерился контент который прислал сервер. Таким образом поисковый робот сразу получит готовую вёрстку (SSR), но при использовании этого приложения реальными пользователями мы не ждём никаких действий со стороны пользователя, а загружаем сразу после рендера статической страницы. Адекватные замечания и предложения приветствуются.
Эта хрень творится с Гуглом уже лет 8. Хотя раньше было попроще бороться с его хотелками. Маразм крепчает. И деваться некуда, если нужно двигаться в Гугле в топы.
Как вариант можно велосипед подпереть костылем. Все кнопочки и пагинашки и прочее оформить в виде обычных стилизованных ссылок) Это не панацея и не везде спасет, но все же) Можно так же побольше работы отдавать css, да сайт все еше будет статичным но "чистые" анимашки поразвлекают пару секунд до загрузки js. Так же можно подумать в сторону отслеживания нажатия на конкретном месте и мгновенно подгрузить мелкий хендлер конкретно под произошедшее действие, но опять таки нужен для простоты какой то мелкий js скрипт уже предзагруженный или инлайном вписанный в разметку... В общем костыли и велосипеды)
@@rodigy зависит от слайдера. Если загуглить "слайдер исключительно на css" то можно найти кучу крутого и без js. Там и цыкличные, и с управлением, и с автостартом))) Опть же, я указал что это не панацея от всех заскоков.
total bloking time это не время выполнения нашего js только то время когда js синхронно выполняет таску более 50мс. мы можем несколько секунд выполнять гидратацию и иметь 0 в TBT но важно чтобы эти секунды были разбиты на несколько тасок каждая из которых менее 50мс. таким образом можно начать гидрировать страницу сразу после загрузки и тратить на это все ресурсы cpu и при этом иметь хороший показатель TBT и лучший пользовательский опыт.
@@rodigy так не надо контролировать в рантайме. ведь не стоит цели свести tbt у всех пользователей до 0. Цель его максимально возможно уменьшить. Чтобы контролировать этот процесс можно открыть вкладку performance в девтулзах и записать профайл загрузки. там на таймлайне main треда подсвечиваются проблемные таски как long task. понятно что на разных устройствах результат будет отличаться. но относительное время выполнения тасок оттуда можно понять. БОльшая проблема в том как при этой оптимизации не потерять порядок выполнения кода.
@@MrJaroslav682 Ну если ориентироваться в среднем по больнице по устройствах. Но тема впринципе интересная, как можно свести к 0 tbt, особенно если подключаются сторонние либы типа аналитики или есть сборщики.
Те, кто работают в конкурентной нише, будут делать такого рода хаки ибо ничего не заработают, не вижу криминала здесь, я еще до спа такое проворачивал с анимацией, каруселями т.д. например, более того у нас бек для краулеров вообще js не отдавал из-за метрик
Ну, тут явное "решение несуществующих проблем", т.е. улучшение метрик ради самих метрик. Метрики, кстати, тоже ведь не в граните высечены, и если какая-то нарушает здравый смысл, то ее следует проигнорировать.
Все существующие метрики априори нарушают здравый смысл, ибо получается что сайты создают не для людей, а для метрик, а как там людям, удобно или нет, вопрос уже второстепенный.
Мне, иногда, кажется, что у нас сайты делают не для людей, а для поисковых роботов, паралельно мастурбируя на показатели синтетических тестов. Научить роботов поисковых систем нормально выполнять js? Не нах оно надо.
Офигеть бредятина этот Delayed Hydration. Гугл роботу получается "лизнули", а пользователь ещё дольше будет ожидать "готового" интерфейса для нормального взаимодействия с сайтом. 🤨
Соглашусь с автором, что обманывать поисковые роботы может привести к негативным последствиям в будущем, особенно если это ведет к ухудшению пользовательского опыта. Пользователи всегда стоят на первом месте, и удовлетворение их потребностей и ожиданий должно быть важнейшей задачей веб-разработчиков.
Огонь разбор веба по этапам!🔥 нагуглил ролик по слову hydration и понял от тебя, что это, Спасибо!
Вы правы, это нечестно по отношению к человеку. В погоне за этими балами, позициями в поиске, все мы стали забывать, что сайты делаются прежде всего для человека. У нас в компании так же, когда приступаем к разработке проекта в первую очередь мысли о сео, продвижении. Пишется, закупается куча текстов, неинтересных и не ненужных нормальному человеку, впихиваются на страницу всякие "фразы", вызывающие отторжение при чтении, но зато так любимые яндексом. В общем про человека если и подумаем, то в самом конце если останется на него время.
А потом на сайт впиливается тонна рекламы, которая просто закрывает весь контент который там есть. И те же поисковые роботы на это никак не реагируют. Выдают захламленные рекламой сайты в начале списка. Вот просто, у меня в локальной сети стоит dns сервер для блокировки рекламы. У меня за сутки может быть до 50 тысяч заблокированных рекламных запросов. Это не нормально.
Дим, спасибо за видео, поставил лайк)
Я думаю, это было бы полезно если это можно было бы настроивать конкретно для компонента, когда ты начал с ним взаимодействовать. Например, так сделано в одном из недавно вышедшем фреймворке ( не помню название ), который кличали убийцей реакта, там как раз весь изначальный js код - это одни обработчики кликов/скролов в компонентах для загрузки уже основного js бандла для этого компонента.
мне кажется, вы излишне драматизируете ) можно же сразу загрузить js для тоглера и еще каких-то мелочей для стартового куска страницы (про мобильную версию речь), а потом по событию загрузить остальное. Не?
Дёргать мышкой, чтобы страничка быстрее загрузилась снова актуально
ну всё просто, во первых определяем что это мобилка, минимальный js повесить на первый экран, там на меню и ещё что-то. Остальное уже если он начал скролить и тд, подгружем блочно необходимые скрипты
Я вот не понимаю, а в чем проблема в начале грузить скрипты на для активности на стартовом экране, а потом по любому эвенту догружать всё остальное, типа сложной логики, поиска и запросов?
ну вообще как я вижу, там все можно настроить до мелочей. Во-первых как я вижу, там можно выделять целые компоненты для отложенной гидратации, то есть у нас основной интерактивный контент, на который может нажать пользователь будет загружен. дальше гидратацию по ивенту на мобиле, как я понял, там для разных устройств (desktop, mobile), можно писать свои правила, то есть на мобиле это можно отключить или делать выборочной теми же компонентами. Поэтому если есть свободное время и необходимость в этих баллах, то думаю можно будет выделить на своем сайте места и случаи, где это можно применить.
Для мобильников можно было бы в код к ивентам добавить, акселерометр, жесты, фейс рекогнишн и т.п.
Может для мобильников отдельное условие есть? Вычислить то можно.
А будет курс по nuxt 3?
Если дословно, вообще не гидрировать страницу, то это будет боль для юзера. А так в целом это хороший подход, но с уточнением. Если блоки скрыты и/или мы точно понимаем, что пользователь не воспользуется ими в момент загрузки, то такие блоки можно гидрировать по необходимости, каждый индивидуально. К примеру меню с большим списком категорий, которое изначально скрыто. Можем его гидрировать в момент открытия, даже на мобильном устройстве это норм отрабатывает. Или на странице 10 экранов, с 3 можно не гидрировать, только по скроллу или по позиции. Но страницу целиком - никогда)
А не проще поисковые системы научить нормально выполнять js и вести себя как браузер клиента? Или может пора уже забить на кучу метрик и делать сайты удобными, в первую, очередь для пользователя?
@@bassboosted1184 ну эта метрика тоже сделана не просто так. если мы долго выполняем js то на это время мы блочим main tread и ничего что в нем должно выполниться не выполнится пока наш js не закончит свою работу. а это влияет на интерактивность страницы и следовательно на пользовательский опыт
Ну это зависит от того, для чего вы сайт делаете, для того чтобы людям было на нем удобно или для максимальных циферок в метриках. 🤔
СпС, Поезидент, Я засыпаю под Тебя))))
Гугл давно с ума сходит
Мы как разрабы лишь реагируем на его заскоки и страдают все
У меня spa сайт Яндекс проиндексировал. Я удивился, где-то 2 месяца назад обнаружил
А что если делать отдельные сборки в прод., для деск. и мобилок
это хорошо в рамках оптимизации бандлов, но плохо в рамках поддержки проекта, а так же создает небольшие проблемы для дебага. этот путь IT уже прошло и из него родился адаптив. как и многое в современной разработке - хуже оптимизация, дешевле поддержка и развитие. хотя опять же, вопрос к целевой аудитории и ее техническим ограничениям
ну гугл отдельно оценивает мобильную версию и десктопную. по десктопной TBT будет хорош а по мобильной плох
@@MrJaroslav682 на сколько я помню, гугл перестал учитывать десктоп версию в поисковой выдаче. по этому основные оптимизации идут с прицелом на мобилку. но опять же вопрос, если на сайте есть SSR, зачем роботу вообще отдавать хоть один рабочий скрипт?
Хмм, не нравится мне загрузка js после какого либо события от пользователя. Хотя и идея загрузки страницы через SSR, а только потом загрузки js для интерактива очень даже не плоха. Что если загружать js по событию window.onload (или ему подобный, смысл в том чтобы загружать js только после полной загрузки html, css и полного его рендера).
То есть не ждать действия от пользователя, а загрузить js сразу после того как отрендерился контент который прислал сервер. Таким образом поисковый робот сразу получит готовую вёрстку (SSR), но при использовании этого приложения реальными пользователями мы не ждём никаких действий со стороны пользователя, а загружаем сразу после рендера статической страницы.
Адекватные замечания и предложения приветствуются.
Эта хрень творится с Гуглом уже лет 8. Хотя раньше было попроще бороться с его хотелками. Маразм крепчает. И деваться некуда, если нужно двигаться в Гугле в топы.
Amp версии сайтов работают по схожему принципу, некоторые скрипты отрабатывают только после взаимодействия клиента с сайтом.
Как вариант можно велосипед подпереть костылем.
Все кнопочки и пагинашки и прочее оформить в виде обычных стилизованных ссылок)
Это не панацея и не везде спасет, но все же)
Можно так же побольше работы отдавать css, да сайт все еше будет статичным но "чистые" анимашки поразвлекают пару секунд до загрузки js.
Так же можно подумать в сторону отслеживания нажатия на конкретном месте и мгновенно подгрузить мелкий хендлер конкретно под произошедшее действие, но опять таки нужен для простоты какой то мелкий js скрипт уже предзагруженный или инлайном вписанный в разметку...
В общем костыли и велосипеды)
есть такой фрейм, забыл название, разбивает все на микро хендлеры и подгружает их по необходимости.
Вот интересно как ты отвелосипедишь слайдер с автостартом.
@@rodigy зависит от слайдера. Если загуглить "слайдер исключительно на css" то можно найти кучу крутого и без js. Там и цыкличные, и с управлением, и с автостартом))) Опть же, я указал что это не панацея от всех заскоков.
total bloking time это не время выполнения нашего js только то время когда js синхронно выполняет таску более 50мс. мы можем несколько секунд выполнять гидратацию и иметь 0 в TBT но важно чтобы эти секунды были разбиты на несколько тасок каждая из которых менее 50мс. таким образом можно начать гидрировать страницу сразу после загрузки и тратить на это все ресурсы cpu и при этом иметь хороший показатель TBT и лучший пользовательский опыт.
В теории, на практике кто то это применял?
ну я применял, поэтому и написал@@rodigy
@@MrJaroslav682 А вот это уже интересно. Как контролировать время выполнения таски меньше 50мс?
@@rodigy так не надо контролировать в рантайме. ведь не стоит цели свести tbt у всех пользователей до 0. Цель его максимально возможно уменьшить. Чтобы контролировать этот процесс можно открыть вкладку performance в девтулзах и записать профайл загрузки. там на таймлайне main треда подсвечиваются проблемные таски как long task. понятно что на разных устройствах результат будет отличаться. но относительное время выполнения тасок оттуда можно понять.
БОльшая проблема в том как при этой оптимизации не потерять порядок выполнения кода.
@@MrJaroslav682 Ну если ориентироваться в среднем по больнице по устройствах. Но тема впринципе интересная, как можно свести к 0 tbt, особенно если подключаются сторонние либы типа аналитики или есть сборщики.
Ох эта вечная война c сео.
Гугл возьмет да и сделает какое-нибудь событие при старте, снова заплачут горе оптимизаторы....
Всему виной чертово SEO, увы...
Те, кто работают в конкурентной нише, будут делать такого рода хаки ибо ничего не заработают, не вижу криминала здесь, я еще до спа такое проворачивал с анимацией, каруселями т.д. например, более того у нас бек для краулеров вообще js не отдавал из-за метрик
Самому противно, но приходится иногда делать. Ибо сео говорит "Надо больше баллов в pagespeed". Надеюсь в аду есть отдельный котёл для всех сеошников.
По таймеру грузить, поставить вместо 7000 значение 1
А разве нельзя эту отложенную гидратацию делать только для роботов? роботы разве не сообщают о себе?
Ну, тут явное "решение несуществующих проблем", т.е. улучшение метрик ради самих метрик. Метрики, кстати, тоже ведь не в граните высечены, и если какая-то нарушает здравый смысл, то ее следует проигнорировать.
Все существующие метрики априори нарушают здравый смысл, ибо получается что сайты создают не для людей, а для метрик, а как там людям, удобно или нет, вопрос уже второстепенный.
ну чо каеф 😁
Нужен курс по nuxt, а то начал изучать и что-то тяжело идет с логикой jwt-токенов для авторизации))
ну а ведь еще все-таки табом и клавой пользуются, а11у как бы
Мне, иногда, кажется, что у нас сайты делают не для людей, а для поисковых роботов, паралельно мастурбируя на показатели синтетических тестов. Научить роботов поисковых систем нормально выполнять js? Не нах оно надо.
Ужас!
Да вообще все к этому и идет. Технологий все больше - сайты все медленнее.
Чуваки из Накст решили хакнуть гугл 🤣
только у меня при слове гидротация первая ассоциация что сейчас будут про "drome keeper" рассказывать))
Офигеть бредятина этот Delayed Hydration. Гугл роботу получается "лизнули", а пользователь ещё дольше будет ожидать "готового" интерфейса для нормального взаимодействия с сайтом. 🤨
а ssr не бредятина?
На некст пора валить, там все бабки
шляпа
А что , есть практические кейсы, когда без этой фичи падал рейтинг в аналитике ? Хм… слабо верю
Соглашусь с автором, что обманывать поисковые роботы может привести к негативным последствиям в будущем, особенно если это ведет к ухудшению пользовательского опыта. Пользователи всегда стоят на первом месте, и удовлетворение их потребностей и ожиданий должно быть важнейшей задачей веб-разработчиков.