{"id":13641,"url":"\/distributions\/13641\/click?bit=1&hash=54ad57c4617320c107392085a34311acc98a801723ceed43ac5a66c11a945977","title":"\u0422\u043e\u0440\u0433\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043c\u0430\u0440\u043a\u0435\u0442\u043f\u043b\u0435\u0439\u0441\u0435 \u043a\u0430\u043a \u0441\u0430\u043c\u043e\u0437\u0430\u043d\u044f\u0442\u044b\u0439","buttonText":"\u041a\u0430\u043a?","imageUuid":"92ef5acf-26f1-5102-8f72-40ca3bb88998","isPaidAndBannersEnabled":false}

Как управлять изображениями в интернет-магазине и не раздувать затраты на ИТ-инфраструктуру

Практики управления контентом и нагрузкой на ИТ могут спасти или убить конверсию онлайн-ритейлера

Изображения составляют более 50% контента любого ecommerce-ресурса: покупатель (готов он купить товар онлайн или изучает его, прежде чем купить потом в магазине) оценивает преимущества товара и принимает решение во многом благодаря онлайн-витрине. Чтобы удержать пользователя и с большей вероятностью превратить его в покупателя, ecommerce-директора и маркетологи используют все больше качественных изображений, но при этом “парк” изображений разрастается, занимает все больше места на серверах, оказывает все большую нагрузку на ИТ-инфраструктуру, становится трудноуправляемым. Казалось бы, при чем тут конверсия?

Недавно мы (я работаю директором по клиентскому сервису в компании NGENIX) провели вебинар о Digital Asset Management в электронной торговле, где как раз задались вопросом, из-за каких неочевидных причин теряется конверсия интернет-магазина, при чем тут ИТ-инфраструктура, как управление цифровыми активами оказывает влияние на то, продолжит ли потенциальный покупатель изучать товар или уйдет искать в других местах. Маркетологи и директора по e-commerce применяют бесчисленное множество тактик, чтобы увеличить конверсию в покупку: от поп-апов до работы с брошенными корзинами, но все это обычно фронт-энд. Но если со стороны фронт-энда многое (если не все) уже сделано или придумано, что можно сделать на стороне бэк-энда, чтобы не потерять в конверсии? Мы сконцентрировались на двух аспектах работы веб-сайта - ускорении загрузки и корректном отображении сайта. Подготовили полезную выжимку с техническими рекомендациями по работе с контентом и, в частности, с изображениями.

В чем проблема?

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

В конце мая мы собирали статистику по темпам роста трафика (в количестве HTTP-запросов в секунду - RPS) в сегментах e-grocery и непродовольственной розницы в течение двух месяцев карантина, и вот что получилось:

Изменение среднего RPS в сегментах продовольственной (вверху) и непродовольственной (внизу) розницы NGENIX

Трафик веб-ресурсов e-commerce стал совершенно непредсказуемым, в нем перестали прослеживаться среднесуточные и средненедельные паттерны. И если те, кто отвечает за выручку интернет-магазина, с радостью потирали руки в ожидании роста, то те, кто обеспечивает ИТ-инфраструктуру, столкнулись с потребностью масштабироваться - притом очень быстро. Ок, допустим, дополнительные сервера закуплены, развернуты, мы ждем наплыва посетителей. Но потом люди решили, что, например, лучше сходить в обычный магазин, чтоб прогуляться хотя бы раз в день в условиях самоизоляции, - трафик так же резко падает, а избыточная инфраструктура под него уже куплена и поддерживается, но простаивает. CAPEX и OPEX выросли на фоне падения выручки - и теперь спасти прибыль онлайн-магазина могут рост конверсии в покупку и снижение показателей отказа.

Схожий кейс — это масштабные акции и распродажи: так как мы наблюдаем веб-трафик ряда крупных онлайн-ритейлеров изнутри, мы часто видим ситуацию, когда условная “Черная пятница” способствует практически 10-кратному росту потребления трафика всего за один день, притом после окончания ажиотажа трафик возвращается к прежним значениям так же быстро. Вот, например, пруф (это потребление полосы пропускания крупным онлайн-магазином во время распродажи): в течение дня средние показатели потребления веб-трафика вырастают с 38 Мбит/с до 435 Мбит/с и уже до начала следующего дня возвращаются к привычным значениям до следующей распродажи. Если в этой день сайт магазина упадет под такой нагрузкой, вряд ли можно будет похвалиться высоким ROMI по этой акции.

Полоса пропускания популярного российского онлайн-ритейлера при распродаже NGENIX

Еще один заметный тренд - это рост доли мобильных покупок: за пять лет она выросла с 2% до 32%, и с приходом поколения Z будет продолжать расти. Нестабильная работа сайта (долгая загрузка из-за ограничений в скорости подключения, некорректное отображение товарных позиций) убивает конверсию, притом в глобальном разрезе статистика говорит, что 70% маркетологов находят свою стратегию по повышению конверсии в m-commerce неэффективной.

