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

+5
с 2021
0 подписчиков
28 подписок

Я пробовал и вверху ставить счетчик, и внизу. Все равно он блокирует основной поток. Если ставить счетчик Яндекса с задержкой, то  его тормозящее действие сильно уменьшается.
При использовании любого метода установки с задержкой есть такая неприятность - при маленьком трафике значок счетчика загорается красным, типа счетчик не найден. Но  он все равно считает посетителей.
Можно сделать показатели 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 улучшаться, в выдаче гугл сайт лучше будет показываться.

1

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

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

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

2

Даже в рекомендациях по оптимизации ввели пункт:
"Перейдите на протокол 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 мс измеряются? - это среднее в десктопе и смартфоне?

1