Урок 24: Выявляем и устраняем проблемы скорости загрузки (19 мин.)

КОНСПЕКТ УРОКА:

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

После того, как пользователь ввел в адресную строку браузера url, или перешел по ссылке, или кликнул на закладку:

1. Браузер отправляет запрос с именем сайта на ns-сервер и получает в ответ ip адрес сервера с сайтом.
А так же проверяет наличие сайта в "черных списках". Это занимает некоторое время.

2. Далее браузер запрашивает контент страницы на сервере хостинга. На сервере происходит предварительная обработка запроса до того, как будет отдан контент страницы браузеру.
Например, это может быть 301 редирект... На этом этапе может пройти несколько процедур (в соответствии с правилами в .htaccess и некоторых других файлах) прежде, чем сервер сформирует контент страницы и передаст обратно браузеру. Позже это рассмотрим подробнее. Это тоже занимает время.

3. Браузер получает контент страницы, распарсивает его, обрабатывает и подгружает дополнительный контент частей страницы (часто с других серверов). И только после того, как браузер собрал контент страниц из многих кирпичиков - на экране у пользователя появляется изображение страницы сайта, на которой всё отрисовано и с которой посетитель может взаимодействовать. Это сейчас самый долгий этап в загрузке сайта.

Проверяем скорость загрузки сайта и время загрузки страницы

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

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

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

Скорость загрузки страницы по Lighthouse в Google Chrome

Запустите инструмент Lighthouse в Google Chrome. Для этого нажимаете F12 и открывается "панель разработчика". Здесь выбираете пункт Lighthouse и запускаете "отчет". В результате вы получите общие параметры по быстродействию текущей страницы, на которой вы запустили lighthouse.

По кнопке "View Original Trace" вы можете посмотреть, что происходило на этапе обработки кода страницы браузером. Вот вы видите первый блок графика, это маленький скриншотик того, что было на экране пользователя. Видно, что до двух секунд на экране не было изображения.
Потом изображение появилось, но здесь видно, что большая картинка появилась не сразу, а только еще через пол секунды.
Только в этой точке, в браузере полностью отрисовано изображение страницы. Это заняло почти три секунды.

Напомню вам, что Google последние годs считает крайне важным параметры, связанные с пользовательским опытом:
- насколько людям удобно и на мобильных телефонах;
- насколько безопасно (защищенный протокол https);
И здесь, на нижнем графике, отмечены основные точки, которые входят в Core Web Vitals - важнейший параметр ранжирования с этого года на Google.

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

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

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

Вот в на экране вы видите, что самый большой скрипт, который съел больше всего времени загрузки, это скрипт Яндекс Карт.
Второй по тяжести скрипт - это скрипт Яндекс Метрики.
Вот эта библиотека - тоже Яндекс.
И следующее - это опять что-то от Яндекса.

Потом по тяжести идет код Google Analytics.

Т.е. все тяжелые скрипты, которые делает долгой загрузку данной страницы и работают на понижение ее в поиске: это инструменты от Google и от Яндекса.

Поэтому я убрал большую часть из этой страницы, а загрузку карт пришлось переписать.

Скорость загрузки страниц сайта по Google Search Console

Теперь переходим в Google Search Console, где вы уже зарегистрировались и начинаем смотреть показатели нашего сайта.

Переходим в раздел "Основные интернет показатели".

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

Тут вы можете открыть отчеты и посмотреть это все более подробно, в том числе, с указанием какой именно параметр вызвал проблему и почему Google посчитал данный адрес неэффективным.

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

Ещё одна проблема, менее значимая - интерактивные элементы страницы становятся кликабельными более чем через одну секунду после начала загрузки. Т.е. для Google этот порог - одна секунда после начала загрузки.

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

Скорость загрузки страниц сайта по Яндекс Вебмастер

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

Скорость загрузки страниц сайта по Яндекс Метрике

В Яндекс Метрике можно посмотреть подробно по всем страницам вашего сайта все основные параметры по скорости загрузки:
- DNS время ответа сервера, который отдает ip адрес (но это, обычно, не значительное время);
- время редиректов (мы по этой теме пройдемся подробно в конце урока);
- "продолжительность установки соединения" (обычно достаточно быстро) ;
- "ответ сервера" - через какое время браузер пользователя получает HTML код страницы от сервера;
- "время загрузки и парсинга HTML" кода;
- "время до отрисовки контента";
В принципе те же параметры, что и у Google. На них можно ориентироваться, находя самые медленные страницы с которыми нужно работать.

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

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

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

Скорость загрузки страниц сайта по Google Analytics

Перед вами таблица параметров скорости загрузки страниц от Google Analytics. Здесь есть примерно те же параметры:
- средние время соединение с сервером;
- по странице - среднее время ответа сервера;
- среднее время загрузки страницы в секундах;
- и среднее время до возможности взаимодействовать со страницей.

Как видите, почти 4.5 секунды до возможности взаимодействовать со страницей - это плохо.
И среднее время до полной загрузки контента.

Также для себя я держу в этой табличке:
- среднее время посетителей на странице;
- средняя длительность сессии;
- среднее количество просмотров страниц за сессию.

Т.е. это такой основной дашборд, чтобы быстро видеть, что происходит на сайте.

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

И вот пример: в какой-то момент стало существенно расти среднее время реакции сервера. Как вы видите, оно стало расти просто катастрофически, в результате чего стали падать позиции сайта. Показатель Google Lighthouse был крайне низкий, вот тут 49.

В результате я выяснил проблему: движок сохранял на сервере логи всех действий всех пользователей на сайте. В базе логов стало слишком много записей. Движок базы данных стал тормозить, так что отвечать стал очень медленно. Пришлось почистить логи и изменить программную логику фиксации поведения посетителей. В результате время реакции сервера существенно снизилось и стало в два - три раза ниже, чем раньше. А показатель быстродействия по Google Lighthouse вырос почти в 2 раза. Позиции все вернулись и даже подросли.

Скорость загрузки страниц сайта по Google PageSpeed Insights

Ещё один инструмент покажу: из Google Analytics, раздел "скорость загрузки сайта - ускорение загрузки" можно перейти в предложение ускорения от PageSpeed Insights. И можно перейти сразу по этой ссылке.

Google Lighthouse показывает скорость загрузки по расчету на модели устройства.
PageSpeed Insights показывает данные на основе реальных данных посетителей вашего сайта из браузера Google Chrome.

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

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

Редиректы и скорость загрузки страницы

Последняя тема урока: редиректы и время загрузки сайта.

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

Т.е. здесь у нас 8 вариантов, каким может быть адрес одной и той же по контенту страницы - в зависимости от протокола HTTP и HTTPS, наличия WWW и index.html
Как посетитель вы не видете это множество редиректов.
В данном примере такое количество редиректов между этими страницами связано с тем, что сайт старый и его много раз правили. При заходе пользователя или робота поисковой системы на эту страничку происходит первый редирект... И только в результате 4 редиректа контент страницы отдается сервером браузеру пользователя.

Этот график построен с помощью инструмента Redirectdetective. Вы можете воспользоваться им бесплатно. Рассмотрим эти редиректы.

Этот редирект реализован на уровне CMS (Content Management System). Изначально было прописано, что если пришел запрос на страничку с адресом без WWW, то редиректить на эту же страницу, но с WWW

Позже, вот здесь, при переводе сайта на защищенный протокол HTTP в .htaccess был прописан редирект всех страниц, по которым пришел запрос по незащищенному протоколу HTTP на адрес с протоколом HTTPS.

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

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

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

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