Инженерия UX и производительности

Внимание пользователя как архитектура надёжности, автоматизации и доверия

Кто такой UX Engineer, что такое SRE подход, и почему Performance Engineering начинается с целостной архитектуры

«Мы не будем давать определение, кто такой Performance и UX Engineer со SRE подходом. Вместе посмотрим - как он работает, какие задачи решает и как это становится архитектурой. Вы увидите и поймёте - не словами, а системой.»

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

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

Вы прочитаете внедрение Performance Engineering - не как теорию, а как систему. Где TTFB падает до 26 мс не после оптимизации, а как следствие многоуровневого кэширования и навигации с предзагрузкой на основе поведения. Как Lighthouse 100 становится побочным эффектом, а не целью. А производительность перестаёт быть задачей - и становится состоянием по умолчанию.

Сейчас вы в деталях рассмотрите, как работает Performance и UX Engineer со SRE подходом, на примере реальной рабочей среды, запущенной в продакшн в 2019 году, при том что её движок, БД и инфраструктура были выпущены до 2017 года, а поддержка уже несколько лет как прекращена. Даже к 2026 году это остаётся распространённым видом унаследованных платформ. Согласно открытым источникам, взрывной рост электронной коммерции начался в период пандемии и активно продолжался вплоть до 2023 года. Текущая инфраструктура сформировалась именно в этот период - время массового роста e-commerce.

Здесь не будет про React или Vue - потому что задача стояла решать на уровне платформы, а не через фреймворки. Не будет и про Prometheus с Grafana - потому что метрики необходимо было брать напрямую из htop, curl, ab и логов. Нет Kubernetes - потому что оркестрация в данном проекте была избыточна, а надёжность достигалась кодом. Не воспользуемся Loki - потому что есть среда, где достаточно bash, grep, awk. Не будем использовать и Ansible - потому что автоматизация эффективнее реализована встроенными средствами. Пропустим Figma - потому что визуал калибруется в DevTools: задача была - быстро, наглядно, "здесь и сейчас".

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

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

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

Продакшн: проблемы, решения и измеримый результат

Знакомимся с работой инженера - как взгляд на подход

Документ системы

1. Цель

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

Инженерия UX начинается с архитектуры, а не с интерфейса
Вместо миграции - надежность через автоматизацию и оптимизацию
Скорость, доверие и эффективность - результат устойчивой системы

Каждый проект - ответ на реальную проблему.

Философия: решать системно.
Приоритет - архитектура, а не интерфейс.
Надёжность - через автоматизацию, а не ручной труд.
Живое присутствие - не имитация, а результат UX-инженерии.

2. Вид рабочей среды

CMS OpenCart 3:

VPS SpaceWeb (CentOS 7, 6 CPU, 12 ГБ RAM, NVMe)
Apache: OpenCart 3.0.2, PHP 7.1.33 + OPcache
Nginx: phpMyAdmin, BrainyCP
СУБД MySQL 5.6.40 (InnoDB), Dr.Web

Распространённая архитектура унаследованной платформы - от малых до крупных e-commerce.

3. Общий контекст

Все проекты разрабатывались в условиях:

Ограниченные ресурсы - реализация одним инженером
Старая платформа - OpenCart 3
Высокая нагрузка - 80% трафика - с мобильных, 70% - новые пользователи
Ручные процессы - поддержка, навигация, обработка в доставку - всё, человеческий фактор

Задача: реализовать SPA-подобный интерфейс на текущей платформе. Чтобы система работала быстро, стабильно и "ощущалась" живой.

4. Структура: от ядра к периферии

Проекты выстроены в последовательность, отражающую масштаб и глубину внедрения:

ML-Cache - фундамент производительности
ISPN - навигация на основе поведения
PWA-Layer - нативный UX на веб-платформе
OPS-UX - автоматизация операторов поддержки
DialogCore - диалоговая система с ИИ и 500+ узлами
AI-Оператор - живое UX-присутствие и доверие
UX-Vibe - визуал как притяжение и завершённость

4.1. Логика последовательности

Как лестница становления:

Сначала задаём - скорость (ML-Cache, ISPN)
Затем оттачиваем - удобство (PWA-Layer)
Потом полируем - эффективность (OPS-UX, DialogCore)
И наконец зарождается - доверие (AI-Оператор + UX-Vibe)

Унаследованная модель

Четырёхуровневое кэширование

Мобильное веб-приложение + SW для браузеров

