SEO
Nikita Spivak

Ускорение сайта или вред для SEO: отложенная загрузка метрик и ее влияние на показатель отказов

Решение написать пост было принято ввиду популяризации статей на тему ускорения сайтов на vc.ru и сотен комментариев под материалами в разделе SEO.

Во всех постах дублируются известные приемы оптимизации страниц сайтов вроде lazyload загрузки изображений, кеширования, GZIP и др., которые в "пузомерках" вроде Google Pagespeed Insights дают небольшой прирост, но на деле реально эффективны.

Для достижения вожделенной "зеленой зоны" (оценки 100/100 по тестам Pagespeed Insights), остается нерешенным вопрос долгой загрузки и блокировки страницы сторонними скриптами метрик (Google Analytics, Яндекс.Метрика, Facebook Pixel и другие).

Единственное предлагаемое решение - отложенная загрузка и выполнение данных скриптов. Но насколько такой подход оправдывает цель?

Более глубокого изучения данное решение не удостоилось, поэтому пришла мысль провести "коллективную дискуссию" - приглашаю вас в комментарии.

Вопрос достаточно емкий, и без небольшого бэкграунда не обойтись, поэтому разделим его на следующие тезисы (от общего к частному):

  1. цель оптимизации сайта (влияние скорости загрузки на SEO);
  2. объективность оценок сервисов Google Pagespeed Insights и подобных;
  3. отложенная инициализация метрик и показатель отказов.

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

  • в комментариях тесно для изложения мыслей на этот счет;
  • интересно разобраться в вопросе основательно.

Простите за долгое предисловие, не планировал лонгрид. Это не гайд (инструкция), не кейс (разбор), а скорее ресёрч (исследование).

Зачем ускорять сайт, и как оценить результат?

Прежде чем приступать к любой работе - важно понимать, какую цель преследует данный манёвр. Простыми словами - зачем это нужно?

Смысл оптимизации скорости загрузки сайта заключается в следующем:

  1. улучшить опыт пользователя - сократить время ожидания загрузки страницы, и тем самым минимизировать показатель отказов;
  2. в следствии п.1. ожидать преференции от поисковых систем в выдаче (не только благодаря быстрой загрузке, но и улучшению ПФ - снижению показателя отказов).

В целом тезисы ясны, но что считать быстрой загрузкой? Да, необходимое время загрузки в 1-2 секунды, и красивый график с показателями отказов все видели.

Красивый график с показателями отказов https://backlinko.com/hub/seo/bounce-rate

НО! К сожалению, показатель скорости загрузки сайта зависит от множества факторов:

  • тип устройства и его мощность (ПК, планшет, смартфон);
  • заявленная скорость интернет соединения (провайдер);
  • фактическая скорость (загрузка канала, качество сигнала и т.п.).

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

Однако, существуют популярные сервисы замера скорости загрузки сайта. Насколько в таком случае точна их оценка? Стоит ли гнаться за 100/100?

Проверка скорости загрузки сервисами

Такие инструменты как Google Pagespeed Insights (и другие, на базе Lighthouse), используют для своих тестов эмуляцию конкретных устройств, которые, по их мнению, подходят для этого.

Интересно было бы узнать, как проходит отбор таких устройств. Возможно, по усредненным техническим характеристикам, или по популярности распространения устройств, схожих по ТХ.

Интересно, что на сегодняшний день, в Lighthouse для тестирования скорости загрузки сайта используется устройство 2016 года выпуска - Motorola Moto G4 на базе процессора Snapdragon 617 от 2015 года.

При этом используется достаточно хорошее интернет соединение - 1,6Mbps/750Kbps - эквивалентный медленному 4G или быстрому 3G. Тестировали бы уже на EDGE. 🙃

Конечно, для гиков гаджеты - это все, и ориентироваться на работников сферы IT было бы не верным решением.

Но в эпоху, когда Apple наполняет рынок десятками моделей смартфонов, соревнуясь с Xiaomi, Samsung и Huawei у кого телефон более бюджетный, при средней комплектации, ориентироваться на Moto G4, кажется, тоже не совсем корректно.

Для получения реальных данных по мобильным устройствам, использующихся аудиторией вашего сайта, перейдите в Google Analytics - Аудитория - Мобильные устройства - Устройства.

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

Немного про железо

Проанализировав топ мобильных устройств своего сайта и, на основании технических данных этих устройств, сравним процессоры и их производительность с процессором Snapdragon 617, установленным в Moto G4, используемом в тестах Lighthouse.

Сравнение мощностей процессоров мобильных устройств посетителей с устройством эмулирующим загрузку в синтетических тестах Lighthouse.

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

В любом случае, Redmi Note 4 (на Snapdragon 625) - одно из самых устаревших устройств в списке аналитики, а в синтетических тестах замедление еще больше.

Таким образом, фактическая проверка оптимизации сайта, содержащего "современные" скрипты отслеживания (последнее изменение было в конце 2017 года), которые предлагает сам Google, проводятся на устройстве выпущенном в начале 2016 года. (голосом Михалкова) Иронично! 🙃

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

То есть синтетические тесты проводятся на очень устаревшем устройстве. Разумеется, есть не такие благополучные страны/города/районы/люди, и кто-то еще использует кнопочные аппараты, но ориентироваться на эту аудиторию странно, нет?

Отложенная загрузка метрик

Хватит же погружения в технически детали! Мы здесь, чтобы разобраться что делать и "как дальше с этим жить". Как достичь 100/100 по Pagespeed Insights?

