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

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

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

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

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

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

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

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

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

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

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

Окей, допустим, вы уже испугались и хотите начать решать проблему скорости загрузки страниц. Однако обычно эта задача обычно попадает в «полосу отчуждения» между техническим 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, чтобы делать очистку кэша - а это дополнительные затраты времени и ресурсов разработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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