Посмотрим, чем во всех этих ситуациях можно помочь со стороны ИТ.

Как работа с изображениями может помочь повысить конверсию?

Скорость загрузки страниц не всегда расценивается маркетологами или директорами в e-commerce как приоритетный фактор, влияющий на уровень конверсии: по статистике, 19% вообще не считают, что это важно. Но есть железобетонные аргументы, которые говорят о том, что проблему все же придется решать:

47% потребителей не будут ждать загрузки веб- страницы магазина более 2 секунд (в случае с мобильными пользователями 53% поступят так же через 3 секунды ожидания);

45% онлайн-покупателей не склонны совершить покупку, если сайт работает медленно, а 37% покупателей больше вообще не вернутся на сайт. 12% еще и расскажут о негативном опыте знакомым;

В среднем одна дополнительная секунда загрузки веб-сайта равна потере 7% конверсии.

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

Список рекомендаций для работы с изображениями со стороны бэк-энда

Окей, допустим, вы уже испугались и хотите начать решать проблему скорости загрузки страниц. Однако обычно эта задача обычно попадает в «полосу отчуждения» между техническим SEO и контентом. На этот параметр со стороны фронт-энда могут влиять различные специалисты — разработчики, дизайнеры, контент-менеджеры и администраторы. Управление процессами их взаимодействия - как раз одна их задач Digital Asset Management’а, о котором мы говорили на вебинаре, но это уже, скорее всего, для следующего раза =)

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

Составляем список покупок...

Существуют лучшие практики работы с изображениями, которые помогают сделать работу сайта магазина стабильной и улучшить показатели скорости загрузки, а следовательно, и конверсию. Все рекомендации проверены на практике — это шишки, которые мы набили на реальных проектах в сфере e-commerce при оптимизации изображений через наш собственный сервис NGENIX Image Optimization.

Заведите отдельный домен для статики

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

Как можно поступить? Можно завести, например, поддомен третьего уровня и раздавать статический контент с него. Первое и основное преимущество этого подхода - простота переключения через CNAME: не нужно давать задачу разработчикам и править код, все происходит на уровне службы эксплуатации. Второе преимущество - гибкое управление безопасностью: для статики можно реализовать более суровые настройки безопасности (отключить лишние HTTP-методы, например), более четко определить политику обращения к ресурсам. Третье преимущество - возможность увеличить скорость работы сайта. Например, если приложение использует уже не новый протокол HTTP/1.1, вы получите дополнительное ускорение, т.к. любой браузер имеет ограниченное количество подключений на один домен в случае использования HTTP/1.1.

Вот так, например, доставка статики организована через отдельный домен в Ozon:

Версионируйте контент

Тоже расхожая проблема. Скажем, вы обновили сайт, он где-то закэшировался, и пользователи получают доступ к старой версии - заходят на сайт и видят совершенно не то, что вам хотелось бы. Вам необходимо после выкатки чистить кэш на платформе сервис-провайдера и всех ваших реверс-прокси. При этом существует возможность, что какой-нибудь пользовательский прокси не соблюдает RFC и закэшировал старую версию навечно. В итоге из-за того, что пользователи продолжают заходить на устаревшую версию сайта, падает конверсия, увеличивается отток. Кроме того, все это сложно поддерживать, потому что необходимо интегрировать вашу CI/CD-систему с API, чтобы делать очистку кэша - а это дополнительные затраты времени и ресурсов разработки.

Как решить? Версионность — это лучшая практика. Когда вы меняете контент, вы добавляете версию либо в наименование, либо в путь, либо в аргументы запроса, то есть вот так:

В имени файла – style.v2.css

В пути – /v2/style.css

В аргументах запроса – style.css?v=2

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

/bitrix/cache/css/s1/main/kernel_main/kernel_main.css?14356674393041

03_Pravilno_imenuite_faily

Еще одна распространенная проблема, с которой мы не раз сталкивались, — это неправильное именование файлов. Если не соблюдать принятые в ИТ-сообществе соглашения в области именования файлов, могут возникнуть проблемы либо с отображением объектов, либо с очисткой кэша. Любой специальный символ может быть энкодирован в другую последовательность символов. Это усложняет техподдержку сайта: например, вы захотели почистить кэш, но файл называется уже не так, как назывался в оригинале. Вот, например, как энкодировались пробелы в именовании PDF-файла на сайте:

Оригинальный файл: /website training class sample.pdf

После urlencoding: /website%20training%20class%20sample.pdf

Этого всего можно избежать, используя безопасный набор символов: цифры, латиница, андерскор (_) и дефис (-).

Всегда используйте заголовки кэширования

Провайдеру необходимо понимать, какой контент кэшировать, а какой нет. Чем грозят неправильные заголовки кэширования и как это отражается на работе сайта? Часто происходит так, что кэшируется динамический контент, но статика, наоборот, не кэшируется. Это происходит либо из-за отсутствия заголовков кэширования, либо, например, на статику выставляется заголовок Set-Cookie (а по RFC такой объект кэшировать нельзя, и тут мы вспоминаем про отдельный cookieless домен). Это приводит к тому, что сайт работает не так, как нужно: возникает повышенная нагрузка на сервера оригинации и другие проблемы.

