{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Ускорение сайта или вред для SEO: отложенная загрузка метрик и ее влияние на показатель отказов

Решение написать пост было принято ввиду популяризации статей на тему ускорения сайтов на vc.ru и сотен комментариев под материалами в разделе SEO.

Во всех постах дублируются известные приемы оптимизации страниц сайтов вроде lazyload загрузки изображений, кеширования, GZIP и др., которые в "пузомерках" вроде Google Pagespeed Insights дают небольшой прирост, но на деле реально эффективны.

Для достижения вожделенной "зеленой зоны" (оценки 100/100 по тестам Pagespeed Insights), остается нерешенным вопрос долгой загрузки и блокировки страницы сторонними скриптами метрик (Google Analytics, Яндекс.Метрика, Facebook Pixel и другие).

Единственное предлагаемое решение - отложенная загрузка и выполнение данных скриптов. Но насколько такой подход оправдывает цель?

Более глубокого изучения данное решение не удостоилось, поэтому пришла мысль провести "коллективную дискуссию" - приглашаю вас в комментарии.

Вопрос достаточно емкий, и без небольшого бэкграунда не обойтись, поэтому разделим его на следующие тезисы (от общего к частному):

  1. цель оптимизации сайта (влияние скорости загрузки на SEO);
  2. объективность оценок сервисов Google Pagespeed Insights и подобных;
  3. отложенная инициализация метрик и показатель отказов.

Возможно, данный вопрос не настолько острый и важный, чтобы писать для него отдельный материал, но:

  • в комментариях тесно для изложения мыслей на этот счет;
  • интересно разобраться в вопросе основательно.

Простите за долгое предисловие, не планировал лонгрид. Это не гайд (инструкция), не кейс (разбор), а скорее ресёрч (исследование).

Зачем ускорять сайт, и как оценить результат?

Прежде чем приступать к любой работе - важно понимать, какую цель преследует данный манёвр. Простыми словами - зачем это нужно?

Смысл оптимизации скорости загрузки сайта заключается в следующем:

  1. улучшить опыт пользователя - сократить время ожидания загрузки страницы, и тем самым минимизировать показатель отказов;
  2. в следствии п.1. ожидать преференции от поисковых систем в выдаче (не только благодаря быстрой загрузке, но и улучшению ПФ - снижению показателя отказов).

В целом тезисы ясны, но что считать быстрой загрузкой? Да, необходимое время загрузки в 1-2 секунды, и красивый график с показателями отказов все видели.

Красивый график с показателями отказов https://backlinko.com/hub/seo/bounce-rate

НО! К сожалению, показатель скорости загрузки сайта зависит от множества факторов:

  • тип устройства и его мощность (ПК, планшет, смартфон);
  • заявленная скорость интернет соединения (провайдер);
  • фактическая скорость (загрузка канала, качество сигнала и т.п.).

Следовательно, говорить об абсолютной оптимизации и постоянной скорости загрузки не представляется возможным.

Однако, существуют популярные сервисы замера скорости загрузки сайта. Насколько в таком случае точна их оценка? Стоит ли гнаться за 100/100?

Проверка скорости загрузки сервисами

Такие инструменты как Google Pagespeed Insights (и другие, на базе Lighthouse), используют для своих тестов эмуляцию конкретных устройств, которые, по их мнению, подходят для этого.

Интересно было бы узнать, как проходит отбор таких устройств. Возможно, по усредненным техническим характеристикам, или по популярности распространения устройств, схожих по ТХ.

Интересно, что на сегодняшний день, в Lighthouse для тестирования скорости загрузки сайта используется устройство 2016 года выпуска - Motorola Moto G4 на базе процессора Snapdragon 617 от 2015 года.

При этом используется достаточно хорошее интернет соединение - 1,6Mbps/750Kbps - эквивалентный медленному 4G или быстрому 3G. Тестировали бы уже на EDGE. 🙃

Конечно, для гиков гаджеты - это все, и ориентироваться на работников сферы IT было бы не верным решением.

Но в эпоху, когда Apple наполняет рынок десятками моделей смартфонов, соревнуясь с Xiaomi, Samsung и Huawei у кого телефон более бюджетный, при средней комплектации, ориентироваться на Moto G4, кажется, тоже не совсем корректно.

Для получения реальных данных по мобильным устройствам, использующихся аудиторией вашего сайта, перейдите в Google Analytics - Аудитория - Мобильные устройства - Устройства.

Перечень моделей мобильных устройств пользователей сайта

Немного про железо

Проанализировав топ мобильных устройств своего сайта и, на основании технических данных этих устройств, сравним процессоры и их производительность с процессором Snapdragon 617, установленным в Moto G4, используемом в тестах Lighthouse.

Сравнение мощностей процессоров мобильных устройств посетителей с устройством эмулирующим загрузку в синтетических тестах Lighthouse.

Конечно, Snapdragon 625 не самый мощный процессор, но все-таки мощнее Snapdragon 617, (возможно, из-за обновленного техпроцесса 10 нм). Не претендую на ученую степень инженера микропроцессоров, поправьте в комментариях.

В любом случае, Redmi Note 4 (на Snapdragon 625) - одно из самых устаревших устройств в списке аналитики, а в синтетических тестах замедление еще больше.

Таким образом, фактическая проверка оптимизации сайта, содержащего "современные" скрипты отслеживания (последнее изменение было в конце 2017 года), которые предлагает сам Google, проводятся на устройстве выпущенном в начале 2016 года. (голосом Михалкова) Иронично! 🙃

Данное сравнение, относительно поверхностно, важно учитывать и другие параметры, но в целом использование такого устройства кажется немного устаревшим.

То есть синтетические тесты проводятся на очень устаревшем устройстве. Разумеется, есть не такие благополучные страны/города/районы/люди, и кто-то еще использует кнопочные аппараты, но ориентироваться на эту аудиторию странно, нет?

Отложенная загрузка метрик

Хватит же погружения в технически детали! Мы здесь, чтобы разобраться что делать и "как дальше с этим жить". Как достичь 100/100 по Pagespeed Insights?

Предлагаемое решение - отложить выполнение скриптов метрик для достижения эффекта быстрой загрузки, реализуемое следующим простым кодом:

document.addEventListener('DOMContentLoaded', () => { setTimeout(function(){ /* * Тут код отслеживания всех метрик, */ }, 3500); // время указано в мс = 0,001 секунды, изменить по вкусу });

Код можно модифицировать по-разному:

  • менять время задержки;
  • менять событие, по которому будет выполнятся код.

Сути это не меняет, но можно найти множество подобных решений (некоторые даже продаются). Бесплатно, без смс и регистрации можно почитать тут:

Как это работает: при загрузке страницы будут загружены и выполнены все стили и скрипты, кроме отложенных. Отложенные скрипты будут загружены и/или выполнены через какое-то время (например, 0.5-1 секунду) или по действию пользователя (при прокрутке страницы, например).

Используя данный код, скорость загрузки страницы безусловно повысится в PageSpeed Insights, поскольку скрипты не будут выполнятся сразу, но:

  • будет ли наша статистика такой же точной?
  • как следствие - не вырастет ли показатель отказов?
  • как следствие - не будет ли понижен ресурс в поисковой выдаче?

Можно уверенно сказать - часть посещений потеряется. Да, это могут быть незначительные визиты, до 1 секунды, боты и т.д. Но эти показатели тоже важны для поисковых систем.

Также, фактический объем скриптов не меняется, то есть нельзя сказать, что будет ускорена загрузка, поскольку код выполнится, но позже. Для сравнения, отложенная загрузка изображений позволяет загружать их по факту востребованности.

Отложенным вызовом можно снизить пиковую единовременную нагрузку на процессор, распределив выполнение кода, не более того.

Из поиска по запросам "lazyload google analitycs" можно найти один очень старый (2011 год), но от этого не менее информативный, пост на Stackoverflow:

Другой информации, относительно изменений показателя отказов ввиду отложенной инициализации скриптов метрик, не удалось найти, кроме пары статей про ускорение сайта и статей на малазийском.

Вывод и опрос

Работать над скоростью загрузки сайта нужно, поскольку она влияет на пользовательский опыт, что несомненно улучшит и поведенческие показатели, и как следствие, положительно скажется на позициях.

Однако, данный показатель немного переоценен, поскольку существуют более весомые факторы ранжирования, и ожидать значительного эффекта не стóит.

Синтетические тесты предоставляют инструмент для ориентира, не более того. Но не стóит создавать сайты на шаблонах за 200$ с десятками ненужных скриптов и стилей, слепленных на коленке.

Решение об оптимизации сайта до "зеленой зоны" - не всегда верное и выполнимое в текущих реалиях, все зависит от:

  • типа сайта и контента;
  • целевой аудитории.

Техника отложенной загрузки скриптов метрик, как решение с целью достичь 100 баллов, вызывает сомнения, поскольку в теории можно получить негативный эффект, и как следствие, в позициях тоже.

А что скажете вы, коллеги?

Влияет ли отложенная загрузка метрик на показатель отказов?
Влияет, критично. Показатель отказов важнее.
Влияет, не критично. Прирост скорости эффективнее.
Не влияет.
Показать результаты
Переголосовать
Проголосовать
0
130 комментариев
Написать комментарий...
Алексей из LOADING.express

Абсолютно согласен, что устройство и троттлинг у лайтхауса немного жестковаты, поэтому мы используем немного другую эмуляцию, процессор в 2 раза быстрее, чем у пейджспид, сеть примерно на том же уровне.

Точность метрик Аналитикс и Яндекса снижается, но мы откладываем её не на 3500 мс, как в статье, а на 200-600 мс. Спросите в чем тогда смысл? Смысл в том, чтобы дать время выполниться без соединений и работы с DOM другим нужным для FCP и LCP элементам, и поставить выполнение внешних скриптов в конец очереди. Хотя бы сместить их на несколько позиций.

Чаты и попапы смело можно на 5-10 секунд откладывать, чтобы дать время выполниться родным скриптам сайта, которые нужны для отрсовки родного содержимого и взаимодействия с ним.

Откуда вообще эта идея в отложке? Это не для того, чтобы синтетика не ловила эти скрипты, а в том, что реальные пользователи выполняют родные скрипты сайта раньше чем сторонние. Однако этот подход практически бесполезен, если внутренние js-скрипты выполняются 10 секунд и на странице инициалиируется 10 слайдеров, при помощи плагина к библиотеке с кучей зависимостей.

Поэтому первоначально обязательно нужно оптимизировать СВОЙ КОД. Переработать, переосмыслить и то, что нельзя оптимизировать — тоже нужно откладывать по времени, или по действию пользователя.

Например, зачем грузить видео ютуба в айфрейм и целый плеер, если не каждый пользователь нажмет на play. Откладываем до клика на изображение видео. Всё.

Вообще, все соединения лучше вести через свой домен и не устанавливать внешних соединений, потому что это едва ли не самая ресурсоемкая операция. Можно потратить ресурсы на установку соединения, а потом гораздо быстрее выкачать картинку в 1 мегабайт.

Задача как раз сделать быстрее отрисовку первого экрана, снизить нагрузку на основной поток, растянуть нагрузку по времени, тем самым избежать лонг-тасков и блокировки потока более 50 миллисекунд.

Ответить
Развернуть ветку
Nikita Spivak
Автор

Спасибо за комментарий, наконец-то дождался от вас какой-то конкретики.

 Точность метрик Аналитикс и Яндекса снижается, но мы откладываем её не на 3500 мс, как в статье, а на 200-600 мс. Спросите в чем тогда смысл? Смысл в том, чтобы дать время выполниться без соединений и работы с DOM другим нужным для FCP и LCP элементам, и поставить выполнение внешних скриптов в конец очереди. Хотя бы сместить их на несколько позиций.

Точность, как уже определили до нескольких процентов не страшно, и конечно 3,5 секунды это много, это код для примера. Но нагрузка же все-равно остается? Конечно влияние стороннего кода уменьшится, но пункты:
- "Удалите неиспользуемый код JavaScript"
- "Минимизируйте работу в основном потоке"
- "Сократите время выполнения кода JavaScript"

по идее никуда не денутся.

Для видео с ютуба есть лайфхак (параметр srcdoc у тега iFrame) - посмотрите на этой странице, например: https://rubika.com.ua/blog/skolko-stoit-sozdanie-sajta-ceny-na-sajt-v-2020-godu#konstruktor-saytov-tilda-publishing

Но! Кстати для решения внешних соединений, почему бы не использовать link rel="dns-prefetch" или "preconnect" (подробнее в статье: https://habr.com/ru/post/445264/), безусловно, речь про аналитики и другие внешние скрипты, КОТОРЫЕ ОПРАВДАНЫ, а не картинка с чужого сайта)

Ответить
Развернуть ветку
Алексей из LOADING.express

Префетч не решит вопрос от слова совсем. Вообще. Он сделает оценку еще хуже.

"А любая попытка преконнекта или прелоада снизит оценку в желтую зону, так как соединение начнет блокировать поток раньше, чем необходимо."

Тут написано для вас специально:

"Вообще, все соединения лучше вести через свой домен и не устанавливать внешних соединений, потому что это едва ли не самая ресурсоемкая операция. Можно потратить ресурсы на установку соединения, а потом гораздо быстрее выкачать картинку в 1 мегабайт."

Вы плохо и невнимательно читали. Я негодую. Зачем мы тут распинаемся перед вами. Жуть.))

Ответить
Развернуть ветку
Nikita Spivak
Автор

Ваши слова идут в разрез документации, поэтому, что логично, они подвергаются сомнению. А ваше высокомерие необоснованно и неуместно.

до того, как сработает основной механизм отрисовки браузера. Это гарантирует, что предзагрузчик нужных ресурсов с меньшей вероятностью заблокирует отрисовку страницы, тем самым улучшая её производительность.

Источник: https://developer.mozilla.org/ru/docs/Web/HTML/Preloading_content

https://developer.mozilla.org/ru/docs/Web/Performance/dns-prefetch

Вот что пишут в документации, помимо статей на хабре.

Ответить
Развернуть ветку
Алексей из LOADING.express

Да-да Никита, вы непробиваемый. Мы тут уже все это поняли.))
Вот когда начнете практиковать, то всё поймете, а пока вы теоретик - всё тщетно.
Больше я вам ничего писать не собираюсь.)) Удачи. 🤞 

