(!) Изначально у нас не было потребности сделать максимально точное исследование. Мы хотели просто свести два значения в виде графика и преподнести простые выводы с цифрами.
Но закончив это исследование, мы поняли, что будем делать повторное, с другими акцентами, показателем и значениями, так как тему можно хорошо сегментировать и получить отличающиеся данные.
Конечно это не отражает тех случаев когда сайт не загружается совсем и человек уходит, такие данные можно собрать только на уровне браузера, хотя у метрики эти значения вроде как и есть.
Так что в данном случае речь пойдет в основном про скорость загрузки сайта, когда сайт вообще загружается и работает.
Методика: Мы взяли значения из метрики о проценте отказа при переходе из ПС и связали с данными о скорости загрузки страниц, измеряемым разными методами.
Напомним, что такое отказ (ym:s:bounceRate) — Доля визитов, в рамках которых состоялся лишь один просмотр страницы, продолжавшийся менее 15 секунд (опционально больше), а так же не зафиксировано служебное событие «неотказ».
Методы замеров из метрики были взяты следующие:
ga:pageLoadTime — Время загрузки страницы с момента перехода на нее до полной загрузки страницы в браузере.
ga:domainLookupTime — Время, потраченное на отработку запросов к DNS-серверу при загрузке страницы.
ga:pageDownloadTime — Время, которое было затрачено на загрузку страницы.
ga:redirectionTime — Время, потраченное на отработку HTTP-переадресации при загрузке страницы. Если HTTP-переадресация не производилась, то значение данной метрики равно 0.
ga:serverConnectionTime — Время, в течение которого браузер ожидал подключения к HTTP-серверу при получении содержимого страницы. На этот параметр влияют задержки в сети, а также степень загруженности сайта.
ga:serverResponseTime — Время, в течение которого передается ответ с содержимым страницы от HTTP-сервера к браузеру. На этот параметр влияют скорость генерации ответа веб-сервером, размер страницы и скорость интернет-канала между посетителем и веб-сервером.
- ga:domInteractiveTime — Время, которое требуется браузеру для обработки объектной модели документа (DOM), включая время на подключение пользователя к серверу.
2,3,4,5,6 метрики — это отдельно взятые этапы процесса.
1 метод — указывает на самую полную загрузку от и до.
7 метод — указывает время от начала перехода, до момента когда можно взаимодействовать со страницей.
В качестве напоминания вот картинка с инструкции Яндекса
В анализе участвовало более 8.1 млн страниц на которые идет трафик с поисковых систем и отказы считались с этого трафика.
**Я буду прикладывать 4 графика. **
-
Первый: Приближенные значения
-
Второй: Добавлен вывод исходных данных зелеными точками.
-
Третий: по X вектору увеличено расстояние (значение на большем отрезке времени)
-
Четвертый: График построенный уже по средним значениям.
ga:pageLoadTime — Время загрузки страницы с момента перехода на нее до полной загрузки страницы в браузере.
И что же мы видим для метрики «с момента перехода на нее до полной загрузки страницы»?
- Резкий скачек с 0 до средних 25% в первую секунду.
С чем связано? да скорее всего это случайно открытые страницы и тут же закрытые, да и на самом графике значение в первую секунду очень сильно прыгает с 5% до 20% на каждом шаге, что говорит о хаотичности.
-
Далее 1-8 секунды она достаточно стабильно держится на значении 25%.
-
К 15 секунде растет с 25-30% до 45%.
Дальше данных становится не так много, опять же по причине 15 секундного значения в самом факторе отказа, но видим в пике оно достигает в среднем не выше 60%. Хотя как раз из за лагов, скорости загрузки итп — время отказа может и быть более 15 сек.
Вывод: Гнаться за сверх высокой скорости загрузки — фанатизм. Что ваш сайт загружался 2 секунды, что 8 — люди ждут загрузки контента, он им нужен.
Вот когда они ждут уже более 10 секунд — тут они уже начинают думать что этот сайт «тормозит и не работает» и что им быстрее открыть соседний сайт на выдаче.
ga:domainLookupTime — Время, потраченное на отработку запросов к DNS-серверу при загрузке страницы.
Тут мы наблюдаем вполне ровный тренд на рост. Стартует он с 12% на первой секунде и стабильно растущий до 35% на 15й.
Что вполне логично, если ДНС сервер не отвечает долго, то все это время юзер не видит контента у себя на странице, даже процесса загрузки не видит. Он видит белый лист. И тут уж ему более очевидно что контент никуда к нему не движется.
ga:pageDownloadTime — Время, которое было затрачено на загрузку страницы.
А вы сильно любите сжимать код страницы, минимизировать JS и CSS файлы?
А пережимать фото и внедрять webp?
Если да, то борьба идет в пределах первых трех-четырех секунд в рамках загрузки файлов за разницу в 10%.
Процент отказа растет с 20 до 25%, а после достигая 35% по большому счету идет на спад.
Вероятно в этот момент юзеры принимают решение уходить или оставаться, либо уже понимают какого рода контент их ждет и возможно уходят не получив полной картины либо уже читают текст, без особой необходимости дождаться фото либо интерфейса.
ga:redirectionTime — Время потраченное на отработку HTTP-переадресации при загрузке страницы.
Самый показательный график: время ожидании переадресации.
Та же история что и с DNS. Люди переходят, сервер говорит что надо переадресовать, но тормозит.
В итоге юзеры смотрят в белый экран загрузки и понимают что контент им не торопятся отдавать.
Стандартные 15-20% отказов в первую секунду (миссклик?) и далее рост до 75% в пике на шестой секунде.
Конец терпения достигает у большинства где-то на 10-12 секунде.
ga:serverConnectionTime — Время, в течение которого браузер ожидал подключения к HTTP-серверу при получении содержимого страницы.
Удивительно, но люди и тут терпеливы. С 15% до 25% значение растет за 10 секунд ожидания. Вероятно потому что все нетерпеливые отсеиваются еще на этапе тормозящих ДНС и Редиректах, либо потому что в целом это не очень частое явление.
Опять же, сайты что не доступны — на некоторое время выбрасываются из топ позиций поисковых систем, а потом после восстановления возвращаются. Вероятно это минимизирует сильные потери в этом значении.
ga:serverResponseTime — Время, в течение которого передается ответ с содержимым страницы от HTTP-сервера к браузеру.
Аналогично предыдущему графику, судя по всему не так сильно людей тревожит этот этап загрузки. Хотя по факту в этот момент они так же все еще не получали контент. Возможно и правда все нетерпеливые уже уходят на предыдущих этапах?
ga:domInteractiveTime — Время, которое требуется браузеру для обработки объектной модели документа (DOM), включая время на подключение пользователя к серверу.
Самый сок, как и первый график.
Если не брать в расчет первые секунды, где данные просто хаотичны и скачут с 15% до 75%, то в целом картина такова, что с 2 секунды получения контента и до аж 20й секунды — в среднем отказы держатся в пределах 15%.
Отдаете контент не 3 секунды как конкуренты а за целых 1.2сек? Да всем плевать. Лишь бы не более чем через 10 секунд вы начали отдавать контент юзерам.
Вывод: Любая крайность это плохо. Увлекаться и пытаться сделать скорость загрузки на 10% быстрее и выиграть тем самым 0.3 сек потратив кучу времени? Ну делайте, если вам этим приятно заниматься и вы не наносите тем самым ущерб чему то другому.
Но и медленный сервер, который начинает отдавать контент спустя десяток секунд никто терпеть особо не будет.
Скажу по своему опыту, если я получаю контент в течение 3-4 секунд, у меня и мысли не будет что сайт слишком медленный или тормозной, а разницу с загрузкой сайта в 1 секунду я и не замечу.
Опять же, у вас не будут покупать только от того, что вы грузитесь на 1 секунду быстрее конкурента. На это смотрят только фанатики ускорения сайтов. И любители культа Google PageSpeed текста, почему-то считающие что это фактор ранжирования.\n\n