Предлагаемое решение - отложить выполнение скриптов метрик для достижения эффекта быстрой загрузки, реализуемое следующим простым кодом:

document.addEventListener('DOMContentLoaded', () => { setTimeout(function(){ /* * Тут код отслеживания всех метрик, */ }, 3500); // время указано в мс = 0,001 секунды, изменить по вкусу });

Код можно модифицировать по-разному:

  • менять время задержки;
  • менять событие, по которому будет выполнятся код.

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

Как это работает: при загрузке страницы будут загружены и выполнены все стили и скрипты, кроме отложенных. Отложенные скрипты будут загружены и/или выполнены через какое-то время (например, 0.5-1 секунду) или по действию пользователя (при прокрутке страницы, например).

Используя данный код, скорость загрузки страницы безусловно повысится в PageSpeed Insights, поскольку скрипты не будут выполнятся сразу, но:

  • будет ли наша статистика такой же точной?
  • как следствие - не вырастет ли показатель отказов?
  • как следствие - не будет ли понижен ресурс в поисковой выдаче?

Можно уверенно сказать - часть посещений потеряется. Да, это могут быть незначительные визиты, до 1 секунды, боты и т.д. Но эти показатели тоже важны для поисковых систем.

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

Отложенным вызовом можно снизить пиковую единовременную нагрузку на процессор, распределив выполнение кода, не более того.

Из поиска по запросам "lazyload google analitycs" можно найти один очень старый (2011 год), но от этого не менее информативный, пост на Stackoverflow:

Другой информации, относительно изменений показателя отказов ввиду отложенной инициализации скриптов метрик, не удалось найти, кроме пары статей про ускорение сайта и статей на малазийском.

Вывод и опрос

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

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

Синтетические тесты предоставляют инструмент для ориентира, не более того. Но не стóит создавать сайты на шаблонах за 200$ с десятками ненужных скриптов и стилей, слепленных на коленке.

Решение об оптимизации сайта до "зеленой зоны" - не всегда верное и выполнимое в текущих реалиях, все зависит от:

  • типа сайта и контента;
  • целевой аудитории.

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

А что скажете вы, коллеги?

Влияет ли отложенная загрузка метрик на показатель отказов?
Влияет, критично. Показатель отказов важнее.
Влияет, не критично. Прирост скорости эффективнее.
Не влияет.
Показать результаты
Переголосовать
Проголосовать
{ "author_name": "Nikita Spivak", "author_type": "self", "tags": [], "comments": 124, "likes": 2, "favorites": 32, "is_advertisement": false, "subsite_label": "seo", "id": 185898, "is_wide": false, "is_ugc": true, "date": "Sun, 13 Dec 2020 16:05:17 +0300", "is_special": false }
0
124 комментария
Популярные
По порядку
Написать комментарий...
4

Не вижу ничего страшного в отложенной загрузке метрик, это никак не скажется на поведенческих. Большинство роботов и так известны ПС. Они их заходы не считают посетителями.
Но!!! Никакого прироста производительности сайта это не даст! GA не обсаживает скорость вообще никак (незначительно настолько, что это смешно!), а с яшиной метрикой ЗАЕ**ТЕСЬ  вы бороться!! Эта шляпа, как ни крути, куда ты её не откладывай, один хрен mobil скорость обсаживает на 20-30% по speed test Google!
Вообще, метрики, это не самое страшное, большинство сайтов страдают из за css и картинок. Ну а если у вас сторонние скрипты на сайте (та же подтяжка товаров от партнёров), то это вообще жопа!
Самое прикольное, что скорость загрузки влияет на ранжирование сайта в 100500 ю очередь! При прочих равных более быстрый сайт в выдаче будет выше.
Потому, господа, не парьтесь из за метрик. Вообще! Чтоб попасть в топ, зелёной зоны недостаточно!!!
Да, обращаясь к автору, Никита!, тебе ли не известно, 100/100 даже голый Google не даёт! Последний тест его же инструментом, показал 98/100.

Ответить
1

То есть получается отложенная загрузка приводит просто к "очищению" статистики.

По поводу оптимизации метрик: да, мы рассматриваем и Яндекс.Метрику тоже - ею тоже пользуются. Но на google analytics PageSpeed тоже реагирует (кеширование, неиспользуемый код, влияние стороннего кода и т.д.)

Прирост скорости - да, фактическое количество кода остается таким же, но все ж SEOшники первым делом проверяют наличие "зеленой зоны" и начинаются пляски :)

CSS и картинки решаются исключением шаблонов и lazyload (про это уже исписался), а вот то что влияет это в последнюю очередь - это полезно будет узнать всем требующим минимум 90/100.

Про идиотию в этом тесте писал еще в феврале 2015 года, пока это еще не стало мейнстримом. С тех пор много воды утекло и я многому научился, в том числе и статьи писать лучше, а Pagespeed каким был - таким и остался.  🤣

Ответить
1

Попробовал как-то сделать отложенную загрузку метрики описанным вами способом... Первый же вопрос к вам - вы сами пробовали это сделать? Просто итог которому приводит задержка в активации метрики - ее полное отключение. Счетчик начинает "гореть" красным, и перестает собирать посещения. Не часть, а все. От слова "совсем"... Ах, да, забыл уточнить - проявляется это только дня через 3-4, когда метрика начинает понимать, что счетчик работает не так как задумано. А в начале все ок - все тесты на ура, и попугаи в PageSpeed глаз радуют)))) Да, и другие способы, каким-либо способом затрагивающие код счетчика - приводят к такому же результату. Единственный способ, который я не пробовал - полная загрузка скрипта метрики к себе на сервер... Но это, на мой взгляд, уже перебор - тем более что эффект от этого не такой уж и значительный, да на циферки в PageSpeed повлияет, но для большинства коммерческих сайтов плюсы даже не будут заметны.