Ответить
Развернуть ветку
Nikita Spivak
Автор

Отличная попытка. В ответ на конкретные аргументы переходить на личности. Задача - разобраться - поэтому много аналитики.

Вы, уважаемый практик, сначала матчасть подтяните. Столько практиков развелось, складывать ГС уже некуда.

Вы только подтверждаете мои догадки относительно вашей некомпетентности в техническом плане.

P.S. Ни одной ссылки на ускоренный вами сайт вы так и не предоставили, кстати.

Ответить
Развернуть ветку
Алексей из LOADING.express

Никита, я не обязан вам давать наши ускоренные проекты.
И не собираюсь этого делать.)
Мы не подписывали эндиэй или похожих доков, но клиенты у нас крупные и за кадром они говорят, что не хотели бы, чтобы их конкуренты знали где они ускорили так сайт. Потому что реально найти тех, кто практикует и получает результат  —  практически невозможно. зато теоретиков много, да.))

Ответить
Развернуть ветку
Nikita Spivak
Автор

Красиво ушли от ответа в который раз. Никто вас не просит публиковать ссылки - можно было отправить в ЛС и сохранить лицо. А рассказать я тоже умею. Главное еще руками поводить многозначительно. Вы, случайно, не ученик Гандапаса?

Кстати, таких товарищей, нынче, еще больше чем теоретиков ;)