Браузерное расширение для операторов

Диалоговое ядро с памятью и LLM

«Живой диалог» UX с платформой

Современный UI как отклик

Внимание пользователя

Каждый уровень опирается на предыдущий. Бессмысленно делать живой UX, если сайт медленный и "разобранный". Неэффективно автоматизировать поддержку, если операторы выгорают на рутине.

С 2024 года каждый проект прошёл глубокое тестирование, калибровку и многократные итерации. Общие трудозатраты на реализацию и доработку всех семи проектов - более 4500 часов.

5. Краткое описание каждого проекта

5.1. ML-Cache - Многоуровневая система кэширования

Проблема: TTFB достигал 1200 мс, сервер перегружался под нагрузкой, кэширование было фрагментарным.

Решение: Построена 4-уровневая система - OPcache, «Сторонний модуль OpenCart», Brotli, Service Worker.

Измеримый результат: TTFB снизился на 98%, нагрузка на CPU - на 99.3%. Система стабильна с 2024 года.

5.2. ISPN - Интеллектуальная система предиктивной навигации

Решение: Внедрён сбор цепочек переходов, анализ логов, автоматический прогрев и предзагрузка контента.

Измеримый результат: TTFB снижен до 26 мс, время перехода - на 90%, Lighthouse Performance = 100.

5.3. PWA-Layer - Архитектура изолированного прикладного слоя

Проблема: Отсутствие мобильного приложения, восприятие обычного сайта.

Решение: Реализовано разделение Service Worker на режимы PWA и браузер, внедрёна динамическая предзагрузка страниц, splash-экран, учёт установок.

Измеримый результат: FCP снизился на 71%, трафик - на 42%, Lighthouse = 100.

5.4. OPS-UX - Операционная система поддержки

Проблема: Высокая нагрузка на операторов, рутина, частые ошибки, несогласованность ответов.

Решение: Написано браузерное расширение, с сохранением состояния и семантической вставкой шаблонов.

Измеримый результат: Время ответа сократилось с 45 сек до 8–12, ошибки устранены полностью, обучение сокращено с 5 дней до 1.

5.5. DialogCore - Диалоговая система с ИИ

Проблема: Все запросы проходили через операторов, отсутствовала база знаний, ответы были медленными.

Решение: Построено диалоговое ядро с 500+ узлами, семантической памятью, визуальным редактором и интеграцией ИИ.

Измеримый результат: 96% запросов обрабатываются без оператора, переводы сокращены до 1 в день, создано 200+ FAQ, база - 173 499 слов.

5.6. AI-Оператор - живое UX-присутствие

Проблема: Сомнения пользователей, пользователи не чувствовали «живого» взаимодействия с сайтом.

Решение: Реализована иллюзия присутствия - пульсирующая сфера, уведомления, игровые механики, «ритуалы» ожидания.

Измеримый результат: Конверсия выросла на 89%, время на сайте - на 104%, отказы снизились на 47%, открытие чата - на 10 900%.

5.7. UX-Vibe - визуал как притяжение

Проблема: Даже после всех улучшений интерфейс ощущался «безжизненным». Не было визуального выражения AI-Оператора.

Решение: Полностью переработана визуальная основа интерфейса через CSS и JS - глубина, свечение, анимации, форма, реакция на касание. Сформирован единый визуальный язык.

Измеримый результат: Появилось визуальное выражение AI-Оператора. Элементы интерфейса перестали быть функциями - стали точками диалога. AI-Оператор стал не только слышимым - он стал видимым.

5.7.1. «Просто Button-Vibe»

6. Общие принципы всех проектов

Во всех семи проектах соблюдены одни и те же инженерные и этические принципы:

Автономность - реализовано одним инженером, доступно всей команде
Надежность - минимизация или исключение человеческого фактора
Измеримость - каждый шаг проверяется через ab, htop, curl, логи
Итеративность - адресные, продолжительные периоды калибровки перед вводом в продакшн
Обратная совместимость - не требует переноса на другую платформу и глубоких изменений ядра
Self-contained - нет внешних зависимостей, всё встроено в текущую платформу
Этика UX - ускоряет, но при риске вреда включается защита: PerfGuard, исключения, адаптация под устройство
GDPR-дружелюбие - нет сбора персональных данных

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

Они не про отдельные или тоточечные улучшения. Они о построении доверия, заложенного в целостности всей системы.

7. Метрики

Основные показатели из рабочей среды проектов:

