При разработке и развитии любого продукта есть одна вещь, которую я считаю архиважной на определённом этапе. Это этап, когда продукт уже прошёл тестирование и довольно активно используется и для дальнейшего движения вперёд необходимо принимать решения о том, что изменить в продукте, каким образом, что является его истинной ценностью для пользователя и как сделать эту ценность ещё больше и заметнее. Что всегда влияет на как на воспринимаемую, так и реальную (в денежном выражении) стоимость.

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

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

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

Одним из таких инструментов является Amplitude – комплексный инструмент для сбора данных и построения аналитических панелей (дашбордов). На нём можно довольно быстро собрать себе панель управления по вкусу и нуждам. К тому же он бесплатный, пока ты не нагрузишь его больше, чем 50 000 событий в течение месяца, так что для начала, думаю, хватит.

С точки зрения сложности внедрения эта штука одна из самых простых на рынке, работает не сложнее чем известные всем Яндекс.Метрика или бывшая Google Analytics. Правда, покодить всё же придётся.

Как работает email-рассылка из web-приложения

С помощью чего организовать отправку email-ов для web-проекта

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

На этой консультации я выяснил, что само приложение сейчас реализовано на Bubble, а бэкенд разработан самостоятельно, то есть это не no-code. Проблема заключалась в том, что вся эта связка работает очень медленно и приложение неюзабельно с точки зрения пользователя. И задача команда разработки заключалась в том, чтобы перейти на новый фронт с Бабла.

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

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

Будем разбираться, в чём же тут дело, и как можно решить эту задачу.

Стартап-проект, связка Bubble + самописный бэкенд. Проблема – сайт работает очень медленно, пользоваться невозможно.

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

Начнём с бэкенда – того, что скрыто под капотом. Программная часть, которая обрабатывает данные, работает с базой, в общем делает всё, что скрыто от глаз пользователя. В общей связке программного комплекса – это двигатель, от скорости работы которого в принципе зависит возможная потенциальная скорость всей машины.

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

На данном этапе в сам код я не погружался, да это и не нужно для базовой оценки ситуации. Достаточно посмотреть на конечную скорость получения данных при запросах. То есть пользователь что-то делает на сайте (фронт, нажимает на педаль газа), фронт отправляет запрос к бэкенду (срабатывает передаточный механизм) и бэкенд возвращает данные (крутящий момент), фронт их отображает (колёса вращаются).

В данном случае мы видим, что данные по запросу возвращаются очень быстро, за доли секунды, ка кв принципе и должно быть. Отправили запрос – сервис ответил, скажем, за 0,25 секунды. Но на фронте данные появляются значительно позже, только секунд через 15-20.

Копаем дальше.

Что может тормозить web-приложение

Движок под капотом у нас быстрый, с этим разобрались. А что с лицевой частью, фронтэндом? Как я уже упоминал в первом посте, фронт собран на Bubble – на текущий момент лидирующая no-code платформа, которая очень много ресурсов вкладывает в ускорение работы приложений, которые собраны на ней.

На одном из своих проектов наблюдал эту картину воочию: стандартный слайдер-гармошка раньше открывался как-то дёргано и заметно для глаза медленно, причём там не было какого-то тяжёлого контента. Через некоторое время после очередного обновления Bubble слайдер стал работать безупречно плавно без всяких заметных глазу тормозов. При этом с моей стороны никаких изменений не было, обновилась сама платформа.

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

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

Конструкторы вроде Tilda – это как поход в Макдак (и точка), где ты выбираешь из готовых блюд и на выходе получаешь ожидаемого качества обед. А Bubble – это магазин с ингредиентами, из которых тебе самому всё надо приготовить. Получится ли из этого шедевр или что-то, что придётся отдать коту, зависит полностью от тебя. Котяра, кстати, вероятно тоже не станет это употреблять.

Поэтому грамотно и чисто собранный Bubble – это важная составляющая быстрого приложения. Но это ещё не всё, остался ключевой элемент паззла.

Как ещё можно оптимизировать скорость работы web-приложения

Ещё одна точка преткновения, которую я обнаружил, консультируя заказчика – это объём передаваемых данных. Да, бэкенд работает молниеносно, API отвечает за доли секунды. Но порция данных, которую сервис вываливает на фронт – тысячи позиций за раз. А теперь приложению в браузере нужно как-то это всё прожевать, переварить и выдать полезные вещества из этих данных на экран.

А теперь и самому пользователю надо проделать всё то же самое: как-то воспринять этот объём информации и выудить оттуда нужное. Ведь у него и так мало инфы в течение дня: подумаешь, пара сотен постов в Инсте, с десяток умных каналов в Телеге (ага) и несколько видосов на Ютубе, просмотренных залпом.

Представь грузчика, который разгружает кузов, набитый небольшими коробками. если это самосвал, то можно опрокинуть его прямо на грузчика и уехать. Вот таким самосвалом сейчас API отгружает данные на фронт. Конечно, рано или поздно он всё разгребёт, но не будет ли более эффективным разбить данные на порции и подавать нашему работнику их партиями по 5 коробок за раз?

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

Но ведь в жизни работает намного эффективнее, чем в некоторых приложениях! Ты подходишь к фармацевту, и он приносит тебе на твой запрос 2–4 варианта, из которых намного легче выбрать, задав ещё пару уточняющих вопросов. Это и есть фильтрация данных на фронте.

Итак, первое – фильтрация данных на входе. Разбей их на порции, добавь пагинацию (переключение страниц или подгрузка при скролле). Прикрути дополнительные фильтры, которые помогут вычленить нужное и ограничить выборку ещё больше. Тем самым облегчишь жизнь и бэку, и фронту, и пользователю.

Соберу воедино всё, на что стоит обратить внимание в первую очередь при анализе скорости работы web-проекта по мотивам консультации заказчика

1. Нужно определить узкое горлышко системы, самого медленного верблюда, который тормозит весь караван.

2. Для этого последовательно проверяем все составные элементы архитектуры. Разумеется, предварительно надо описать архитектуру хотя бы на верхнем уровне для понимания, с чем мы работаем.

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

4. Лицевая часть или фронтенд – то, с чем взаимодействует пользователь напрямую. Насколько быстра сама платформа, достаточно ли оптимально собрано приложение, нет ли лишний операций, которые можно переложить на плечи бэкенда?

5. Интеграционный слой – связь между бэком и фронтом. Насколько грамотно она организована, как далеко серверы расположены друг от друга, нет ли ограничений с обеих сторон (со стороны передачи или приёма)?

6. Оптимизация передачи данных. Разбить на порции, применить фильтры, ограничить поток.

И последнее. Переходить на новую платформу (как фронт, так и бэк) – всегда очень болезненный, долгий и ресурсоёмкий процесс. Если переводить в деньги, то сильно дешевле будет оптимизировать текущую конструкцию, чем строить новую.

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

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