Для динамического контента самое оптимальное решение - это установка двух заголовков, например:

Cache-Control: no-cache,no-store,max-age=0,must-revalidate

Expires: Thu, 01 Jan 1970 00:00:01 GMT

Зачем здесь два заголовка? Промежуточные прокси между пользователем и облачным провайдером могут быть устаревшими и не “знать” о заголовке Cache-Control, либо не обрабатывать все его директивы, поэтому в таком случает они хотя бы могут ориентироваться на заголовок “Expires”.

Для статики все проще: в заголовке Cache-Control нужно указать время (в секундах), в течение которого контент должен лежать в кэше. После истечения этого времени контент будет перезапрошен с сервера оригинации:

Cache-Control: max-age=259200

Предусмотрите особенности инфраструктуры и архитектуры для ресайзинга на лету

Для качества пользовательского опыта важно, чтобы отображение картинки было заточено под различные типы экранов. До того, как сделать различные версии большого изображения под различные типы устройств, надо определиться с профилями — это может быть от 3 до 5 профилей с отдельными параметрами сжатия под каждый. Ресайзинг изображений должен работать в синхронном режиме (на лету): нелогично пользователю, который заходит с мобильного устройства и запрашивает маленькое изображение, отдавать оригинальное, так как из-за этого у вас может “поехать” верстка. Самая большая проблема в этом случае — это высокая ресурсоемкость для кэширования и конвертации, под это нужно соответствующе планировать и архитектуру приложения, и нижележащую ИТ-инфраструктуру, если учесть характерные для e-commerce всплески обращений к сайту. У нас синхронной конвертацией занимается отдельное приложение на промежуточных серверах, а чтобы справиться с всплесками запросов, мы предусмотрели его автоскейлинг.

Используйте современные форматы сжатия

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

На сайтах онлайн-магазинов используются большей частью JPEG (или PNG, если необходимо использовать текст и лого, где есть четкие переходы между цветами). Существует более оптимизированный формат WebP, который был представлен в 2010 году Google - он поддерживается 72% браузеров. Долгое время Apple оставалась в стороне и использовала собственный формат сжатия, но буквально пару недель назад компания наконец объявила о поддержке WebP в следующей 14 версии Safari, и это еще один довод в пользу того, чтобы обратить внимание на конвертацию изображений из привычных форматов в WebP.

Формат очень хорошо оптимизирует размер без видимой потери качества, хотя сжатие, как и в JPEG, происходит с потерями. Но на мобильных устройствах, например, это не так сильно заметно, а прирост в скорости доставки колоссален (о реальном тестировании расскажем чуть ниже). Если на сайте очень много изображений, и часть товаров загружается фоном для “перелистывания” нескольких изображений одного товара, время загрузки страницы может увеличиться в несколько раз.

Пример тестов на одном из клиентов: средний размер изображения уменьшился более чем вдвое NGENIX

Как оптимизация изображений влияет на скорость загрузки и объемы трафика

При конвертации изображений в WebP происходит несколько особо приятных для представителей e-commerce вещей - в этом мы убедились, протестировав работу сервиса оптимизации изображений на инфраструктуре одного всем известного игрока рынка e-grocery.

Например, снижение объемов передаваемого трафика на 46% в пике и на 42,3% - в среднем.

Вверху - потребление полосы пропускания с подключенным сервисом оптимизации изображений (IMO). Внизу - без оптимизации изображений NGENIX

Или улучшение показателя времени запроса, что ускоряет загрузку страниц в среднем на 64,8%.

Среднее время запроса к изображению в мс NGENIX

Оптимизация изображений существенно снижает потребляемый трафик при просмотре страниц с мобильного устройства: благодаря использованию формата WebP объемы передаваемого трафика снижаются на 58% в пике и на 64,5% в среднем. Время запроса на мобильных устройствах при оптимизации изображений снижается более чем в 5 раз.

Что в итоге?

Мы собрали ряд полезных (но не для всех очевидных) практик, которые помогут онлайн-магазинам улучшить показатели конверсии. О том, насколько важно быстродействие и время отклика для конверсии, особенно для крупного онлайн-ритейлера, говорит пример Amazon: его представители утверждают, что, улучшая время загрузки сайта на 0,1 секунды, они увеличивают доход на 1%. Учитывая, что чистая прибыль Amazon по итогам 2019 года составила $3,3 млрд, к этому вопросу в Amazon относятся серьезно.

Amazon молодец, будьте как Amazon! =)

P.S. Если интересно, при чем здесь Digital Asset Management и с чего начать внедрение этого подхода, то здесь лежит запись нашего вебинара - велкам!

0
Комментарии
Читать все 0 комментариев
null