Ответить
0

Нет, не пробовали. Я пока только рассматриваю это решение со всех сторон, провожу ресерч.

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

Загрузка на свой сервер вообще ничего не решает - аналитика в коде загружает еще скрипты - все дерево выкачивать и редактировать ссылки на скрипты в файлах? Тогда не автоматизируешь обновление. В общем совсем не правильно.

Ответить
1

Возможно) я поделился с вами своим практическим опытом. Если у вас будет по другому - буду рад за вас, и с удовольствием почитаю про ваш экспириенс: что это дало, стоит ли оно трудозатрат и т.п.

Ответить
0

Вот это мы и пытаемся выяснить, поскольку есть еще опасения по потерянным посещениям :) Но вроде все пишут что кроме "чистой" статистики ничего не дает.

Ответить
0

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

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

Конечно, гнаться бездумно за 100/100 на существующем проекте глупо, но что касается новых - мастхэв. 

Ответить
0

Михаил, ближайший к вам конкурент может быть качественнее по контенту. По количеству полезных для сайта юзеров, в конце концов. Скорость сайта как фактор ранжирования оценивается в последнюю очередь. Да и сайтов, чтоб давали 98/100 по speed test я видел всего 2. И оба лендосы. Один на bitrix, другой на wp. Больше не довелось. А, ещё Google даёт)) 

Ответить
0

Да ну. Посмотрите наши рейтинги. Там полно сайтов с зеленым пейджспидом.

Ответить
0

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

Ответить
0

где их можно посмотреть? У вас на сайте нет портфолио - я и раньше искал, интересно было расковырять :)

Ответить
3

А вы проводили исследования по влиянию количества набранных баллов PageSpeed Insight на позицию в поиске? По моим данным для Google корреляция с позицией такая, что можно особо не заморачиваться с оптимизацией. На изображении по оси X позиция в поиске от 1 до 20, по оси Y - количество набранных баллов.

Ответить
0

Нет, спасибо за предоставленный график.

Ответить
0

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

Ответить
0

Ну за 10кой скорость медленне. Да и надо с фонами сравнивать, как в исследованиях Ашманова. Вопрос, как сильно влияет.

Ответить
1

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

Точность метрик Аналитикс и Яндекса снижается, но мы откладываем её не на 3500 мс, как в статье, а на 200-600 мс. Спросите в чем тогда смысл? Смысл в том, чтобы дать время выполниться без соединений и работы с DOM другим нужным для FCP и LCP элементам, и поставить выполнение внешних скриптов в конец очереди. Хотя бы сместить их на несколько позиций.

Чаты и попапы смело можно на 5-10 секунд откладывать, чтобы дать время выполниться родным скриптам сайта, которые нужны для отрсовки родного содержимого и взаимодействия с ним.

Откуда вообще эта идея в отложке? Это не для того, чтобы синтетика не ловила эти скрипты, а в том, что реальные пользователи выполняют родные скрипты сайта раньше чем сторонние. Однако этот подход практически бесполезен, если внутренние js-скрипты выполняются 10 секунд и на странице инициалиируется 10 слайдеров, при помощи плагина к библиотеке с кучей зависимостей.

Поэтому первоначально обязательно нужно оптимизировать СВОЙ КОД. Переработать, переосмыслить и то, что нельзя оптимизировать — тоже нужно откладывать по времени, или по действию пользователя.

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

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

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

Ответить
1

Я находил как то плагин для WP, который как раз откладывает выполнения скриптов (как раз чаты, попапы и тд) до взаимодействия с пользователем. Название - Flying Scripts by WP Speed Matters
видео по нему на Ютюб 

Ответить
0

По внутренней оптимизации.

Иногда инициализация одного внутреннего слайдера может занимать 2-3 секунды, так как приходится ждать ответа от бакенда, или загружать 1-2 библиотеки и существенно изменить DOM, вызвав тем самым перерисовку несколько раз подряд.

Простое изменение порядка работы с DOM может существенно снизить время выполнения задачи.

Пример:

вместо того, чтобы вставлять в страницу 10 элементов, вставляем один, который уже содержит эти 10 элементов, что уже вызовет одну перерисовку, вместо 10. Лучше конечно вообще не менять DOM из js без ведома пользователя.

В крайнем случае добавлять, но не менять. Это позволит еще и контролировать CLS, так как все элементы будут стилизованы без js.

Изменения css-свойств также может вызывать перерисовку всего содержимого. Нужно быть аккуратнее и не менять свойства своим js скриптом после загрузки страницы, оставив это на момент взаимодействия с элементом.

Ответить
1

Про 100/100 по PageSpeed Insights.

Не надо. Не гонитесь за этими баллами. Надо сделать быстрый FCP. Именно он влияет на "восприятие" скорости.

+ уменьшить время блокировки потока, чтобы повысить интерактивность.

Ответить
0

Изменения в HTML через JS это такой ад. Мне кажется уже все от этого ушли, разве нет? Или в темах еще есть?

