уменьшите влияние стороннего кода metrika

Как устранить влияние Яндекс.Метрики на показатели Google PageSpeed Insights

Сервис Google PageSpeed Insights является одной из «пузомерок» с помощью которых вебмастера проверяют скорость работы сайта. Этот сервис анализирует контент веб-страницы и советует, как ускорить ее загрузку. В идеале все хотят видеть зеленый индикатор со значением 100.

Но как бы тщательно вы не оптимизировали свой сайт сразу после внедрения счетчиков посещений будь то Яндекс.Метрика, LiveInternet или Google Analytics индекс PageSpeed проседает на пару десятков пунктов.

Примеры показателей PageSpeed для моего тестового сайта:

До внедрения Яндекс.Метрики

После установки счетчика Яндекс.Метрики

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

По-совести говоря, счетчик Яндекс.Метрики никак не влияет на скорость загрузки сайта. Но несмотря на то, что код Яндекс.Метрики стал намного быстрее, Google PageSpeed всё равно ругается на него благим матом.

Как снизить влияние Яндекс.Метрики на скорость загрузки сайта

Чтобы нивелировать влияние стороннего JavaScripts кода, будет разумно отложить загрузку счетчика на несколько секунд. То есть будем загружать его только после полной загрузки сайта браузером пользователя. В таком случае он точно не будет влиять на скорость отображения контента страницы.

Например, можно использовать следующий код:

Предложенное авторами решение подойдет для всех сайтов. Но если вы используете WordPress, то проще всего воспользоваться бесплатным плагином True Lazy Analytics. Который кроме упомянутой мной Яндекс.Метрики умеет добавлять на WordPress сайт счетчики LiveInternet и Google Analytics.

Основная цель плагина — подключить системы аналитики без снижения баллов в тесте Google PageSpeed Insight.

Внешний вид плагина True Lazy Analytics

Вам достаточно указать только номер вашего счетчика Яндекс.Метрики и перед закрывающим тегом

Источник

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». Сейчас там можно и поставить устаревший код яндекс, который очень сильно понижает скорость сайта, и просто вставить код счетчика. Что на много проще и не снижает скорость сайта!

Еще раз спасибо автору, за то что указал на данный плагин. Раньше его не ставил по причинам «мало балов и установок». Но плагин оказался отличным!

Источник

Сторонний код

Чтобы «разогнать» сайт, проведения одного аудита, а ещё хуже — простого замера скорости,совсем не достаточно. Будучи инструментом со сложной конструкцией, он требует всесторонней работы и изучения возможных ошибок. Наша команда проводит многоступенчатое тестирование и только на основании собранных из нескольких источников данных делает выводы. Затем, исправляется каждый недочёт. Стоит учитывать, что одна ошибка может повлечь за собой целый ряд. Это как в автомобиле, когда неисправность одного узла, тянет за собой поломки в других, а ремонт наиболее очевидной ничего не даёт. Так и при оптимизации сайта — далеко не факт, что проблема кроется в наиболее явной ошибке. Поэтому, корректировки нужно проводить взвешенно и аккуратно. В результате нашей работы — заказчик получает сайт оптимизированный на максимум и с правильными настройками для дальшейшей работы. Это уже не просто страничка в интернете, а полноценный инструмент маркетинга.

Но что делать, если вы уже провели все оптимизации самостоятельно, а сайт всё-равно загружается медленно. Проводя тестирование при помощи сервиса Google PageSpeed Insights, в результатах аудита может отобразиться строка «Сторонний код». Разбираемся, что это значит и как сделать так, чтобы сторонние коды не мешали загрузке страницы.

Что такое сторонние коды и чем они могут навредить

Сторонние коды это всё, что не имеет прямого отношения непосредственно к вашему сайту: реклама, аналитика, трекеры, кнопки социальных сетей, переход на Youtube и так далее. Эти сторонние сценарии могут иметь решающее значение для функциональности сайта или потока доходов. К примеру — рекламные ссылки и банеры. Но сторонние сценарии также сопряжены с целым рядом рисков, на которые нельзя не обращать внимание. А значит, необходимо свести эти риски к минимуму, при этом не потеряв пользы от них.

Чем могут навредить сторонние коды и почему стоит быть с ними внимательным:

● Снижают производительность сайта

● Снижают уровень конфиденциальности пользователей

● Могут нести в себе вредоносные файлы

● Могут быть непредсказуемыми и меняться без вашего на то согласия

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

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

Сторонние коды в JavaScript

