Электронная коммерция: восприятие скорости веб-сайта имеет значение

Опубликовано: 2017-05-25

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

В одном тематическом исследовании, проведенном SOASTA, утверждалось, что повышение скорости загрузки мобильных страниц увеличило коэффициент конверсии более чем на 25%. В своем постоянном стремлении поставить пользователя на первое место Джефф Безос, основатель и генеральный директор Amazon, как известно, одержим скоростью загрузки страниц и постоянно побуждает своих сотрудников снижать скорость загрузки страниц веб-сайта Amazon.

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

Существует множество инструментов, которые помогут вам повысить скорость веб-страниц, таких как Yslow или Google Pagespeed Insights, а также различные передовые методы, такие как минимизация и слияние css и js, использование спрайтов css и минимизация сетевых запросов. разработчик внешнего интерфейса должен следить за тем, чтобы скорость страницы была максимальной.

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

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

Есть некоторые вещи, которые вы не можете контролировать, такие как задержка в сети или скорость мобильного соединения, поэтому существует предел тому, чего можно достичь с необработанной скоростью страницы. В 3G-соединении где-то между 600 мс и 1 с потребляются обязательные сетевые накладные расходы, с которыми вы ничего не можете поделать. Исходя из желаемого времени загрузки страницы в 2 секунды, это дает нам всего 1 секунду для экспериментов. Это не очень много.

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

Однако в этой статье мы не будем обсуждать, как ускорить загрузку вашей страницы. Есть много статей об этом, и все они немного технические.

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

Конечно, восприятие — это то, что имеет наибольшее значение для пользователя.

Нажми, нажми, купи: тенденции электронной коммерции 2021 года, обусловленные DTC, мобильными и социальными сетями

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

Скорость сайта: первые впечатления

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

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

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

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

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

Этот тест был запущен на симуляторе iPhone 6 при хорошем 3G-соединении и отключенном кэшировании. После того, как страница была первоначально загружена, я инициировал жесткое обновление.

Чуть более чем через 600 мс у меня что-то начинает загружаться с моим именем в заголовке. Вы также заметите, что было сделано только 6 сетевых вызовов и загружено 5 ресурсов (3 файла css и 2 изображения).

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

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

Менее чем за 2 секунды у меня появился новый раздел с важным контентом.

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

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

Теперь давайте посмотрим на веб-сайт, который делает это не так хорошо. Этот тест был проведен с использованием тех же инструментов и скорости сети, что и предыдущий тест Amazon. Хотя сайт Charles Tyrwhitt отдает приоритет некоторому контенту, можно сделать гораздо больше, чтобы приблизиться к оптимизации Amazon.

Я не вижу никакого контента почти 7,5 секунд. У меня сразу возникает ощущение, что этот сайт работает медленно на моем мобильном устройстве. Хотя сайт отдает приоритет содержимому заголовка, а также главному баннеру, вы можете видеть, что к этому моменту было сделано более 90 запросов, и, как я вижу полосу прокрутки, ясно, что контент должен быть загружен ниже сгиба.

Через 8,5 секунд я вижу, что карусель начинает загружаться. Количество запросов не изменилось, что говорит о том, что основная часть запросов, связанных с контентом, делается в самом начале загрузки страницы.

Только через 22 секунды я понимаю, что сайт полностью загружен. На самом деле для полной загрузки страницы потребовалось 28,4 секунды. Это говорит о том, что я считаю, что страница была полностью загружена, хотя на самом деле она была загружена на 77%.

Легко увидеть четкую разницу между двумя опытами. Хотя домашняя страница Amazon для мобильных устройств загружается значительно быстрее, чем домашняя страница Charles Tyrwhitt, были предприняты усилия, чтобы пользователи воспринимали ее еще быстрее. Пользователь начинает видеть, что что-то загружается в течение 12,5% от общего времени загрузки страницы, тогда как пользователи веб-сайта Charles Tyrwhitt видят, что что-то происходит только в течение 26% от общего времени загрузки страницы. Домашняя страница Amazon сделала 6 сетевых запросов, прежде чем пользователь увидит прогресс, тогда как домашняя страница Charles Tyrwhitt сделала 90 запросов.

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

Примеры мобильной коммерции: 3 бренда, которые ее полностью уничтожают

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

Улучшите скорость веб-сайта, отдав приоритет CSS

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

Решение этой проблемы состоит в том, чтобы разделить файлы css и загрузить их последовательно с важным содержимым. Если мы посмотрим на пример Amazon, они загружают файл css размером всего 6,5 КБ в качестве одного из своих первоначальных 6 запросов. Этот файл содержит css, необходимый для стилизации важного содержимого на их домашней странице. Фактически, общий размер всех файлов css, которые запрашиваются до того, как пользователь увидит контент на домашней странице Amazon для мобильных устройств, составляет менее 40 КБ, тогда как на домашней странице Charles Tyrwhitt он превышает 500 КБ.

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

Сделайте то же самое с JavaScript

Помимо расстановки приоритетов css, вы должны подумать о том, как сделать это с помощью JavaScript. Почти все веб-сайты электронной коммерции будут в значительной степени полагаться на JavaScript для работы. Это нормально, если JavaScript не блокирует загрузку критического контента. Если я снова возьму пример с веб-сайта Charles Tyrwhitt и отключу JavaScript в своем браузере, я увижу загрузку контента в течение 4,5 секунд. Это серьезное изменение в моем восприятии скорости этого веб-сайта и JavaScript, который загружался до того, как критический контент не повлиял на этот контент, и поэтому нет причин, по которым JavaScript не мог загрузиться после этого контента.

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

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