Слайдеры добавляют пару div'ов (пагинация и стрелки) - не критично я думаю, а ajax подгрузка контента активируется при скролле или при нажатии на кнопку.

В общем в моем представлении такие сайты все-таки это последствие неверного подхода к разработке. Когда стили переопределяют на все элементы и т.д.

Ответить
0

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

А то что HTML менять через JS - стандартное дело вообще. Всюду, кругом так происходит. То что вы не видите этого - не значит что этого нет.

Ответить
0

Возможно, вы имеете ввиду перестроение DOM дерева? Когда добавляются элементы на страницу - происходит перестроение, а перерисовка (Cumulative Layout Shift) - когда слайдер сворачивает элементы в строку и меняется вид отображения.

То есть при инициализации слайдера происходит одно перестроение - добавление элементов управления. Тогда при инициализации нескольких слайдеров, по идее происходит N перестроений, где N - количество слайдеров на странице.

А перерисовка  - должна быть одна, когда все слайдеры на странице инициализируются и превращаются из блоков в столбец в слайдеры. (можно минимизировать перерисовку при помощи CSS).

Иногда инициализация одного внутреннего слайдера может занимать 2-3 секунды, так как приходится ждать ответа от бакенда, или загружать 1-2 библиотеки и существенно изменить DOM, вызвав тем самым перерисовку несколько раз подряд.

Почему при инициализации слайдера нужно ждать бэкенд? Слайдер (тот же slick, например) - JS, работает с DOM. Какие вы используете технологии?

А то что HTML менять через JS - стандартное дело вообще. Всюду, кругом так происходит. То что вы не видите этого - не значит что этого нет.

Не уверен. Подгрузка HTML в наших проектах, во всяком случае (мы же не говорим про бесконечную ленту Facebook или сервисы Yandex, а про обычные сайты), реализуется либо при инициализации слайдеров (или других библиотек для спец. блоков), либо при подгрузке контента через AJAX по действию (скролл/клик и т.д.). Анимации не должны контент подгружать, а только изменять классы (тоже на скролл).

Напоминаю, я сам разработчик, если мне нужно что-то увидеть - я найду :)

Ответить
0

🤯🤯🤯

Ответить
0

Сложно расценить это как профессиональный ответ. Или я слишком углубился в тему?

Ответить
0

слишком углубился в теорию
лечится часами практики
но в вашем случае не уверен)) 🤔 

Ответить
0

Ну правильно, у вас видимо другой подход

Ответить
0

другой
мы практики
каждый день десятки сайтов приходит на анализ
а теоретикам место на форумах))

Ответить
0

По поводу снижения баллов за Яндекс.Метрику.

20-30 баллов Метрика может снять только в случае, если поток занят перерисовкой или выполнением скриптов уже после загрузки страницы. До крутизны Analytics ей достаточно далеко, и блокирует поток она на 300-600 миллисекунд, при троттлинге 4х на макбук PRO.

Но ребята занимаются и стараются оптимизировать скрипт Метрики. Если на странице вообще нет JS, то вставка метрики и аналитики снизит показатели PageSpeed незначительно, оставив их в зеленой зоне.

Пример:

https://3-секунды.рф — тут вообще без отложки метрики. Делаем 10 перезамеров PageSpeed и получаем 95-99 баллов.

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

Ответить
1

Вам повезло, через CDN jsdeliver дает 1 390 ms блокировки! 1,4 секунды!
Я не знаю связано ли это с использованием CDN (по идее не должно быть, поскольку скрипт-то один и тот же), но это не 600 миллисекунд)

Сайт из примера - три экрана без картинок и контента. Ну его приводить как-то не серьезно, что ли. Да, и у него 85, а не 95-99. То есть даже если перезамерять 10 раз - уже из диапазона выпал и значительно так.

Ответить
0

Спасибо за комментарий, наконец-то дождался от вас какой-то конкретики.

 Точность метрик Аналитикс и Яндекса снижается, но мы откладываем её не на 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/), безусловно, речь про аналитики и другие внешние скрипты, КОТОРЫЕ ОПРАВДАНЫ, а не картинка с чужого сайта)

Ответить
0

Префетч не решит вопрос от слова совсем. Вообще. Он сделает оценку еще хуже.

"А любая попытка преконнекта или прелоада снизит оценку в желтую зону, так как соединение начнет блокировать поток раньше, чем необходимо."

Тут написано для вас специально:

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

Вы плохо и невнимательно читали. Я негодую. Зачем мы тут распинаемся перед вами. Жуть.))

Ответить
0

Ваши слова идут в разрез документации, поэтому, что логично, они подвергаются сомнению. А ваше высокомерие необоснованно и неуместно.

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

Источник: https://developer.mozilla.org/ru/docs/Web/HTML/Preloading_content

https://developer.mozilla.org/ru/docs/Web/Performance/dns-prefetch

Вот что пишут в документации, помимо статей на хабре.

Ответить
0

Да-да Никита, вы непробиваемый. Мы тут уже все это поняли.))
Вот когда начнете практиковать, то всё поймете, а пока вы теоретик - всё тщетно.
Больше я вам ничего писать не собираюсь.)) Удачи. 🤞 

Ответить
0

Отличная попытка. В ответ на конкретные аргументы переходить на личности. Задача - разобраться - поэтому много аналитики.

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

Вы только подтверждаете мои догадки относительно вашей некомпетентности в техническом плане.

