Здравствуйте, дамы и господа, сегодня давайте поговорим о том, как скорость сайта влияет на ранжирование сайта в поиске. И сразу объясню распространённые ошибки некоторых SEO-специалистов, которые наивно полагают, что скорость сайта подсчитывается по инструменту PageSpeed Insight.

Кстати, прилагаю видеобзор, где демонстрирую наглядно, как пользоваться инструментами для проверки скорости.

Как подсчитывается скорость сайта у Google и Яндекс

Итак, давайте приступим к аналитике проблемы. Предположим, есть у нас популярный запрос «растровая графика».

Запрос "растровая графика" в Google
На запрос «растровая графика» получили такой блок.

Давайте прямо перейдём по ссылке в блоке-ответе, который у нас стоит выше даже Википедии по факту. Что видим?

Результат для мобильных платформ в PageSped Insight
Для мобильных платформ
Результат для десктопных платформ в PageSped Insight
Для десктопа

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

А теперь давайте перейдём в режим разработчика на Google Chrome и проверим реальные показатели сайта (можете работать так с любым сайтом, в том числе и своим):

  1. Откройте браузер Chrome. Работаем под Google, так что не поленитесь скачать.

  2. Откройте нужную страницу в браузере.

  3. Нажмите F12, чтобы перейти в режим разработчика.

  4. В появившемся окне перейдите на вкладку Perfomance.

Нас интересует скорость загрузки страницы, так что нужно запустить с помощью сочетания клавиш Ctrl+Shift+E запись загрузки страницы.

Консоль разработчика в Google Chrome
Вкладка Perfomance консоли разработчика в Chrome

Нажмите эти клавиши одновременно. И ждите, пока проверка будет окончена.

Результат тестирования сайта

Стрелкой отметил событие, которое нас интересует. Это полная загрузка DOM, по сути, в этот момент происходит событие DOMContentLoaded, которое происходит после полного парсинга HTML. Сложновато? Давайте проще.

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

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

Событие Onload на вкладке Perfomance
Буквой L отмечено событие Onload

Это у нас Король Тормозов! VK API, вот и видим, что он сработал на отрезке 4,6 секунд, так что с точки зрения синтетики, сайт очень медленный. С точки зрения посетителя, грузился всего полсекунды.

Настройки для имитации медленного соединения

Если хотите проимитировать допотопный смартфон с очень плохим интернетом, нажмите в этом инструменте в правом верхнем углу малозаметный винтик, а потом выставьте настройки:

  1. Network: Slow 3G.

  2. CPU: 4x slowdown.

  3. Снова нажмите Ctrl+Shift+E.

На этот раз событие DOM произошло через 6 секунд, но тормоза остались те же. Только на этот раз место короля заняло Facebook API.

Медленная загрузка Facebook и VK API

При этом заметно, что они на 1,5 секунды отсрочили загрузку DOM. Для скриптов с асинхронной загрузкой такое возможно, так что, лучше эти тормоза нещадно выпилить. Либо отложить их загрузку на потом с помощью тега defer, ибо вперёд DCL они вставать точно не должны. Разве что могут грузиться параллельно основному потоку.

Результаты в PageSpeed Insight

Собственно, на этом результате мы как раз таки видим, что какой-то завалящий скрип грузится очень поздно, это может быть вызвано причинами, не зависящими от сайта. Например, если VK отдал данные с запроса по API с опозданием, то можем увидеть, как нужный скрипт придёт на 5-10 секунд позже, чем случится даже крайне тормозное событие Onload.

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

А теперь пора перейти к самым важным вопросам. А как поисковики замеряют реальную скорость веб-ресурса?

Как поисковики определяют скорость сайта

Кстати, у Яндекс тоже недавно подъехал индекс скорости сайта. Почитать подробнее о нём можете по ссылке: https://yandex.ru/support/webmaster/service/site-quality.html#site-quality__stat.

Индекс скорости сайта в Яндекс Вебмастер

Пока что не до конца ясно, как и на что он влияет, но Яндекс сообщили, что замеряться он будет на основе показателей Яндекс Браузера при переходе из мобильного поиска. Соответственно, скорее всего на мобильную выдачу влиять будет, если нет турбо-страниц у сайта. Да, Яндекс начал довольно жёстко продвигать свою технологию.

У Google ситуация практически та же, но информацию приходится собирать по крупицам. Но точно помню: представители компании заявляли, что PageSpeed Insight не влияет на ранжирование сайта. И это правильно, ориентироваться на синтетический тест — затея сомнительная. Так что можно на пузомерки не ориентироваться.

Ну а как тогда измеряют скорость страниц сайта Google? Например, можно найти вот такую запись: https://developers.google.com/web/updates/2018/07/search-ads-speed.

И пролистав пониже, можно увидеть такую вот сноску.

Как Google измеряет реальную скорость страниц

Если перевести, то значить будет примерно следующее:

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

Я перечитал некоторые другие заметки, а также во время выступления представители компании сообщали примерно то же самое. Данные берутся из самого популярного браузера — Chrome. На мобильных платформах он также присутствует, потому сделать статистику проблем не составит.

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

Как видите, реальные инструменты, на которые ориентируется Google и Яндекс, синтетическими тестами не являются, потому портить сайт ради зелёной зоны в PSI не стоит. Важнее оптимизировать реальную загрузку и убрать такие вещи, как счётчики и API, которые встают вперёд загрузки DOM, лишние скрипты, заняться оптимизацией изображения.

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

Не гонитесь за циферками

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

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

На PageSpeed Insight или GTmetrix не ориентируются от слова совсем. Так что если сайт реально долго грузится, событие DOMContenLoaded на нормальной машине происходит не через 1-1,5 секунды, а через 3-4, тогда есть над чем поработать.

На этом с вами прощаюсь, желаю успехов!

Нажмите для оценки!
[Оценило: 1 Средний: 5]