Мы уже выяснили, что к сторонним кодам относятся любые скрипты, которые встраиваются в сайт от стороннего поставщика. Размещая у себя ссылки на Facebook, VK, Instagram вы тем самым ставите сторонние сценарии, не говоря уже о рекламе и другом контенте. Тем не менее, они увеличивают конверсию и являются полезными.

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

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

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

Среди проблем, которые могут всплыть:

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

● Могут отправлять слишком большое количества JavaScript, который занимает основной поток. Стоит учитывать, что в JavaScript останавливает процесс построения DOM, задерживая скорость отображения страниц.

● Файлы, изображения, видео могут быть не оптимизированы. Это не только негативно влияет на скорость загрузки, но и съедает трафик пользователей.

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

● Устаревшие API, которые они могут использовать, наносит вред пользовательскому интерфейсу.

Для начала необходимо выявить какие сторонние коды есть на сайте и сколько ресурсов требуется для их загрузки. Как известно — найти проблему, равно половине её устранения. Делается это при помощи специальных инструментов, которые позволяют выявить скрипты, провести их бейнджинг и аудит времени загрузки маяка. Только одним инструментом здесь обойтись невозможно. Необходимо применять все и в определённой последовательности.

Как эффективно загрузить сторонний скрипт?

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

● Загрузите код, используя атрибуты «async» или «defe»r, во избежание блокировки анализа документа.

● Рассмотрите возможность самостоятельного размещения кода, если сторонний сервер работает медленно.

● Удалите скрипт, если он не приносит пользы сайту, а только впустую потребляет ресурсы

Все сторонние коды и сценарии необходимо запускать асинхронно, чтобы они не блокировали DOM, и анализ HTML-документа продолжался. При этом, не подавайтесь на уловки поставщика сторонних кодов, которые предполагают синхронную загрузку. Это негативно скажется не на их, а на вашем сайте. Корректные настройки произвести можно всегда. Для этого потребуются грамотные специалисты, которые разберут коды на составляющие и встроят их так, как нужно.

Источник

Скрипт метрики (tag.js) съедает процессорное время при загрузке

Обнаружил что при загрузке страницы скрипт Яндекс.Метрики что-то очень активно обрабатывает. Длится это

400 мс. Проверял на 2х сайтах.

Небольшое копание вглубь показывает (насколько я понял) что для работы вебвизора либо аналитики форм метрика индексирует весь DOM и именно на это уходит очень много ресурсов.

Кто-то сталкивался с подобной проблемой? Совсем отказываться не хочется, но и людей с мобильными браузерами жалко.

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

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

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

Сейчас мы работаем над созданием новой версии легкого кода счетчика, который будет работать быстрее. В настоящее время проводится закрытое тестирование: https://yandex.ru/blog/metrika/otkryvaem-zapis-na-testirovanie-novogo-koda-schetchika

Следите за новостями;)

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

320кб минифицированного файла.

страница со счетчиком становится доступной пользователю почти на секунду позже, чем страница без счетчика http://joxi.ru/823RRZZcJNl9Rm

Для моб версий сайтов это достаточно негативно сказывается на пользовательском опыте.

У нас файлы скриптов spa-приложения, написанного на реакте, с редаксом, роутингом, со всеми зависимостями меньше размером чем один скрипт счетчика метрики.

Команда метрики не думала по этому поводу огромного размера скрипта? Может для мобильных устройств нужно сделать скрипт поскромнее в размерах?

320кб минифицированного файла.
страница со счетчиком становится доступной пользователю почти на секунду позже, чем страница без счетчика http://joxi.ru/823RRZZcJNl9Rm

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

Команда метрики не думала по этому поводу огромного размера скрипта? Может для мобильных устройств нужно сделать скрипт поскромнее в размерах?

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

На смартфоне в Mozilla в адаптивной версии сайта наблюдаю замедление загрузки сайта, появляется окно ошибки сценария \»Внимание: Сценарий не отвечает\» и ссылка на сценарий https://mc.yandex.ru/metrika/tag.js:66

В Chrome ошибки сценария нет. Тормоза с загрузкой скрипта есть.

Добрый день, присоединяюсь к просьбе что-нибудь сделать с кодом Метрики:

На смартфоне в Mozilla в адаптивной версии сайта наблюдаю замедление загрузки сайта, появляется окно ошибки сценария «Внимание: Сценарий не отвечает» и ссылка на сценарий https://mc.yandex.ru/metrika/tag.js:66
В Chrome ошибки сценария нет. Тормоза с загрузкой скрипта есть.

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