P.S. Ни одной ссылки на ускоренный вами сайт вы так и не предоставили, кстати.

Ответить
1

Никита. Я почитал этот диалог выше.
 И посоветовал бы прислушаться к тому что говорит Алексей. Прелоад и префетч для баллов в пейджспид -  это путь вникуда. Да, возможно для реального ускорения в мсек, но не для баллов.
Просто Вам нужно взять сайты новичков-вебмастеров с курсов Пузата и попробовать их ускорить. А там по 3 слайдера, font awesome, 5 разных счётчиков статистики и куча прочей дряни.
Вот после этого Вы поймёте, то о чём говорит Алексей.

Ответить
1

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

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

Когда в проект подключается jQuery + BS + кастомный код + аналитики. Все. А вот это вот, давайте не рассматривать. Понятно что их сайт вообще не оптимизирован.

Ответить
1

Короткий ответ на Ваши вопросы - прелоад бесполезен, хотя и рекомендуется в документации.
Два основных пути по оптимизации, которые дают быстрый результат:
1. отложенная загрузка скриптов
2. максимально убрать всё с первого экрана

Всё остальное: настройка кеширования, swap для шрифтов .... и прочее дают малую прибавку по баллам.

Ответить
0

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

Ответить
0

Если вы оптимизируете сайты учеников Пузата, как пишет Евгений, тогда вопросов больше не имею)

Ответить
0

Ученики Пузата зарабатывают не по десять даже лямов в год.)) Зря вы так про них. Не все конечно, но есть такие.
И да, им мы сайты тоже ускоряем. Обращаются, потому что Роман нас рекомендует. И кстати, до сайта Романа мы тоже почти добрались, но пока 20 год сплошная неожиданность. В 21 году сделаем его быстрым точно.
И кстати. Кто высокомерен после такого выпада на учеников Романа?

Ответить
0

Ахаха, не зарывайтесь еще глубже, остановитесь, а то никто супер-скрипты setTimeout() по 599 рублей покупать не будет, после прочтения этого диалога.

Вы как комментарии читаете? Я и не знал про существование Пузата, пока Евгений не написал! https://vc.ru/seo/185898-uskorenie-sayta-ili-vred-dlya-seo-otlozhennaya-zagruzka-metrik-i-ee-vliyanie-na-pokazatel-otkazov?comment=2287335

А мой ответ был простым:
 Если вы оптимизируете сайты учеников Пузата, как пишет Евгений, тогда вопросов больше не имею)

В чем тут выпад, высокомерие? Обоснуете, или только "мелиораторское" искусство освоили?

Ответить
0

Если вы про этот комментарий: https://vc.ru/seo/185898-uskorenie-sayta-ili-vred-dlya-seo-otlozhennaya-zagruzka-metrik-i-ee-vliyanie-na-pokazatel-otkazov?comment=2288448 (странно ветка работает - сортирует сообщения не по хронологии).

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

Ответить
0

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

Ответить
0

Красиво ушли от ответа в который раз. Никто вас не просит публиковать ссылки - можно было отправить в ЛС и сохранить лицо. А рассказать я тоже умею. Главное еще руками поводить многозначительно. Вы, случайно, не ученик Гандапаса?

Кстати, таких товарищей, нынче, еще больше чем теоретиков ;)

Не буду вдаваться в подробности, но ваш пафос выглядит смешно, особенно на фоне общедоступной информации)

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

Ответить
0

О да, потому что как мы все здесь поняли - вы не умеете читать внимательно и вникать в ответы. 
Теория ваше всё. Ну и вот эти все тычки про пафос - вообще непонятное что-то. Пока-пока. 👋 

Ответить
0

Мы, они, все.
Ночь, улица, фонарь, аптека.
Конь, стул, двадцать два.

Да до свидания, до свидания.
Сколько можно прощаться уже? Какой вы нерешительный.
Всего доброго!

Ответить
0

Да-да. Мне просто нравится с вами прощаться. Вы забавный.
Но какие наши годы. Мне тоже 24 было десять лет назад. И тоже мог писать такие тексты.))

P.S. Ответы на ВСЕ ваши вопросы заданные когда либо есть в том большом моем комментарии. То что вы не умеете читать внимательно это я уже заметил. Это вас и подводит. А писать одно и тоже для вас - сомнительное удовольствие.

Ответить
0

Ой, б***ь, началось 🤦‍♂️ "мне 24 было 10 лет назад", "а у меня длиннее", "а наша компания на рынке с 934 года".

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

Обратите внимание - вы единственный из "ВСЕХ", кто что-то там у вас понял, с кем возникла подобная перепалка.

Может вы конкурентов боитесь? Так это, опять таки, неуверенность в вас говорит и несостоятельность.

Вам точно 24 БЫЛО 10 лет назад? Может вы имели ввиду БУДЕТ через 10? Ваше поведение выдает возраст.

И откуда информация что мне 24? 🤣
Мимо.

P.S. ВСЕ мои вопросы, которые возникали по вашим ответам есть в моих тех комментариях. То что вы не умеете отвечать на вопросы это я уже заметил. Это вас и выдает. А поддерживать ваш пустой треп - сомнительное удовольствие. 🤣

Ответить
0

Да вы не волнуйтесь так, Никита. Всё пройдет.

Ответить
0

Пройдет и это, Алексей)

Ответить
1

Нужно ли рассматривать в качестве отказа неучет посещения ботом длительностью менее нескольких секунд? Бот, очевидно, не пытался ничего полезного сделать.