Не буду вдаваться в подробности, но ваш пафос выглядит смешно, особенно на фоне общедоступной информации)

Далее, я так понимаю, ничего нового, кроме очередных высокомерных высказываний не будет, так что можете восхвалять себя и дальше, но без моего участия.

Ответить
Развернуть ветку
Алексей из LOADING.express

О да, потому что как мы все здесь поняли - вы не умеете читать внимательно и вникать в ответы. 
Теория ваше всё. Ну и вот эти все тычки про пафос - вообще непонятное что-то. Пока-пока. 👋 

Ответить
Развернуть ветку
Nikita Spivak
Автор

Мы, они, все.
Ночь, улица, фонарь, аптека.
Конь, стул, двадцать два.

Да до свидания, до свидания.
Сколько можно прощаться уже? Какой вы нерешительный.
Всего доброго!

Ответить
Развернуть ветку
Алексей из LOADING.express

Да-да. Мне просто нравится с вами прощаться. Вы забавный.
Но какие наши годы. Мне тоже 24 было десять лет назад. И тоже мог писать такие тексты.))

P.S. Ответы на ВСЕ ваши вопросы заданные когда либо есть в том большом моем комментарии. То что вы не умеете читать внимательно это я уже заметил. Это вас и подводит. А писать одно и тоже для вас - сомнительное удовольствие.

