Чем нужно проверять скорость загрузки сайта: немного бэкэнд-теории для маркетологов

16.12.2021

Стоит ли гнаться за ачивками Google PageSpeed Insights? Зависит от того, почему вам важна скорость загрузки сайта

Медленная загрузка веб-сайта может иметь гораздо более серьезные последствия, чем недовольство пользователей и хейт в соцсетях. В случае с интернет-магазинами низкая скорость загрузки напрямую влияет на конверсию и выручку: по данным Unbounce, около половины потребителей уйдут с веб-сайта после 2,3 секунд ожидания, а если и останутся, то будут менее склонны совершить покупку. Более трети больше никогда не вернутся.

Ок, мы все поняли — скорость загрузки важна для удержания, конверсии и лояльности. И первое, что сделает человек, который хочет проверить, все ли у него в порядке со скоростью, — это посмотрит на баллы в Google PageSpeed Insights: логично, что нет причин не доверять интернет-гиганту, который определяет, насколько высоко будет находиться веб-сайт в поисковой выдаче. Казалось бы, раз вы в зеленой зоне, то и волноваться не о чем. Можно, конечно, для верности воспользоваться другими известными сервисами, среди которых, к примеру, Gtmetrix или Sitespeed — и результаты либо дополнительно успокоят вас, либо заставят задуматься, почему картина совершенно другая. А как на самом деле на стороне пользователя — страницы загружаются быстро или нет? Заглянем под капот, чтобы понять, что измеряется при оценке скорости загрузки, как устроены эти сервисы и что влияет на результат.

Зачем-таки спрашиваете?

Важный уточняющий вопрос: почему конкретно вам нужна высокая скорость загрузки?

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

Второй вариант: вы отвечаете не за SEO и трафик, а за выручку, юнит-экономику или развитие продукта. Тогда для вас задержки при загрузке выливаются в недополученную прибыль: после третьей секунды ожидания загрузки каждая дополнительная секунда — это потеря 7% конверсии. А если ваш сайт высоконагруженный, работает на большой территории, а в вашем бизнесе высокий средний чек, то такое положение дел должно вас расстроить. Вам важнее всего знать, что не Гугл, а пользователи считают ваш сайт быстрым и не уходят.

Поэтому если вы SEO-специалист или маркетолог, логично ориентироваться на Google PageSpeed Insights, как мерило, навязанное вам самим Гуглом: вы же все-таки играете на его поле. И как только сайт дотягивает до зеленой зоны, кажется, что можно расслабиться и пооптимизировать что-нибудь еще, чтобы улучшить общий результат. Однако нередко вы можете оказаться в ситуации, когда показатели в Google PageSpeed Insights выглядят отлично, но отказов все равно много, а пользователи жалуются, что скорость низкая. Эффект уже может выражаться в потере реальных рекламных денег. Например, это приводит к неэффективному расходованию рекламных бюджетов: если рекламные системы списывают бюджет за клик, то посетитель, который не дождался загрузки веб-страницы и ушел с сайта, даже не познакомившись с товаром, уже стоил компании потраченных на его привлечение денег.

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

Так в чем дело?

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

Один из ключевых факторов, влияющих на скорость доставки данных с сервера, — длина сетевого маршрута от источника до устройства конечного пользователя. Чем ближе данные к пользователю с точки зрения топологии сети (географическое положение на это влияет косвенно), тем выше скорость загрузки. Конечно, кроме этого на скорости доставки сказывается качество «последней мили», но это уже совсем другая история, происходящая вне нашего участка ответственности.

То есть, если, скажем, онлайн-магазин хостится на сервере в московском ЦОДе или на одном из узлов AWS в Европе, то запросу из Хабаровска на пути к серверу оригинации придется преодолеть множество «хопов» — промежуточных переходов, через которые должны пройти данные. На каждом из них возникнет некоторая задержка, и то же самое случится на обратном пути. Чем больше этих хопов, тем медленней доставляется контент и тем медленней будет грузиться страница веб-сайта. То есть, централизация инфраструктуры может «удлинить» маршрут доставки трафика для части, если не для всех, пользователей. И даже если передачу этих данных обеспечивает только одна сеть оператора связи, то физическая передача данных на расстояние, например, из Амстердама до Хабаровска, потребует больше времени, чем в случае, если тот же файл был бы загружен из Москвы, или тем более, из Владивостока.<

Как оценивают скорость загрузки известные сервисы?

Синтетические тесты скорости загрузки, к которым также относится Google PageSpeed Insights, имеют свои нюансы, и, как всегда бывает с синтетикой, предлагают некую усредненную картину, которая соответствует реальной в той мере, в какой портрет «виртуального» посетителя по версии сервиса отображает реальные характеристики вашей целевой аудитории. Например, в Ping Admin запросы исходят не от реальных пользователей, а от серверов, размещенных в ЦОДах самого сервиса. Pingdom и GTmetrix не учитывают ограничения по скорости подключения и качеству последней мили, а также тестируют опыт с довольно мощных по производительности устройств.

Как устроена сеть синтетических «пробников»:

Что касается алгоритма Google PageSpeed Insights, он по умолчанию эмулирует статистически усредненный опыт взаимодействия с сайтом в глобальном масштабе — с мобильного устройства со сниженной производительностью процессора в сети 3G. Вероятнее всего, замер будет производиться из европейской локации, и чем дальше это положение от серверов, на которых развернута инфраструктура веб-ресурса, тем меньше может быть итоговый результат замера. Совпадет ли это с условиями, в которых реально находится ваш посетитель — большой вопрос.

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