Поэтому потеря посещений если и произойдёт, то только на такие мусорные посещения. Совсем не страшно

Ответить
0

Получается, таким образом, вообще можно «подстраивать» статистику под пожелания. Сделать показатель отказов = 0.

Сделать отложенную загрузку на 10 (подставляем среднее время большинства мусорных посещений) секунд и если пользователь не очень заинтересован - просто посмотрел и вышел - не будет отказа.

Не расценивается ли такое решение как попытка манипуляции со статистикой? Накрутка пф, возможно?

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

Ответить
0

Зависит от того, что мы хотим видеть в статистике. Если мы хотим видеть нормальные посещения - не вижу никаких проблем. Насчёт накрутки: тут обратное - «скрутка» посещений. Едва ли она подлежит неким санкциям ПС.

Причин, по которым обязательно хочется видеть такие вот мусорные посещения я придумать не могу. Доя бизнеса такие посещения едва ли имеют смысл. Но техническую реализацию фиксации таких посещений сделать очень просто - собственными силами фиксировать посещение. И считать те, которые «не дождались» окончания загрузки всех скриптов.

Ответить
0

Да, конечно, "скрутка", манипуляция с аудиторией в общем)

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

Но:
1) скрипт влияет на все посещения и для реальных сократится время на сайте. То есть, если раньше пользователь заходил на 60 секунд, то после внедрения - 50 секунд. Не критично, пожалуй, но негативный эффект.

2) Написать отдельный скрипт для отлова коротких посещений и грузить его отдельно? В чем смысл ускорения тогда? :)

3) Как, при условии пропуска коротких сеансов оперативно увидеть накрутку негативных ПФ на сайт (например конкуренты крутят отказы на сайт). Не уверен что такой сценарий может быть (не сеошник - всех тонкостей могу не знать), но стараюсь предугадать, чтобы быть уверенным в подобном решении.

Спасибо

Ответить
1

Никита, скруткой мало кто занимается)), это дорого! Прокси нормальные (для Москвы допустим) стоят денег), бесплатные постоянно банятся ПС, ну а чужие посещения (из других регионов) лучше отсекать вообще, и перенаправить их на "заглушку". 

Ответить
0

Да, я понимаю, условному интернет магазину обуви из Тюмени никто скручивать не будет) Но если выделка стоит того?

По другим регионам: а если магазин делает отправки по всей стране? Или это, например, бренд авто? Условно, конечно.

Ответить
0

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

А учёт таких посещений может быть крайне простым: генерируйте идентификатор (обычный guid) при загрузке страницы, асинхронно бросайте его на свой бэк, а после окончания загрузки отложенных скриптов бросайте его снова. И бэк сможет вести статистику: сколько загрузок не закончились повторной отправкой идентификатора.

Вопрос только один: зачем вам эта цифра. Не представляю.

Ответить
0

Понял, то есть вы тоже склоняетесь к тому что отложенная загрузка просто очистит статистику от "мусорных" сеансов?

Ответить
2

Да.

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

И не слышал ни разу какого то особого негатива ни от кого

Ответить
1

Спасибо

Ответить
1

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

Ответить
0

стоит еще учитывать, что телеметрию Гугл получает не только от счетчиков аналитики, а еще и из самого Хрома

не буду утверждать, но, если эти данные будут значительно отличаться, шанс получить санкции есть

Ответить
0

Именно! То есть Google будет подозревать какой-то странный диссонанс в данных и сочтет их за попытку обмана.

Но с другой стороны - хочу я получать не точную статистику. Только реальные посетители, зачем мне в ней боты? Что в этом такого? Это моя статистика, а вы там меряйте что вам нужно с хрома или из выдачи.

Ответить
0

Гугл учитывает ТОЛЬКО живые данные в ранжировании. На них влиять невозможно практически.
Никакая синтетика не будет учитываться в ранжировании. Никем. Это тупик.
Надеюсь, это всем понятно.)

Ответить
1

То что показатели теста PageSpeed (а именно один из них - FCP) влияют на ранжирование уже статистически доказано. Вот исследование https://pro100blogger.com/2020/12/google-december-2020-core-update.html
Кроме того в личной переписке коллеги мне кидали примеры, когда удалось восстановить позиции сайта после оптимизации скорости.
Так что да - заниматься оптимизацией нужно, но разумно.
Ну и, пользуясь случаем, напомню что мы разработали WordPress плагин для отложенной загрузки счётчиков статистики, в том числе и Яндекс Метрики
 https://ru.wordpress.org/plugins/true-lazy-analytics/

Ответить
0

обновления в последней версии не смотрел,
оно все так же вешает загрузку аналитики на onscroll и теряет посетителей, который кликают сразу без скрола?

Ответить
0

Дмитрий, Вы можете стать контрибьютором этого бесплатного плагина и внедрить передовые технологии отложенной загрузки.

Ответить
0

Замените событие "scroll" на "mouseover" или "mousemove", например, зачем для этого контрибьютор? :)

Ответить
1

вот и я про то же)
пофиксить проблему времени займет значительно меньше, чем спорить

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

откладывать загрузку аналитики ради 100 попугаев в гугле, в принципе, можно, но я бы предпочел получать нормальные данные в аналитике

Ответить
0

На каждый продукт найдется свой клиент. Кому-то нужны попугаи за счет потери 3-5% точности в аналитике. Эти люди и воспользуются плагином.
остальные будут использовать скрипты аналитики в обычном режиме.

