Ускорение сайта или вред для SEO: отложенная загрузка метрик и ее влияние на показатель отказов
Для достижения вожделенной "зеленой зоны" (оценки 100/100 по тестам Pagespeed Insights), остается нерешенным вопрос долгой загрузки и блокировки страницы сторонними скриптами метрик (Google Analytics, Яндекс.Метрика, Facebook Pixel и другие).
Абсолютно согласен, что устройство и троттлинг у лайтхауса немного жестковаты, поэтому мы используем немного другую эмуляцию, процессор в 2 раза быстрее, чем у пейджспид, сеть примерно на том же уровне.
Точность метрик Аналитикс и Яндекса снижается, но мы откладываем её не на 3500 мс, как в статье, а на 200-600 мс. Спросите в чем тогда смысл? Смысл в том, чтобы дать время выполниться без соединений и работы с DOM другим нужным для FCP и LCP элементам, и поставить выполнение внешних скриптов в конец очереди. Хотя бы сместить их на несколько позиций.
Чаты и попапы смело можно на 5-10 секунд откладывать, чтобы дать время выполниться родным скриптам сайта, которые нужны для отрсовки родного содержимого и взаимодействия с ним.
Откуда вообще эта идея в отложке? Это не для того, чтобы синтетика не ловила эти скрипты, а в том, что реальные пользователи выполняют родные скрипты сайта раньше чем сторонние. Однако этот подход практически бесполезен, если внутренние js-скрипты выполняются 10 секунд и на странице инициалиируется 10 слайдеров, при помощи плагина к библиотеке с кучей зависимостей.
Поэтому первоначально обязательно нужно оптимизировать СВОЙ КОД. Переработать, переосмыслить и то, что нельзя оптимизировать — тоже нужно откладывать по времени, или по действию пользователя.
Например, зачем грузить видео ютуба в айфрейм и целый плеер, если не каждый пользователь нажмет на play. Откладываем до клика на изображение видео. Всё.
Вообще, все соединения лучше вести через свой домен и не устанавливать внешних соединений, потому что это едва ли не самая ресурсоемкая операция. Можно потратить ресурсы на установку соединения, а потом гораздо быстрее выкачать картинку в 1 мегабайт.
Задача как раз сделать быстрее отрисовку первого экрана, снизить нагрузку на основной поток, растянуть нагрузку по времени, тем самым избежать лонг-тасков и блокировки потока более 50 миллисекунд.
По внутренней оптимизации.
Иногда инициализация одного внутреннего слайдера может занимать 2-3 секунды, так как приходится ждать ответа от бакенда, или загружать 1-2 библиотеки и существенно изменить DOM, вызвав тем самым перерисовку несколько раз подряд.
Простое изменение порядка работы с DOM может существенно снизить время выполнения задачи.
Пример:
вместо того, чтобы вставлять в страницу 10 элементов, вставляем один, который уже содержит эти 10 элементов, что уже вызовет одну перерисовку, вместо 10. Лучше конечно вообще не менять DOM из js без ведома пользователя.
В крайнем случае добавлять, но не менять. Это позволит еще и контролировать CLS, так как все элементы будут стилизованы без js.
Изменения css-свойств также может вызывать перерисовку всего содержимого. Нужно быть аккуратнее и не менять свойства своим js скриптом после загрузки страницы, оставив это на момент взаимодействия с элементом.
Я находил как то плагин для WP, который как раз откладывает выполнения скриптов (как раз чаты, попапы и тд) до взаимодействия с пользователем. Название - Flying Scripts by WP Speed Matters
видео по нему на Ютюб
По поводу снижения баллов за Яндекс.Метрику.
20-30 баллов Метрика может снять только в случае, если поток занят перерисовкой или выполнением скриптов уже после загрузки страницы. До крутизны Analytics ей достаточно далеко, и блокирует поток она на 300-600 миллисекунд, при троттлинге 4х на макбук PRO.
Но ребята занимаются и стараются оптимизировать скрипт Метрики. Если на странице вообще нет JS, то вставка метрики и аналитики снизит показатели PageSpeed незначительно, оставив их в зеленой зоне.
Пример:
https://3-секунды.рф — тут вообще без отложки метрики. Делаем 10 перезамеров PageSpeed и получаем 95-99 баллов.
В нашем случае отложка внешки не нужна. Так как загрузка внешнего скрипта начинается гораздо позже, чем отрисовка всей страницы. А любая попытка преконнекта или прелоада снизит оценку в желтую зону, так как соединение начнет блокировать поток раньше, чем необходимо.
Спасибо за комментарий, наконец-то дождался от вас какой-то конкретики.
Точность метрик Аналитикс и Яндекса снижается, но мы откладываем её не на 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/), безусловно, речь про аналитики и другие внешние скрипты, КОТОРЫЕ ОПРАВДАНЫ, а не картинка с чужого сайта)