И после этого вылетает программа SOCPUBLIC AGENT

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

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

пожалуйста, пришлите примеры ситуаций в поддержку: https://yandex.ru/support/metrika/troubleshooting.html

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

постоянно стал выдавать это сообщение и подвисать, что делать?

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

«,»replyTo»:»5d38b45e1c76670031159a7d»,»replyToName»:»Вова из Коврова»>>»>

tag.js поддерживает Вебвизор 2.0 и новые (и старые тоже) методы JS API.

Метрика сжирает 2 054 ms при загрузки сайта.

Метрика сжирает 2 054 ms при загрузки сайта.

У нас основной пожиратель времени по загрузке и выполению js, это YM:

если верить этому измерению, то код YM замедляет нам страницу на 1+ с, что конечно очень много в современных реалиях!
Сайт на Битриксе note-store.ru. И что делать? Никакого решения в интернете не нашел.

Аналогичная ситуация с кодом Я.Метрики, которая замедляет скорость загрузки страницы.

У нас основной пожиратель времени по загрузке и выполению js, это YM:
https://yadi.sk/i/sdgyzx1WkARKVg
https://yadi.sk/i/tm1jof6CjvC9vg
если верить этому измерению, то код YM замедляет нам страницу на 1+ с, что конечно очень много в современных реалиях!
Сайт на Битриксе note-store.ru. И что делать? Никакого решения в интернете не нашел.

здравствуйте. Посмотрел ваш сайт. Вы так и не нашли решение этой проблемы?

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

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

Вебвизор 2.0 включен.

Я так понимаю, что решить проблему можно только пожертвовав Вебвизором?

Тоже временно перешел на старый код метрики со старым вебвизором.

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

Да! Новый вебвизор сканирует весь DOM.
Тоже временно перешел на старый код метрики со старым вебвизором.

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

Попробуем старый код, спасибо за идею:)

Кто-то ка-то решил проблему? 🙂

Кто-то ка-то решил проблему? 🙂

В большинстве случаев при правильной установке код Метрики не должен существенно влиять на скорость загрузки сайта. Проверьте, что код счётчика Метрики установлен так, что он загружается полностью асинхронно от контента сайта.

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

В некоторых случаях может наблюдаться увеличение времени загрузки для счетчиков, у которых включен Вебвизор 2.0. Специфика его работы требует полной обработки контента сайта. Если ваш сайт обладает множеством контентных элементов, вы можете переключиться на Вебвизор 1.0, выбрав галочку \»Устаревший код счетчика\» в Настройках

https://yandex.ru/support/metrica/general/counter-general.html#other. Не забудьте переустановить код счетчика Метрики на всех страницах сайта.

Мы постоянно работаем над ускорением загрузки кода, и в следующих обновлениях кода счётчика представим более лёгкую версию.

02.02.2020 UPD: М ы работаем над новой версией кода счетчика, который будет работать быстрее. Записывайтесь на закрытое тестирование: https://yandex.ru/blog/metrika/otkryvaem-zapis-na-testirovanie-novogo-koda-schetchika

На данный момент в тестирование, в первую очередь, мы сможем взять счетчики с большим объемом трафика (

10 000 посетителей в неделю), т.к. на таких счетчиках можно быстрее протестировать работу нового кода.

В большинстве случаев при правильной установке код Метрики не должен существенно влиять на скорость загрузки сайта. Проверьте, что код счётчика Метрики установлен так, что он загружается полностью асинхронно от контента сайта.

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

В некоторых случаях может наблюдаться увеличение времени загрузки для счетчиков, у которых включен Вебвизор 2.0. Специфика его работы требует полной обработки контента сайта. Если ваш сайт обладает множеством контентных элементов, вы можете переключиться на Вебвизор 1.0, выбрав галочку «Устаревший код счетчика» в Настройках
https://yandex.ru/support/metrica/general/counter-general.html#other. Не забудьте переустановить код счетчика Метрики на всех страницах сайта.

Мы постоянно работаем над ускорением загрузки кода, и в следующих обновлениях кода счётчика представим более лёгкую версию.

02.02.2020 UPD: Мы работаем над новой версией кода счетчика, который будет работать быстрее. Записывайтесь на закрытое тестирование: https://yandex.ru/blog/metrika/otkryvaem-zapis-na-testirovanie-novogo-koda-schetchika

На данный момент в тестирование, в первую очередь, мы сможем взять счетчики с большим объемом трафика (

10 000 посетителей в неделю), т.к. на таких счетчиках можно быстрее протестировать работу нового кода.

Источник