Виктор Чернов

Я пробовал и вверху ставить счетчик, и внизу. Все равно он блокирует основной поток. Если ставить счетчик Яндекса с задержкой, то  его тормозящее действие сильно уменьшается.
При использовании любого метода установки с задержкой есть такая неприятность - при маленьком трафике значок счетчика загорается красным, типа счетчик не найден. Но  он все равно считает посетителей.
Можно сделать показатели pagespeed 90/99, отложив загрузку рекламных баннеров, счетчика, социальных кнопок на 1,.5 - 2,5 секунды. А First Input Delay (FID) - задержка первого ввода будет 200 мс, и надпись "Origin Summary: Согласно данным наблюдений за последние 28 дней сводная оценка всех страниц из этого источника не отвечает требованиям к основным интернет-показателям."
Сайт начинает жить двойной жизнью:
1. Вначале загружается то, что требуется для хороших показателей pagespeed, 
2. Потом загружается все остальное (реклама, счетчики, социальные кнопки, чаты и прочее.
В результате показатели скорости хорошие, а сайт плохо реагирует на действия пользователей. В  консоли инструмента разработчика гугл хром видны кучи замечаний типа: " [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive", то есть "[Нарушение] Добавлен не пассивный прослушиватель событий к событию "touchstart", блокирующему прокрутку. Подумайте о том, чтобы пометить обработчик событий как "пассивный", чтобы сделать страницу более отзывчивой". В основном портят все впечатление о сайте скрипты https://yastatic.net/ - оттуда скачиваются огромные библиотеки.
Работа с пассивными прослушивателями при ускорении сайта очень сложная. Сложнее,  в разы, чем все остальное вместе взятое. Pagespeed может не указывать эту ошибку, но в консоли разработчика (вызывается в гугл хром кнопкой f12, после нее желательно обновить страницу все эти ошибки видны. 

На пару секунд время на сайте уменьшается. Но, посетители сайта с низкой скоростью интернета будут повторно приходить на ваш сайт, он станет комфортнее для них. Показатели скорости по speed/pagespeed/insights улучшаться, в выдаче гугл сайт лучше будет показываться.

5000 ботов под управлением одного злоумышленника? Как думаете.

""но не ограничивает их присутствие на сайте""
На сайте пусть присутствуют. Главное выбросить из статистики.
Google Analytics мне кажется проще воспринимает этих роботов.

А не пробовали в настройках фильтров в метрике изменить способ фильтрации роботов?

Если установить по этой инструкции:
https://vc.ru/dev/158627-uskoryaem-rabotu-sayta-na-etape-razrabotki-i-obgonyaem-konkurentov-v-poiske-chast-2 
то запускается после загрузки страницы после скрола

Поменяйте счетчик в Яндекс метрике. Установите счетчик через Гугл Таг Менеджер. И сам счетчик, и его номер, больные на голову накрутчики не будут  видеть. А если в коде сайта номер счетчика виден, то счетчик с Вашим номером могут куда угодно установить, и он будет работать. Хотя в настройках счетчика надо устанавливать галочку в графе "Принимать данные только с указанных адресов".
Из Таг менеджера можно запускать счетчик после загрузки страницы, и с задержкой. Можно запускать после события "скролл". Боты редко умеют скролить, реальные посетители сразу скролят. При отсутствии нашествия роботов и ботов при запуске счетчика после скролла посещаемость снижается примерно на 10%.

Даже в рекомендациях по оптимизации ввели пункт:
"Перейдите на протокол HTTP/2".

Все таки апдейт у них. Они стали проводить измерение при подключении по http/2 для выполнения сетевых запросов, если сервер его поддерживает. То есть у сайтов, которые на серверах с поддержкой http/2 выросли показатели.
https://developers.google.com/speed/docs/insights/release_notes?hl=ru-RU&utm_source=PSI&utm_medium=incoming-link&utm_campaign=PSI
"3 марта 2021 года
По состоянию на 3 марта 2021 года PageSpeed Insights использует http/2 для выполнения сетевых запросов, если сервер его поддерживает. Ранее все запросы выполнялись с помощью http/1.1 из-за ограничений в инфраструктуре подключения. С этим улучшением вы можете ожидать большего сходства между результатами Lighthouse от PSI и от Lighthouse CLI и DevTools (которые всегда делали запросы с помощью h2). Однако важно иметь в виду, что различные среды (аппаратное обеспечение и подключение) будут влиять на измерение, поэтому согласованность между средами практически невозможна.

С этим изменением сетевые подключения часто устанавливаются быстрее. Учитывая, что ваши запросы обслуживаются в h2, вы, вероятно, можете ожидать улучшения показателей и оценки производительности. В целом, показатели производительности по всем запускам PageSpeed Insights выросли на несколько пунктов."

Сегодня в pagespeed/insights странность - вчера показатели были 60-80 (мобильный и десктоп), а сегодня 90-99. У меня так, или у всех? Или апдейт такой у них?

Матчасть у всех разная. Поэтому излагаю как один из вариантов. У меня 4G быстрый, а 3G значительно медленнее.

"Проверять на конкретном компьютере смысла нет, с подключением в 100мб/с и core-i7 11th. Поэтому ценность данного расширения стремится к нулю." - Так не надо делать!
Выключите роутер. Подключите компьютер от вай фай смартфона. Там есть режимы 3G, 4G - вот вам и условия, близкие к реальным.
Скорость интернета можете уменьшить, заэкранировав смартфон - положите его в кастрюлю и прикройте слегка крышкой. 

CLS зависит от скорости интернета. Поэтому эта метрика очень не стабильна.
Сайт надо испытывать несколькими сервисами. И пытаться улучшить на всех сервисах.
Расширение для Гугл хром "web-vitals-extension" весьма интересно. Показывает скорость загрузки сайта в вашем компьютере в условиях вашей скорости интернета

Нет, направление движения выбирать по эмуляции. Но главная цель должна быть не 100/100, а "Сводная оценка всех страниц из этого источника отвечает требованиям к основным интернет-показателям". И если ради главной цели надо пожертвовать результатом при эмуляции, то надо жертвовать. 
Ведь при эмуляции проверка сайта идет в сети 3G с помощью "старенького" смартфона. И настроив сайт на этот режим мы делаем его не оптимальным для большинства реальных пользователей, у которых дома, на работе, при поездке в метро есть возможность подключения к нормальной сети.
Обратите внимание на сервис loading.express. Они проводят проверку сайта в более реальных условиях. Их результат проверки ближе к данным по реальным пользователям. 

Тестировать, настраивать сайт надо по эмуляции. Но за главный критерий качества принимать не результаты эмуляции, а результаты посещения сайта реальными пользователями. Так как результаты эмуляции могут быть обманчивы.
Проверьте любые сайты, и Вы  увидите, что у кого то при 50 сайт удовлетворяет требованиям Гугл, а у кого то при 80 сайт НЕ удовлетворяет требованиям.

Именно так как Вы пишите. Но, Гугл оценивает сайт именно по результатам посещения сайта реальными пользователями. Поэтому в первую очередь надо обратить внимание на LCP, FID и CLS даже в ущерб суммарному показателю скорости загрузки при эмуляции.

Куда это все бегут? А, в зеленую зону. Но бежать то надо не туда, а за записью в Google Page Speed: "Origin Summary Согласно данным наблюдений за последние 28 дней сводная оценка всех страниц из этого источника отвечает требованиям к основным интернет-показателям". 
Запись появляется только тогда, когда LCP,  FID и Cumulative Layout Shift (CLS) удовлетворяют требованиям Гугл. Остальные параметры, необходимые  для входа в вожделенную зеленую зону не важны для "Отвечает требованиям к основным интернет-показателям".
При очень плохом Time to Interactive (через 15 секунд браузер начинает реагировать на действия пользователя) Google Page Speed может быть в красной зоне (показатель 45), и тем не менее "Согласно данным наблюдений за последние 28 дней сводная оценка всех страниц из этого источника отвечает требованиям к основным интернет-показателям"!
А если Cumulative Layout Shift (смещение макета при загрузке) равен 0,11, а все остальное ускорено до максимума, то можно даже в зеленой зоне при 92 - 94 получить запись "Не отвечает требованиям к основным интернет-показателям".

Если сайты известных банков в смартфоне грузятся 10 секунд, а реагировать на действия пользователя - через 60 секунд, то в ТОПе их не будет.
Сейчас школьники, походив на курсы вебмастеров в разы грамотнее тех специалистов банков, которые отвечают за сайты.

Добрый день! Не совсем понятно, как измеряется "живой" First Input Delay (FID). В PageSpeed Insights для десктопа 2 мс, для мобильного 80 мс.А в loading.express где помечено "Живые данные Core Web Vitals" - 23 мс. Как эти 23 мс измеряются? - это среднее в десктопе и смартфоне?