Первый день
2024 год. Я джун, только что устроился в компанию. Ожидал, что первые месяцы буду исправлять мелкие баги и разбираться в чужом коде. Реальность оказалась другой.
На второй неделе меня добавили в команду из двух фронтенд-разработчиков — и мы начали строить интернет-магазин с нуля. Не лендинг, не корпоративный сайт — полноценный e-commerce с тысячами товаров, фильтрами, корзиной, онлайн-оплатой и функцией рассрочки.
Что нужно было сделать
Проект был амбициозным по меркам любой команды, а уж тем более из двух человек на фронте:
- каталог с тысячами товаров и вложенными категориями
- фильтрация по десяткам параметров без перезагрузки страницы
- карточки товаров с галереями, характеристиками, отзывами
- корзина и оформление заказа
- интеграция с платёжной системой и функция рассрочки
- адаптивная вёрстка под все устройства
- SEO — метатеги, структурированные данные, скорость загрузки
Стек — Next.js, React, TypeScript. SSR для страниц каталога и карточек товаров, чтобы Google их нормально индексировал.
Чему научил большой проект
Компонентный подход на практике
До этого я читал про компоненты, писал небольшие учебные проекты. Но только на реальном проекте понял, что значит правильно разбить интерфейс.
Карточка товара — компонент. Галерея внутри неё — отдельный компонент. Кнопка "Добавить в корзину" с логикой состояния — тоже. Фильтры — отдельное дерево компонентов с собственным стейтом.
Когда всё разбито правильно, изменить поведение одного элемента можно не трогая остальные. Когда нет — правишь в одном месте, ломается в трёх других.
SSR и почему это важно для e-commerce
Страницы каталога и карточек товаров рендерились на сервере. Это критично по двум причинам: Google получает готовый HTML и нормально индексирует контент, а пользователь видит страницу быстрее, чем если бы она собиралась на клиенте.
Я разобрался, как правильно разграничивать серверные и клиентские компоненты в Next.js App Router — что можно рендерить на сервере, а что обязательно должно быть клиентским (интерактивные фильтры, корзина, модальные окна).
Оптимизация JavaScript-бандла
Когда мы впервые прогнали сайт через Lighthouse, размер JS-бандла оказался больше, чем хотелось бы. Начали разбираться.
Оказалось, несколько тяжёлых библиотек импортировались целиком, хотя использовалась только часть функционала. Добавили динамические импорты для компонентов, которые не нужны при первой загрузке — например, модальное окно оформления заказа. В итоге начальный бандл сократился значительно, и это сразу отразилось на оценках PageSpeed.
Чистый код и бизнес-логика
Логика рассрочки, расчёт цен со скидками, управление состоянием корзины — всё это бизнес-логика, которую важно писать предсказуемо и тестируемо. Я стал разделять: компонент отвечает за отображение, хук или утилитарная функция — за логику. Никакого спагетти.
Kapital.kz: с красного INP до зелёного
Параллельно с новым проектом я работал над действующим Kapital.kz — одним из крупных медиасайтов Казахстана. Там была конкретная проблема: метрика INP (Interaction to Next Paint) светилась красным в Google Search Console.
INP измеряет, насколько быстро страница реагирует на действия пользователя — клики, нажатия, скролл. Красный показатель означает, что пользователи ощущают тормоза при взаимодействии с сайтом. Google учитывает это при ранжировании.
Что было причиной
После анализа выяснилось несколько проблемных мест:
- тяжёлые обработчики событий блокировали главный поток
- часть работы выполнялась синхронно в момент клика, хотя могла быть отложена
- некоторые компоненты перерендеривались при каждом взаимодействии без необходимости
Что сделали
Разбили тяжёлые задачи на части, вынесли некритичные операции из обработчиков событий. Добавили мемоизацию там, где компоненты рендерились лишний раз. Оптимизировали работу с DOM.
Результат
INP перешёл из красной зоны в зелёную. В Google Search Console пропало предупреждение по Core Web Vitals. Это напрямую влияет на позиции сайта в поиске.
Что вынес из первого года
Большой проект с первых недель — это стресс. Но именно такие условия дают максимальный рост. За год я прошёл путь, который в спокойном режиме занял бы несколько лет:
- научился строить архитектуру компонентов, которую не стыдно поддерживать
- разобрался с SSR на практике, а не в теории
- понял, как работает производительность браузера и что на неё влияет
- получил опыт работы с реальными платёжными интеграциями
- увидел, как оптимизация кода напрямую меняет позиции сайта в Google
Самый главный урок — скорость роста определяется сложностью задач, которые берёшь. Лёгкие задачи комфортны, но не развивают.