Ответить
Развернуть ветку
Nikita Spivak
Автор

Ой, б***ь, началось 🤦‍♂️ "мне 24 было 10 лет назад", "а у меня длиннее", "а наша компания на рынке с 934 года".

Вот с одной стороны, мне, как более грамотному и деловому человеку, стоило проигнорировать ваши язвительные комментарии не по делу. Но это же так забавно наблюдать за вашими попытками выкрутиться.

Обратите внимание - вы единственный из "ВСЕХ", кто что-то там у вас понял, с кем возникла подобная перепалка.

Может вы конкурентов боитесь? Так это, опять таки, неуверенность в вас говорит и несостоятельность.

Вам точно 24 БЫЛО 10 лет назад? Может вы имели ввиду БУДЕТ через 10? Ваше поведение выдает возраст.

И откуда информация что мне 24? 🤣
Мимо.

P.S. ВСЕ мои вопросы, которые возникали по вашим ответам есть в моих тех комментариях. То что вы не умеете отвечать на вопросы это я уже заметил. Это вас и выдает. А поддерживать ваш пустой треп - сомнительное удовольствие. 🤣

Ответить
Развернуть ветку
Алексей из LOADING.express

Да вы не волнуйтесь так, Никита. Всё пройдет.

Ответить
Развернуть ветку
Nikita Spivak
Автор

Пройдет и это, Алексей)

Ответить
Развернуть ветку
127 комментариев
Раскрывать всегда