сторонний код заблокировал основной поток yandex metrika
Код Метрики стал быстрее
Долгожданное обновление: мы ускорили код Метрики, чтобы он как можно меньше влиял на работу сайта. Мы внимательно следили за вашими пожеланиями — поэтому доработали код таким образом, чтобы он стал работать быстрее даже на самых «тяжёлых» и сложных сайтах. И даже если на счётчике подключены дополнительные возможности — Вебвизор, электронная коммерция или контентная аналитика. При этом переустанавливать счётчик на сайт не понадобится.
Коротко — самое главное:
Как именно мы ускорили код
Для этого потребовались два больших проекта:
Счётчик не просто загружается быстрее: теперь он способен фиксировать больше коротких визитов на сайт, которые раньше просто не успевали записаться в отчёты — так как к концу супер-короткого визита счётчик ещё не был загружен. В результате статистика станет ещё более полной — вы сможете лучше понимать, сколько визитов оказываются совсем непродолжительными, и исследовать, почему это происходит. Например, дело может быть в неудачной ссылке в рекламном объявлении — и это важно вовремя исправить.
Такие масштабные изменения всегда требуют длительной и тщательной отладки. Недостаточно просто переписать код с нуля — важно проверить, что он совместим со всеми браузерами и со всеми способами вёрстки, и со всеми их комбинациями. Например, если посетитель заходит с какой-нибудь устаревшей модели мобильного, на Linux, из браузера Puffin — ведь счётчик должен корректно отрабатывать в самых разных ситуациях. Поэтому на тестирование более быстрого кода потребовалось значительное время.
Мы благодарим всех участников закрытого бета-тестирования, которые помогали нам проверять работу более быстрого кода «в боевых условиях». Ваши отзывы и подробные комментарии помогли нам сделать быстрый код доступным для всех пользователей Метрики 🙌
Быстрый код подключается автоматически только при условии, что на сайте у вас установлена актуальная версия счётчика.
Как проверить версию счётчика: если в коде Метрики у вас на сайте есть строчка tag.js, это актуальный код. А если в нём встречается watch.js — значит, у вас устаревшая версия. Как посмотреть код счётчика на сайте, описано в Справке.
Если у вас — устаревшая версия кода, рекомендуем заменить её на актуальную. В устаревшей версии watch.js не поддерживаются новые возможности Метрики, в том числе и более быстрая загрузка серверной части кода. Актуальная версия кода Метрики есть в настройках счётчика — просто скопируйте этот код и установите его на все страницы сайта вместо старого кода.
Чтобы ещё больше ускорить код Метрики, мы готовим и другие обновления. Оставайтесь на связи — подписывайтесь на наши новости, чтобы ничего не пропустить!
Yandex Metrika: Сторонний код заблокировал основной поток
Для веб-мастеров не секрет, что Google’s PageSpeed Insights снимает баллы за код счётчика Яндекс.Метрики. Почему? Банально из за того, что файл tag.js грузится со стороннего ресурса достаточно медленно. У меня показывает 600+ микросекунд.
Убрав счетчик Yandex Metrika, я получаю примерно на 4 балла больше. Это, на минутку, ускорение загрузки на 4%! Но Яндекс.Метрика необходима, как удобный инструмент веб-аналитики, а потому выпиливать её не вариант.
Что остаётся?
Способ №1
Остаётся скачать файл tag.js к себе на сервер, скажем, в папку metrika и использовать его оттуда.
Вот так выгладили баллы в Google’s PageSpeed Insights до этой правки.
Очевидно, эффект есть. Но есть и минус. Файл tag.js может меняться, а значит время от времени его нужно скачивать. Руками… Фи!…
Руками качать не будем. Пусть этим занимается Крон. Не тот, который титан из греческой миффологии, а который CronTab на хостинге. Скажем, раз в час.
А теперь пошаговая инструкция на примере хостинга Бегет.
Итак, если Google’s PageSpeed Insights ругается, что сторонний код заблокировал основной поток и винит в этом счетчик Yandex Metrika, мы делаем следующее:
Шаг 1: Создаём в корне сайта папку metrika.
Для этого заходим в корень сайта с помощью FTP-клиента и… Если вы не знаете что такое корень сайта или FTP-клиент, то у вас есть три выхода:
К слову, вместо FTP, можно использовать SSH-клиент или даже Файловый менеджер, который есть в панели управления хостингом (у Бегета он точно есть).
Шаг 2: Скачиваем tag.js и копируем его в папку metrika, созданную в предыдущем шаге.
Тут тоже всё просто. Ссылка на файл есть в коде счётчика Яндекс Метрики. Вот она https://mc.yandex.ru/metrika/tag.js
Просто переходим по ней, а когда файл откроется в браузере, сохраним его комбинацией клавиш Ctrl-S, а затем просто скопируем в папку.
Шаг 3: Вносим правку в код счётчика Яндекс Метрики.
Находим ссылку на tag.js и делаем так, чтобы она ссылалась на папку в корне вашего сайта.
Было (window, document, «script», «https://mc.yandex.ru/metrika/tag.js», «ym»);
Стало (window, document, «script», «/metrika/tag.js», «ym»);
Сохраняем и идём дальше.
Шаг 4: Узнаём полный путь к корню сайта на сервере.
В вебе корень сайта начинается с /. В файловой системе сервера путь до корня может выглядеть примерно так /r/username/sitename/public_html/.
Т.е. корень сайта там лежит в папке, а та в папке, и она, в свою очередь тоже в какой-нибудь папке. Но нам надо знать полный путь, чтобы указать его в кроне.
Убираю index.php, остаётся /home/w/redalert/sitename.ru/public_html/. Это и есть нужный мне путь.
Теперь, когда путь известен, не забываем убрать из подвала сайта!
Шаг 5. Настраиваю задание для крона.
Не знаю как у вас, а на Бегете достаточно зайти в панель управления хостингом и нажать кнопку CronTab.
На открывшейся странице я выбираю произвольную команду, делаю для неё понятное описание, и выбираю её выполнение каждый час.
Сама команда выглядит вот так. Если у вас другой хостинг (не бегет) то найдите способ внедрить её в задачу для крона тем способом, который поддерживается хостингом.
/home/w/redalert/sitename.ru/public_html/ — это тот путь к корню сайта, который я получил в шаге 4.
/metrika/ — это папка где мы будем хранить tag.js и откуда он будет грузиться на сайте.
Теперь раз в час крон будет обновлять tag.js без нашего участия.
Собственно, сохраняю и иду измерять скорость в Google’s PageSpeed Insights.
Ура! Она на 4% выше, как и ожидалось.
Способ №2
Ну а теперь, для самых стойких, способ номер 2. Подойдёт тем кому лень заморачиваться с кроном.
1. Заходим на сервер в корневую папку сайта.
2. Создаём там папку metrika.
3. Кладём в папку metrika файл tag.php
4. В коде счётчика меняем https://mc.yandex.ru/metrika/tag.js на /metrika/tag.php
5. В файл tag.php прописываем вот этот код.
или скачиваем архив с готовым файлом по ссылке /up/metrika.zip и распаковываем в корень сайта (там уже есть нужная папка и даже tag.js в ней имеется).
6. Тестируем результат.
Как это работает?
При обращении к tag.php, если tag.js отсутствует в папке metrika или с момента его последнего обновления прошло больше часа, tag.js будет скачан с серверов яндекса и его содержимое подставится в tag.php.
Если tag.js свежий, то его содержимое будет подставлено в tag.php сразу.
Просто, очень просто, примитивно даже. Создали папку, кинули туда файл, заменили строчку в счётчике и всё.
А теперь полевые испытания. Есть у меня сайт wowm.ru. Он не оптимизирован, а значит идеально подходит для эксперимента.
Замеряю скорость до изменений.
Ставлю новый код счётчика (оказывается там был старый), меняю в нём путь к tag.js на свой. Ну и далее по инструкции.
И вот вам результат.
Миленько так. Т.е. стало медленнее.
Может дело в старом коде счётчика?
Ок. Тестируем скорость на новом счётчике, где tag.js берется с серверов яндекса. А затем тестируем скорость с tag.php
Вывод
1. Сообщение «Сторонний код заблокировал основной поток» исчезло.
2. Прироста в скорости, при использовании способа №2, не наблюдается, а даже наоборот.
3. Старый счётчик яндекс.метрики был быстрее.
А с вами был Доктор Лексиум.
Спасибо за внимание.
После проделанных манипуляций общая оценка Page Speed Insight одной страницы
Было 84
Стало 58
Нет, некоторые показатели улучшились, уменьшение влияния стороннего кода удалось,
но в общем целом незачет получился — вернул как было
У каждого сервера и сайта своя структура. Кому-то этот вариант помогает, как мне например. Кому-то нет.
Я использовал этот способ на нескольких сайтах и там был прирост скорости. Небольшой, конечно, но всё-же.
Все так запутано, нет ли какого-нибудь способа попроще?
Как не быть? Есть. Я добавлю его к этому посту.
а где в коде счетчика найти эту конструкцию?
4. В коде счётчика меняем https://mc.yandex.ru/metrika/tag.js на /metrika/tag.php
В коде счётчика)) Она либо там есть, либо нет. Если нет, значит у вас старый счётчик.
День добрый.
За инфу спасибо.
Но есть вопрос.
Почему плагин? Он позволяет настройками исключить посещение сайта пользователями-админами.
Ваш способ это не позволяет. Или есть возможность организовать аналогичный функционал?
Насколько мне известно, в настройках самой метрики можно указать IP адреса которые следует игнорировать. Обычно SEO-специалисты именно так и делают.
Что касается плагина. Я не лазил в его код, но уверен, что он всего-лишь определяет админ ли пользователь. Если админ, код счётчика на страницах сайта не выводится вовсе. Без плагина это можно сделать двумя строчками кода. При том, вторая строка это фигурная скобка.
Однако, такой способ хуже поскольку до авторизации администратора, код метрики будет присутствовать на страницах, а значит все шатания неавторизованного админина зафиксируются счётчиком метрики.
Когда же Гугл перестанет учитывать метрику при оценке скорости загрузки? Свои коды наверняка не считает.
Пока такая ситуация сохраняется, Гуглу нет никакого смысла не учитывать скрипты Яндекса.
Спасибо за статью. Очень полезная информация.
На здоровье. Надеюсь пригодится.
Тут как раз очень редкий случай, когда лучше поставить плагин. Мой сайт https://tv-ch.ru/ показывал в PageSpeed Insights
99 балов, с установкой кода «Яндекс метрика» упал на 10. Но, спасибо автору, установил плагин «Яндекс.Метрика by Alexander Semikashev». Сейчас там можно и поставить устаревший код яндекс, который очень сильно понижает скорость сайта, и просто вставить код счетчика. Что на много проще и не снижает скорость сайта!
Еще раз спасибо автору, за то что указал на данный плагин. Раньше его не ставил по причинам «мало балов и установок». Но плагин оказался отличным!
Скрипт Яндекс.Метрики (tag.js) негативно влияет на PageSpeed: что делать
Итак, вы решили улучшить ваш показатель PageSpeed. Но в процессе проверки вы заметили, что скрипты Яндекс.Метрики серьезно ухудшают положение дел (что особенно заметно при проверке сайта на мобильных устройствах). Давайте посмотрим на примере с нашим сайтом oddstyle.ru.
В поддержке Яндекса признавали эту проблему (но дальше тестирования ничего не сдвинулось до сих пор):
upd 28/07/2021: Счетчик был обновлен (спасибо за информацию Mihdan), но результаты все равно далеки от идеала. См. комментарии.
У нас стоит следующий код для подключения Яндекс.Метрики:
При проверке мы получаем следующие показатели.
Естественно, показатели эти так себе. Смотрим ниже и видим следующее:
Как видно отсюда, Метрика сильно блокирует основной поток загрузки.
Естественно, у нас есть вариант вообще от нее отказаться. Если Метрику вообще отключить, то показатель будет следующим:
Но как быть, если Метрика все же нужна, хочется использовать некоторые ее особенности?
Одно из решений – заключить вызов функции в setTimeout, чтобы загрузка скрипта была отложена, пока основной контент не будет загружен.
Вот как будет выглядеть код скрипта (не забудьте подставить вместо xxxxxxxx номер своего счетчика):
Вместо 5000 нужно будет подобрать значение, которое позволит вам поддерживать хороший показатель PageSpeed (можно задавать больше, чем 5000).
Вставляем данный код в header.php и имеем следующее:
Чуть похуже, чем без скрипта Метрики вообще, но все равно отлично.
Собственно, setTimeout помог добиться хороших результатов для мобильных, при этом не отказываясь вообще от Метрики.
Для десктопов мы имеем следующее с данным кодом:
Если вы знаете другие методы улучшения PageSpeed для скриптов Метрики, делитесь ими в комментариях.
Yandex Metrika: Сторонний код заблокировал основной поток
Иногда бывает, что Вебвизор выдает ошибку и не показывает посещения страницы. В качестве возможных причин ошибки высвечивается:
«Невозможно воспроизвести посещение на этой странице. Возможные причины:
Проверьте, включен ли Вебвизор в настройках счетчика. Иногда Вебвизор выключается — если не смотреть записи в течение последнего полугода. Тогда нужно просто включить опцию заново.
Блокировщик рекламы заблокировал и вебвизор
Если счетчик установлен корректно и дело не в нем, возможно, виноват блокировщик рекламы. Попробуйте посмотреть с браузера, где нет блокировщиков.
Использование другой версии кода при настройке событий в яндекс. метрике
Отслеживание JavaScript-событий, при которых не меняется URL сайта, требует настройки. Если следовать руководствам из интернета, а не советам из Справки Яндекса, есть риск скопировать из статьи код, который не будет подходить вашей версии Метрики.
Есть две версии: старая и новая, которая доступна в настройках с декабря 2021 года. Тогда Яндекс обновил код счетчика и набор методов.
Если вы используете новую версию, для настройки понадобятся новые методы, там есть примеры для установки на кнопку, форму, ссылку и другие.
Если используете старую, методы будут другие, они перечислены на странице Справочника методов предыдущей версии.
Яков Осипенков в эксперименте проверил метод Reach goal, который используют для настройки целей. Он выяснил, что методы новой версии не будут работать с устаревшим счетчиком, но методы старой работают с обеими версиями.
Если вы пользуетесь руководствами из интернета, вероятнее всего, в актуальных материалах используют методы для новой версии. Так что если у вас старая, они не сработают, проще обновить Метрику до новой и не думать об этом.
Как проверить установку счетчика
В Справке Яндекса есть алгоритм:
Как установить счетчик яндекс. метрики правильно
Процесс регистрации в Яндекс. Метрике и установки счетчика описан в обновленном Руководстве со скриншотами.
Для добавления кода на сайт, есть несколько способов. На странице ресурсов собраны дополнения для разных CMS, которые помогут установить счетчик на страницы сайта.
Если установка прошла правильно, довольно скоро он начнет собирать данные.
На странице Метрики со всеми счетчиками у каждого отмечен его статус. Для определения статуса счетчика робот запрашивает главную страницу сайта. Если на главной счетчика нет, в статусе будет «Не найден», но это никак не повлияет на корректность сбора данных на других страницах, если на них он установлен правильно.
Красный обычно появляется у недоступных и зараженных сайтов, но если таких проблем нет, то причина может быть в другом:
Короткий тайм-аут визита
Тайм-аут визита — это максимальное время для бездействия пользователя на сайте. Обычно его оставляют стандартным, но некоторые меняют под особенности поведения своей аудитории. По истечению установленного веб-мастером времени бездействия визит пользователя автоматически завершается и расценивается как новый, источником считается внутренний переход.
Настройка тайм-аута визита
В разделе «Отчеты» — «Источники» — «Источники, сводка» — «Внутренние переходы» видно, сколько переходов относятся к внутренним.
Внутренние переходы в Метрике
Если вы выяснили, что слишком много пользователей не укладываются в установленный тайм-аут и внутренних переходов слишком много — к примеру, больше половины — то тайм-аут лучше увеличить. Иначе долгие сессии пользователей будут делиться на два визита, а по факту это не так. Также проверьте, на всех ли страницах стоит счетчик.
Не работает вебвизор яндекса. как включить?
Вебвизор включен по умолчанию, если вы подключили счётчик в «Настройках сайта».
Доступ к ним может быть закрыт:
Добавьте эти адреса в список доверенных и проверьте, осталась ли проблема.
Если проблема осталась, то попробуйте зайти с «чистого» браузера, где нет плагинов (особенно блокировщиков рекламы и антивирусных аддонов).
Если проблема и после этого сохраняется, пожалуйста, обратитесь в поддержку Яндекса, так как с нашей стороны все установлено корректно.
Некорректная установка счетчика я. метрики
Причины того, что в Метрике появляются не все данные, могут быть связаны с особенностями работы счетчика:
Это просто нужно иметь в виду при работе с данными. Но если вы установили счетчик, но он не фиксирует данные с сайта, возможно, установка прошла неправильно.
От чего защищает x-frame-options?
От атак типа «кликджекинг» (англ. Clickjacking).
На русский переводится дословно, как “воровство кликов”. Суть заключается в том, что ваш сайт запускают во фрейме на стороннем ресурсе, затем поверх кнопок и других элементов накладывают ссылки на запуск вредоносных программ, либо иных мошеннических действий.
Сервер блокирует вебвизор
Проблема может заключаться в защите от показов в iframe.
Как это понять:
Решить эту проблему можно, если убрать запрет в конфигурации сервера, файле htaccess или настройках CMS. Придется удалить код защиты, это увеличивает уязвимость сайта. Веб-мастерам приходится выбирать, что приоритетнее: безопасность или работа Вебвизора.
Фаервол блокирует вебвизор
Антивирус, фаервол компьютера или корпоративной сети может блокировать доступ к доменам:
Чтобы исправить это, нужно добавить домены в доверенные.
Часовой пояс по офису, а не по клиентам
Обычно веб-мастеры ставят в настройках тот часовой пояс, в котором находится компания, в которой работают.
Часовой пояс в настройках
В разделе «Отчеты» — «Аудитория» есть статистика посещений сайта по времени суток. Время суток определяется по указанному в настройках часовому поясу. Если он выбран некорректно, данные будут неверны.
Причем выбирать часовой пояс стоит по целевой аудитории, а не местоположению самой компании, ведь люди заходят на сайт по своему времени, а время в отчетах стоит по настройке Метрики.
Геоположение большинства клиентов можно определить по сводке «География» в разделе «Аудитория».
По ней видно, из каких стран идет трафик. Найдите, откуда большая часть аудитории, и выберите ее часовой пояс. Если получилось, что основной аудиторией вашего сайта оказались жители региона, с которым вы не работаете, стоит пересмотреть продвижение ресурса.
Для веб-мастеров не секрет, что Google’s PageSpeed Insights снимает баллы за код счётчика Яндекс. Метрики. Почему? Банально из за того, что файл tag. js грузится со стороннего ресурса достаточно медленно. У меня показывает 600+ микросекунд.
Убрав счетчик Yandex Metrika, я получаю примерно на 4 балла больше. Это, на минутку, ускорение загрузки на 4%! Но Яндекс. Метрика необходима, как удобный инструмент веб-аналитики, а потому выпиливать её не вариант.
Что остаётся?
Способ №1
Остаётся скачать файл tag. js к себе на сервер, скажем, в папку metrika и использовать его оттуда.
Вот так выгладили баллы в Google’s PageSpeed Insights до этой правки.
Очевидно, эффект есть. Но есть и минус. Файл tag. js может меняться, а значит время от времени его нужно скачивать. Руками… Фи!…
Руками качать не будем. Пусть этим занимается Крон. Не тот, который титан из греческой миффологии, а который CronTab на хостинге. Скажем, раз в час.
А теперь пошаговая инструкция на примере хостинга Бегет.
Итак, если Google’s PageSpeed Insights ругается, что сторонний код заблокировал основной поток и винит в этом счетчик Yandex Metrika, мы делаем следующее:
Шаг 1: Создаём в корне сайта папку metrika.
Для этого заходим в корень сайта с помощью FTP-клиента и… Если вы не знаете что такое корень сайта или FTP-клиент, то у вас есть три выхода:
К слову, вместо FTP, можно использовать SSH-клиент или даже Файловый менеджер, который есть в панели управления хостингом (у Бегета он точно есть).
Шаг 2: Скачиваем tag. js и копируем его в папку metrika, созданную в предыдущем шаге.
Тут тоже всё просто. Ссылка на файл есть в коде счётчика Яндекс Метрики. Вот она https://mc. yandex. ru/metrika/tag. js
Просто переходим по ней, а когда файл откроется в браузере, сохраним его комбинацией клавиш Ctrl-S, а затем просто скопируем в папку.
Шаг 3: Вносим правку в код счётчика Яндекс Метрики.
Находим ссылку на tag. js и делаем так, чтобы она ссылалась на папку в корне вашего сайта.
Было (window, document, «script», «https://mc. yandex. ru/metrika/tag. js», «ym»);
Сохраняем и идём дальше.
Шаг 4: Узнаём полный путь к корню сайта на сервере.
В вебе корень сайта начинается с /. В файловой системе сервера путь до корня может выглядеть примерно так /r/username/sitename/public_html/.
Т. е. корень сайта там лежит в папке, а та в папке, и она, в свою очередь тоже в какой-нибудь папке. Но нам надо знать полный путь, чтобы указать его в кроне.
Убираю index. php, остаётся /home/w/redalert/sitename. ru/public_html/. Это и есть нужный мне путь.
Теперь, когда путь известен, не забываем убрать из подвала сайта!
Шаг 5. Настраиваю задание для крона.
Не знаю как у вас, а на Бегете достаточно зайти в панель управления хостингом и нажать кнопку CronTab.
На открывшейся странице я выбираю произвольную команду, делаю для неё понятное описание, и выбираю её выполнение каждый час.
Сама команда выглядит вот так. Если у вас другой хостинг (не бегет) то найдите способ внедрить её в задачу для крона тем способом, который поддерживается хостингом.
/home/w/redalert/sitename. ru/public_html/ — это тот путь к корню сайта, который я получил в шаге 4.
/metrika/ — это папка где мы будем хранить tag. js и откуда он будет грузиться на сайте.
Теперь раз в час крон будет обновлять tag. js без нашего участия.
Собственно, сохраняю и иду измерять скорость в Google’s PageSpeed Insights.
Ура! Она на 4% выше, как и ожидалось.
Способ №2
Ну а теперь, для самых стойких, способ номер 2. Подойдёт тем кому лень заморачиваться с кроном.
1. Заходим на сервер в корневую папку сайта.
2. Создаём там папку metrika.
3. Кладём в папку metrika файл tag. php
4. В коде счётчика меняем https://mc. yandex. ru/metrika/tag. js на /metrika/tag. php
5. В файл tag. php прописываем вот этот код.
или скачиваем архив с готовым файлом по ссылке /up/metrika. zip и распаковываем в корень сайта (там уже есть нужная папка и даже tag. js в ней имеется).
6. Тестируем результат.
Как это работает?
При обращении к tag. php, если tag. js отсутствует в папке metrika или с момента его последнего обновления прошло больше часа, tag. js будет скачан с серверов яндекса и его содержимое подставится в tag. php.
Если tag. js свежий, то его содержимое будет подставлено в tag. php сразу.
Просто, очень просто, примитивно даже. Создали папку, кинули туда файл, заменили строчку в счётчике и всё.
А теперь полевые испытания. Есть у меня сайт wowm. ru. Он не оптимизирован, а значит идеально подходит для эксперимента.
Замеряю скорость до изменений.
Ставлю новый код счётчика (оказывается там был старый), меняю в нём путь к tag. js на свой. Ну и далее по инструкции.
И вот вам результат.
Миленько так. Т. е. стало медленнее.
Может дело в старом коде счётчика?
Ок. Тестируем скорость на новом счётчике, где tag. js берется с серверов яндекса. А затем тестируем скорость с tag. php
Вывод
1. Сообщение «Сторонний код заблокировал основной поток» исчезло.
2. Прироста в скорости, при использовании способа №2, не наблюдается, а даже наоборот.
3. Старый счётчик яндекс. метрики был быстрее.
А с вами был Доктор Лексиум.
Спасибо за внимание.
После проделанных манипуляций общая оценка Page Speed Insight одной страницы
Было 84
Стало 58
Нет, некоторые показатели улучшились, уменьшение влияния стороннего кода удалось,
но в общем целом незачет получился — вернул как было
У каждого сервера и сайта своя структура. Кому-то этот вариант помогает, как мне например. Кому-то нет.
Я использовал этот способ на нескольких сайтах и там был прирост скорости. Небольшой, конечно, но всё-же.
Все так запутано, нет ли какого-нибудь способа попроще?
Как не быть? Есть. Я добавлю его к этому посту.
а где в коде счетчика найти эту конструкцию?
4. В коде счётчика меняем https://mc. yandex. ru/metrika/tag. js на /metrika/tag. php
В коде счётчика)) Она либо там есть, либо нет. Если нет, значит у вас старый счётчик.
День добрый.
За инфу спасибо.
Но есть вопрос.
Почему плагин? Он позволяет настройками исключить посещение сайта пользователями-админами.
Ваш способ это не позволяет. Или есть возможность организовать аналогичный функционал?
Насколько мне известно, в настройках самой метрики можно указать IP адреса которые следует игнорировать. Обычно SEO-специалисты именно так и делают.
Что касается плагина. Я не лазил в его код, но уверен, что он всего-лишь определяет админ ли пользователь. Если админ, код счётчика на страницах сайта не выводится вовсе. Без плагина это можно сделать двумя строчками кода. При том, вторая строка это фигурная скобка.
Однако, такой способ хуже поскольку до авторизации администратора, код метрики будет присутствовать на страницах, а значит все шатания неавторизованного админина зафиксируются счётчиком метрики.
Когда же Гугл перестанет учитывать метрику при оценке скорости загрузки? Свои коды наверняка не считает.
Пока такая ситуация сохраняется, Гуглу нет никакого смысла не учитывать скрипты Яндекса.
Спасибо за статью. Очень полезная информация.
На здоровье. Надеюсь пригодится.
Тут как раз очень редкий случай, когда лучше поставить плагин. Мой сайт https://tv-ch. ru/ показывал в PageSpeed Insights
99 балов, с установкой кода «Яндекс метрика» упал на 10. Но, спасибо автору, установил плагин «Яндекс. Метрика by Alexander Semikashev». Сейчас там можно и поставить устаревший код яндекс, который очень сильно понижает скорость сайта, и просто вставить код счетчика. Что на много проще и не снижает скорость сайта!
Еще раз спасибо автору, за то что указал на данный плагин. Раньше его не ставил по причинам «мало балов и установок». Но плагин оказался отличным!
Популярные ошибки настройки Яндекс. Метрики
Отчеты Яндекс. Метрики дают массу информации для принятия решений о развитии сайта и корректировки стратегии. Если ориентироваться на неверные данные статистики, можно навредить сайту, поэтому важно настроить Метрику правильно.
В этом материале разберем частые ошибки в настройке Яндекс. Метрики. Если у вас мало опыта настройки или вы видите неестественные данные, советуем провести проверку — вдруг найдете описанные в статье ошибки
Подробное руководство по регистрации и начале работы с Метрикой — «Яндекс. Метрика от А до Я».
Разберем ошибки, которые чаще встречаются при работе с Метрикой.
Некорректная установка счетчика Я. Метрики
Причины того, что в Метрике появляются не все данные, могут быть связаны с особенностями работы счетчика:
Это просто нужно иметь в виду при работе с данными. Но если вы установили счетчик, но он не фиксирует данные с сайта, возможно, установка прошла неправильно.
Как проверить установку счетчика
В Справке Яндекса есть алгоритм:
Если все установлено правильно, в консоли отобразится номер счетчика и данные, которые отправляет код.
Счетчик Метрики установлен
Если в Params вместо данных написано undefined, значит счетчик работает корректно, но параметры визитов не передает.
Счетчик не передает визиты
Если в консоли есть данные, но отчеты не отображаются, зайдите в настройки Метрики во вкладку Фильтры, возможно, фильтры стоят слишком жесткие.
Если информации вообще нет, что-то не так со счетчиком:
Как установить счетчик Яндекс. Метрики правильно
Процесс регистрации в Яндекс. Метрике и установки счетчика описан в обновленном Руководстве со скриншотами.
Для добавления кода на сайт, есть несколько способов. На странице ресурсов собраны дополнения для разных CMS, которые помогут установить счетчик на страницы сайта.
Если установка прошла правильно, довольно скоро он начнет собирать данные.
На странице Метрики со всеми счетчиками у каждого отмечен его статус. Для определения статуса счетчика робот запрашивает главную страницу сайта. Если на главной счетчика нет, в статусе будет «Не найден», но это никак не повлияет на корректность сбора данных на других страницах, если на них он установлен правильно.
Красный обычно появляется у недоступных и зараженных сайтов, но если таких проблем нет, то причина может быть в другом:
Использование другой версии кода при настройке событий в Яндекс. Метрике
Отслеживание JavaScript-событий, при которых не меняется URL сайта, требует настройки. Если следовать руководствам из интернета, а не советам из Справки Яндекса, есть риск скопировать из статьи код, который не будет подходить вашей версии Метрики.
Есть две версии: старая и новая, которая доступна в настройках с декабря 2018 года. Тогда Яндекс обновил код счетчика и набор методов.
Если вы используете новую версию, для настройки понадобятся новые методы, там есть примеры для установки на кнопку, форму, ссылку и другие.
Если используете старую, методы будут другие, они перечислены на странице Справочника методов предыдущей версии.
Яков Осипенков в эксперименте проверил метод Reach goal, который используют для настройки целей. Он выяснил, что методы новой версии не будут работать с устаревшим счетчиком, но методы старой работают с обеими версиями.
Если вы пользуетесь руководствами из интернета, вероятнее всего, в актуальных материалах используют методы для новой версии. Так что если у вас старая, они не сработают, проще обновить Метрику до новой и не думать об этом.
Короткий тайм-аут визита
Тайм-аут визита — это максимальное время для бездействия пользователя на сайте. Обычно его оставляют стандартным, но некоторые меняют под особенности поведения своей аудитории. По истечению установленного веб-мастером времени бездействия визит пользователя автоматически завершается и расценивается как новый, источником считается внутренний переход.
Настройка тайм-аута визита
В разделе «Отчеты» — «Источники» — «Источники, сводка» — «Внутренние переходы» видно, сколько переходов относятся к внутренним.
Внутренние переходы в Метрике
Если вы выяснили, что слишком много пользователей не укладываются в установленный тайм-аут и внутренних переходов слишком много — к примеру, больше половины — то тайм-аут лучше увеличить. Иначе долгие сессии пользователей будут делиться на два визита, а по факту это не так. Также проверьте, на всех ли страницах стоит счетчик.
Часовой пояс по офису, а не по клиентам
Обычно веб-мастеры ставят в настройках тот часовой пояс, в котором находится компания, в которой работают.
Часовой пояс в настройках
В разделе «Отчеты» — «Аудитория» есть статистика посещений сайта по времени суток. Время суток определяется по указанному в настройках часовому поясу. Если он выбран некорректно, данные будут неверны.
Причем выбирать часовой пояс стоит по целевой аудитории, а не местоположению самой компании, ведь люди заходят на сайт по своему времени, а время в отчетах стоит по настройке Метрики.
Геоположение большинства клиентов можно определить по сводке «География» в разделе «Аудитория».
По ней видно, из каких стран идет трафик. Найдите, откуда большая часть аудитории, и выберите ее часовой пояс. Если получилось, что основной аудиторией вашего сайта оказались жители региона, с которым вы не работаете, стоит пересмотреть продвижение ресурса.
Блокировка Вебвизора
Иногда бывает, что Вебвизор выдает ошибку и не показывает посещения страницы. В качестве возможных причин ошибки высвечивается:
«Невозможно воспроизвести посещение на этой странице. Возможные причины:
Проверьте, включен ли Вебвизор в настройках счетчика. Иногда Вебвизор выключается — если не смотреть записи в течение последнего полугода. Тогда нужно просто включить опцию заново.
Блокировщик рекламы заблокировал и Вебвизор
Если счетчик установлен корректно и дело не в нем, возможно, виноват блокировщик рекламы. Попробуйте посмотреть с браузера, где нет блокировщиков.
Если дело в этом, зайдите в настройки блокировщика рекламы и добавьте в «белый список» webvisor. com и metrika. yandex. ru, после чего перезагрузите Метрику.
Фаервол блокирует Вебвизор
Антивирус, фаервол компьютера или корпоративной сети может блокировать доступ к доменам:
Чтобы исправить это, нужно добавить домены в доверенные.
Сервер блокирует Вебвизор
Проблема может заключаться в защите от показов в iframe.
Решить эту проблему можно, если убрать запрет в конфигурации сервера, файле htaccess или настройках CMS. Придется удалить код защиты, это увеличивает уязвимость сайта. Веб-мастерам приходится выбирать, что приоритетнее: безопасность или работа Вебвизора.
Расскажите, с какими еще ошибками в настройке Метрики вы сталкивались?
Про перекос данных в Google Analytics есть отдельная статья «10 популярных ошибок настройки Google Analytics и способы их исправить».