Ответить
0

Хочется разобраться до конца и делать выводы, использовать конкретное решение.

Ответить
0

В 2.2 так и будет. Просто мы с Дмитрием знакомы по другому чату. Поэтому он и задаёт вопросы по скроллу. 

Ответить
0

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

Я так понял из статьи, что на данный момент показатели скорости учитываются только для мобильного трафика:

 2 декабря 2020 года, как раз перед официальным запуском Декабрьского обновления алгоритма, Google официально признал, что LCP, FID и CLS являются факторами ранжирования, *но пока что только для мобильного поиска*.

Кстати, на графике показателей ранжирования скорость загрузи занимает суммарно ~15% (Desktop CLS, Mobile FCP, Desktop LCP) от общего результата, верно? Не совсем понятно где потерялся FID на графике, правда.

Интересно, 15% от ранжирования, это не так уж и много. Не мало, согласен, но 85% на остальном... хмм.

Интересно что в статье указано <1,5 секунды на FCP, при этом в документации (https://web.dev/first-contentful-paint/) до 2 секунд, а на калькуляторе зеленая зона до 2.3 секунд (https://googlechrome.github.io/lighthouse/scorecalc/). Кому верить? :)

Ответить
1

Я не знаю писал тут кто то или нет. Я делаю так: аналитика после отрисовки страницы. Не таймер, а именно после отрисовки. На моб.гуглспид это даёт +10%. Важнее для пользователя показать готовую страницу, без задержек на анализ скриптов. Ну а в целом, если вы хотите хорошие показатели, то нужно работать с кодом темы. Разработчики всегда немного не доделывают, оставляют нам немного. 

Ответить
0

Лучше не использовать тему :) а писать свою. Но все-равно, конечно, если в смете не заложена полная оптимизация загрузки, то ее не будет в проекте.

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

Ответить
0

Заголовок многообещающий, а на деле полезного 0.

Ответить
1

Прямо как ваш комментарий.

Ответить
0

Не согласен. Может мой комментарий увидят прежде, чем прочтут пост и не потеряют своего времени. 

Ответить
0

Не согласен. Ресерч полезный. Отвечает на вопросы:
1) насколько важна погоня за 100/100
2) почему сложно достичь зеленой зоны
3) и расписывает один из подходов для решения проблемы метрик.

Ответить
1

Про погоню было как раз в тех 1оо5оо статьях, что вы привели в начале.

Мне лично было интересно про отказы и не срабатывания счетчиков, но ответа в статье я не увидел. 

Ответить
0

Так почитайте комментарии. Это еще одна суть статьи - собрать эту инфу в одном месте.

Ответить
0

Имею сайт по проверке музыки на АП - https://eproves.com/
Делал сразу под отличное SEO и для UX использования удобного.
В результате получил оценки по Google Page Speed:
SEO 100/100 - сам прифигел, но там начинки много: микроразметка, h1-4, линкбилд хорошый
PageSpeed для ПК: 96/100 - не на что жаловаться
PageSpeed для Мобилы: 75/100, вроде бы хорошо, но Google Console ругается на отстающие метрики CLS & LCP.
Пошел значить "чинить", поправил все красные зоны, оптимизировал по максимуму, добавил прелоадеры для шрифтов и скриптов от Гугла.
Результат для Мобилы: упало до 60/100 (фейспалм).
Вернул назад, живу радостной жизнью.

Правда, нас "какого-то" до сих пор в поиске нет, сайту уже 2мес.
В Яндексе залетели всего за 2недели на 1 место по СЧ запросу: "проверить музыку на авторские права". Сейчас ухватили несколько ВЧ и масшатируемся дальше.
А Гуглу вообще пофигу, он ранжировать не собирается. Бросает где-то с 10 на 8 страницу поиска и назад...

Ответить
1

В результате получил оценки по Google Page Speed:

SEO 100/100 - сам прифигел, но там начинки много: микроразметка, h1-4, линкбилд хорошый

Микроразметка и заголовки и ссылки - не влияют на скорость загрузки сайта. Также, с точки зрения SEO у вас, на мой взгляд, не очень подходящие заголовки.

По поводу оптимизации, полагаю, что отложенная загрузка метрик, например GTM, и настройка шрифтов решит вопрос и можно будет добиться лУчшего результата.

 Правда, нас "какого-то" до сих пор в поиске нет, сайту уже 2мес.

Вы имеете ввиду что поисковые системы не проиндексировали сайт совсем? Или речь про ТОП10?

Если индексация - то нужно запросить индексацию в вебмастере. А по поводу ТОПа, то с таким возрастом сайта это не удивительно. Конечно все зависит от тематики сайта, но 2 месяца это слишком мало. Плюс объем сайта, супер-мелкий - в топе за подобный запрос бьются юридические форумы, информационные блоги - ваш сайт им проигрывает.

Ну и плюс, конечно же, слабая SEO оптимизация.

Ответить
0

Что скажете о блокировке скриптов для Гугл Бота?
Вот статья: https://qna.habr.com/q/701107

Ответить
1

Блокировать отдельно не рекомендовал бы. В частности Google собирает данные не только своим ботом, но и статистикой из браузеров пользователей (Google Chrome).

Боюсь что такой «маневр» не лучшим образом скажется на оценке, если вообще скажется. Или Google увидит реальные цифры у пользователей и примет их за основу, или заподозрит что-то неладное - а это уже не хорошо.