Как заморочиться и проверить достоверно?

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

Мы замеряем скорость загрузки с точки зрения реального пользователя при помощи сервиса, который называется Real User Monitoring (RUM). Тестируя скорость, мы обязательно следуем двум правилам: тестируем под нагрузкой (то есть количество обрабатываемых в ходе тестирования запросов превышает сотни тысяч), чтобы обеспечить репрезентативную выборку, а также учитываем максимально приближенный к реальному опыт использования.

Источник данных для RUM-тестирования — это скорость на стороне «живых» пользователей. На популярной странице веб-ресурса, скорость которого мы хотим проверить, размещается JS-скрипт, который при обращении получает от нас задания на скачивание тестовых объектов, выполняет их и отправляет тайминги загрузки для анализа. Погрешность замера не превышает миллисекунды, так как мы используем Resource Timing API. RUM умеет одновременно замерять скорость доставки данных из нескольких источников — так можно сравнить скорость доставки для пользователей в различных регионах, использующих различные десктопные и мобильные платформы, а также сравнить скорость доставки нескольких CDN-провайдеров или оценить, нужно ли отказываться от собственной инфраструктуры в пользу облачной.

Как устроен Real User Monitoring:

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

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

Получив все сырые данные, мы можем сформировать отчет о скорости доставки в различных разрезах: например, по субъектам РФ, по сетям интернет-провайдеров, по устройствам пользователей, по различным CDN. В частности, можно увидеть, как быстро резолвится доменное имя, как быстро обрабатывается запрос, как быстро загружается тестовый объект с точки зрения реального пользователя в различных браузерах и на различных устройствах — и на основе этих данных увидеть, есть ли возможность улучшить показатели. Это мы делаем бесплатно для всех, кто решил протестировать нашу платформу для ускорения доставки контента — после перевода трафика на облачную платформу мы в течение двух недель «в бою» анализируем различные показатели, влияющие на скорость загрузки веб-страниц, а также тестируем, могут ли какие-либо из сервисов улучшить показатели (например, сервис автоматического преобразования в webp).

Что делать с этим дальше?

В завершении несколько рекомендаций всем, для кого скорость загрузки веб-страниц не пустой звук. Прежде всего, если вам важно получить высокий балл в Google PageSpeed Insights, поработайте с кодом/контентом веб-страниц:

• Сжимайте JS- и CSS-скрипты

Например, при помощи алгоритма сжатия данных Brotli — он способен на 20% эффективнее сжимать текстовые файлы по сравнению с deflate.

• Используйте оптимизацию изображений

Сжатие в формат webp позволит в сократить «вес» тяжелых изображений в среднем на 30% без видимых человеческому глазу потерь (а в некоторых случаях и больше), к тому же алгоритмы поискового ранжирования Google любят сайты, где используется этот формат. Однако помните, что часть устаревших браузеров не поддерживает webp. Мы научились производить конвертацию в webp в облаке и отдавать сконвертированный в webp файл тем устройствам, чьи браузеры поддерживают формат, а остальным — несконвертированное изображение. Об этом кейсе писали здесь.

• Делайте выбор в пользу inline-стилей

Это непременно отразится на баллах в Google PageSpeed Insights.

• Используйте алгоритмы отложенной загрузки

Делайте выбор в сторону lazy-loading: если что-то, особенно обширный каталог изображений, можно подгружать в отложенном режиме, лучше это сделать. Отложенную загрузку также стоит применять в отношении стороннего контента — это скрипты чат-ботов, карты Google/Яндекс и прочее.

Если для вас высокий балл в Google PageSpeed Insights — это круто, но не решает всех проблем с загрузкой, то необходимо работать над оптимизациями как фронтэнда, так и инфраструктуры. Чем более географически распределена аудитория вашего веб-ресурса, тем менее релевантны показатели PageSpeed.

Какие улучшения со стороны инфраструктуры ускорят ваш веб-сайт?

• Перейдите на HTTP/2

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

• Используйте CDN

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

• Используйте распределенный DNS

Если использовать географически распределенную инфраструктуру для размещения DNS-зоны, то доменное имя быстрее резолвится в точке присутствия, расположенной ближе к источнику запроса, а это позволяет выиграть порой до нескольких сотен миллисекунд к скорости обработки запроса. Бонус — дополнительная отказоустойчивость, которую не может дать регистратор.

В итоге

Нужно ли воспринимать высокий балл в Google PageSpeed Insights как однозначную победу и любыми способами достигать желанной “зеленой зоны”? Зависит от вашей первостепенной задачи как специалиста. Но однозначно делать из этого Священный Грааль не стоит — есть множество условий, влияющих на пользовательский опыт и недоступных для замера исключительно синтетическими метриками: например, производительность устройства, качество сетевого соединения, географическое положение посетителя. Если веб-ресурс крупный и охватывает аудиторию всей страны от Калининграда до Владивостока, замеры PageSpeed с точки зрения скорости загрузки веб-страниц вам ничего конструктивного не дадут. В этом случае тестируйте под нагрузкой для различных условий, в которых могут быть ваши реальные пользователи, и принимайте решения о том, может ли ваша инфраструктура дать достаточную скорость для оптимального пользовательского опыта.