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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако, существуют популярные сервисы замера скорости загрузки сайта. Насколько в таком случае точна их оценка? Стоит ли гнаться за 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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