А вот вариант со скроллом или другими событиями очень даже имеет право на существование. Сейчас его тестируем.

Ответить
0

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

Ответить
0

Можно поподробнее? :)

Ответить
0

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

Ответить
0

Почему всегда приводят код просто с таймаутом, когда можно встроить метрику по комплексу событий так, чтобы влияние на статистику было минимальным? Например: комбинация таймаута и тачстарт/маусмув-события. 

Ответить
0

Кажется это уже есть в статье.

Ответить
0

Это Михаил Flat намекает, что в его плагине Flat как раз все это и реализовано. 

Ответить
0

А, понял, ссылки просто нет, но давайте не превращать обсуждение в рекламу плагинов.

1) можно это реализовать и без плагина (добавить обертку для кода метрик)
2) мы все таки хотим понять насколько это эффективно и не противоречит ли условиям установки, чтобы не получить обратный эффект.

Ответить
0

Считаю что не противоречит правилам.
А код можно добавить вручную. Я могу. Вы можете.
Только для многих вебов плагины - это удобнее. 

Ответить
0

Удобнее?) Может для тех кто не разбирается в коде)

Ответить
0

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

Ответить
0

Сомневаюсь что большинство pagespeed читает и понимает что к чему. Скорее видят оценку 40 и к разработчику - ускорять.

Ответить
0

Не намекаю, хотел бы написать - написал бы прямым текстом. Никакой рекламы, только обсуждение

Ответить
0

Менять можно, и нужно, более того - комбинировать. Погрешность можно снизить в подсчётах метрики вплоть до 0.5-1%

Такие проценты меняют суть? 

Ответить
0

Сбросьте ссылку в лс на ваш плагин. Он тоже на WP?

Ответить
0

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

Ответить
0

Кто знает, как от яндекс метрики оставить один вебвизор. Только сделать его не тормозящим сайт?

Ответить
0

Насколько я знаю - никак. Технически не реализуемо. Вебвизор - часть Яндекс.Метрики, а метрика - готовый продукт.

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

Ответить
0

Спасибо,все работает,pagespeed попросил уменьшить до 1500,и все ошибки исчезли.

Ответить
0

Куда это все бегут? А, в зеленую зону. Но бежать то надо не туда, а за записью в 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 получить запись "Не отвечает требованиям к основным интернет-показателям".

Ответить
0

Очевидно же. Origin Summary - это и есть общая оценка всех страниц у реальных пользователей.

А текущий пейджспид - оценка конкретной страницы эмулируя минимальные технические характеристики.

Ответить
0

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

Ответить
0

Безусловно, но как тестировать решения без эмуляции?

Ответить
0

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

Ответить
0

То есть идти в слепую? Эмуляция создана для того чтобы тестировать разные решения. В противном случае тестирование затягивается по времени на месяца.

Ответить
0

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

Ответить
0

Ааа)) теперь все стало понятно)))
loading.express выдает примерно те же оценки что и pagespeed :)

Пример - Summary выдает CLS = 0.3 (откуда ему там взяться?)
В pagespeed - 0

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Frubika.com.ua%2Fblog%2Finternet-magazin-na-prom-ua-bystryj-start-ili-nevygodnaja-arenda&tab=desktop&hl=ru

В loading.express - 0.16

https://loading.express/?test_id=603403117709443190077aa1&server=kiev-1-monitor

В чем изюм?
Информацию что именно эта страница и другие из группы выдают высокий CLS берется из консоли. На главной CLS выше из-за анимации - но он не выше 0.1 и на мобильных она отключена.

Ответить
0

Я предполагаю, что сейчас эта метрика переживает какое-то обновление и она сломана. Даже lighthouse дает 0 CLS

Ответить
0

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

Ответить
0

CLS отчасти зависит от скорости интернета, впрочем как и другие метрики и скорость загрузки сайта в целом, что логично и очевидно.

Проверять на конкретном компьютере смысла нет, с подключением в 100мб/с и core-i7 11th. Поэтому ценность данного расширения стремится к нулю.

CLS зависит от подключаемых в документе стилей, скриптов и других внешних ресурсов, которым не выделено заранее место на странице, тем самым провоцируя СДВИГ (shift) верстки (layout).

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

Ответить
0

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

Ответить
0

Более профессиональный подход - открыть консоль разработчика в хроме, вкладка Network, и на ней задаете скорость. Не благодарите.

А на телефоне у меня LTE, тоже не на малой скорости, и 3g в больших городах быстрый. Плюс ругается он на десктопную версию, а не на мобильную.

А core-i7 чем заменить? Рекомендую вам, прежде чем комментировать что либо, сперва ознакомиться с темой, изучить мат.часть, так сказать.

Ответить
0

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

Ответить
0

🤦🏻‍♂️ хорошо 🤣

Ответить
0

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

Ответить
0

Во-первых, все зависит от сайта (изменения делали? Кеш есть?), сервера (его загруженности), и доугих параметров, так что сказать наверняка сложно.

Во-вторых, не об этом ли я писал выше????
https://vc.ru/185898?comment=2515365

Ответить
0

Все таки апдейт у них. Они стали проводить измерение при подключении по 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 выросли на несколько пунктов."

Ответить
0

Отлично! Значит я оказался прав))) вчера не проверял блог и пока не было времени разбираться с нововведениями, но спасибо за наводку.

Ответить
0

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

Ответить
0

👍🏼

Ответить

Комментарии