TTFB с 1200 мс до 26 мс, CPU на 99,3 %
FCP до 0,5 с, время на 70-90 %
Скоростное мобильное веб-приложение, Lighthouse Performance 100
96% запросов от пользователей обрабатывается без участия операторов
Время ответа операторов сократилось в 5 раз, обучение - до 1 дня
Быстрая, визуально современная, “живая” веб-платформа для пользователей

Скриншот консоли Chrome DevTools: TTFB = 4.7 мс в PWA. Ответ из кэша Service Worker.
Устройство: ASUS Zenfone 9, соединение: Wi-Fi 2.4GHz.

(() => {
  const nav = performance.getEntriesByType('navigation')[0];
  if (!nav) {
    console.warn('Нет данных о навигации. Обновите страницу.');
    return;
  }

  const ttfb = Math.max(0, nav.responseStart - nav.requestStart);
  const fromCache = nav.transferSize === 0;

  const scaleMax = 200;
  const barLength = 20;
  const filledLength = Math.min(barLength, Math.round((ttfb / scaleMax) * barLength));
  const emptyLength = barLength - filledLength;

  const ttfbColor = fromCache 
    ? '#43A047' 
    : ttfb < 50 ? '#43A047' 
    : ttfb < 200 ? '#FB8C00' 
    : '#E53935';

  const sourceLabel = fromCache ? 'Cached (SW)' : 'Network';
  const sourceColor = fromCache ? '#43A047' : '#1976D2';

  const bar = '█'.repeat(filledLength) + '░'.repeat(emptyLength);

  const labelLine = Array(barLength).fill(' ');
  labelLine[0] = '0';

  if (barLength > 11) {
    labelLine[9] = '1';
    labelLine[10] = '0';
    labelLine[11] = '0';
  }

  if (barLength > 18) {
    labelLine[17] = '2';
    labelLine[18] = '0';
    labelLine[19] = '0';
  }

  const labels = labelLine.join('');

  console.log('%cTTFB ANALYSIS', 'font-weight: bold; font-size: 14px; color: #ababab;');
  console.log(
    '%cTime to First Byte: %c' + ttfb.toFixed(1) + ' ms',
    'color: #ababab',
    `color: ${ttfbColor}; font-weight: bold`
  );
  console.log(
    '%cResponse source:    %c' + sourceLabel,
    'color: #ababab',
    `color: ${sourceColor}; font-weight: bold`
  );

  console.log('');
  console.log('%c' + bar, `color: ${ttfbColor}`);
  console.log('%c' + labels, 'color: #ababab; font-family: monospace');
  console.log('');

  console.log(
    '%cTTFB < 50ms: optimal | 50–200ms: acceptable | >200ms: needs improvement',
    'font-size: 11px; color: #ababab'
  );
})();

Результат:

Высокопроизводительная и надежная веб-система, которая всегда в диалоге с пользователем
Скоростное мобильное веб-приложение - красивая, комфортная для пользователей платформа на которой хочется проводить время
Операторы как управляющие диалога, а не "печатальшики по шаблону"
Чат-бот с семантической памятью и LLM - помощник 24/7 для пользователей и операторов, который всегда рядом и готов помочь
Бизнес-ориентированный продукт с измеримым результатом: конверсия +89%, время на сайте +104%, отказы -47%

7.1. Доверие системе: внешние проявления

Позиция - №2 в органической выдаче. Переходы из Google Поиска выросли на 94% за 6 месяцев: с 614 в мае до 1191 в ноябре 2025 года.

Источник: Google Search Console

Были устранены технические ограничения для поисковой индексации: исправлены ошибки индексации, настроены метатеги, улучшена структура URL, обновлён контент под пользовательские запросы.

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

Пользователь доверяет веб-сервису - поисковые системы доверяют пользователю.

8. Заключение

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

Один инженер может построить SPA-подобный опыт в условиях legacy, при этом сделав его доступным для всей команды
Инженерия производительности начинается с целостной архитектуры
Скорость, эффективность и доверие - результат устойчивой системы

Хочется выделить, что действительно считаю важным:

Понимать платформу от OPcache до Service Worker
Строить системы с измеримой производительностью
Думать на перспективу устойчивой и современной платформы
Работать комплексно, внутри системы

— это и есть Инженерия производительности и UX со SRE подходом, где

Пользователь не доверяет скорости.

Он доверяет вниманию.

А внимание — в архитектуре.