УПС! Что-то пошло не так

Askona — крупнейший в Восточной Европе вертикально-интегрированный производитель и ритейлер товаров для здорового сна, пятикратный обладатель отечественной премии «Марка № 1» в категории «Матрасы для сна». Миссия компании — научить людей правильно спать, делая их сон здоровым и давая силу и энергию для реализации своих целей.

Компания активно развивает омниканальный подход к розничной сети, когда оффлайн и онлайн каналы предоставляют единый спектр товаров и услуг для того, чтобы клиент мог совершать покупки максимально удобно как в салоне, так и в e-commerce — каналах. Об одной из ступеней в развитии интернет-магазина Askona — в этом кейсе.

Проблематика

Наше знакомство с «Асконой» началось с аудита старой версии сайта, после чего была выполнена работа по его модернизации, как с точки зрения usability, так и внутренней архитектуры, поскольку прежний вариант интернет-площадки не отвечал возросшей нагрузке. Однако на этом взаимодействие не прекратилось. Потребовалось ускорить работу интернет-магазина.

Цели и задачи

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

Реализация

Работы можно разделить на два этапа: по back-end’у и front-end’у. При диагностике проблем была выявлена крайне низкая скорость загрузки страниц на back-end’е. Скорость работы у 90% клиентов при переходе на самую популярную категорию достигала 148 секунд — это недопустимо много и приводило к падению конверсии.

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

Что касается front-end’а, то здесь картина была следующей. В разное время его неоднократно дорабатывали разные специалисты, что в результате привело к наслоению кодов, и чисто практически — к многократной загрузке одних и тех же элементов на странице. Неграмотное использование CDN оказывало огромную нагрузку на браузер и вызывало ошибки на самом сайте. К этому стоит добавить проблемы с lazyload и внешними скриптами.

Команда

• Руководитель проекта
• Тимлид разработки
• Front-end разработчик (2)
• Back-end разработчик (2)
• QA-лид
• Тестировщик (2)

Результат

Мы наладили мониторинг работы front и back-end’а, настроили получение метрик сайта при нагрузочном тестировании и реальной эксплуатации, устранили проблемы в обеих категориях без глобальной переделки кода, оптимизировали его в рамках существующей архитектуры сайта.

Магазин стал работать быстрее? Определенно! Средняя скорость по сайту раньше равнялась почти четырем секундам, после проведенных работ показатель стал равняться 0,29 с. Самая медленная категория: было — 93.128, стало — 1.129. Успех? Нам кажется, что да.