Разработка портала ярека.рф с нуля за 4 месяца: речной транспорт, турбазы и прокат Самарской Луки

.case-content h2 { margin-top: 48px; }
.case-content h3 { margin-top: 32px; }
.case-content figure { margin: 32px 0; }
.yareka-summary { background: #f8f6ff; border-left: 4px solid #7b2cbf; padding: 20px 24px; border-radius: 0 12px 12px 0; margin: 24px 0 32px; font-size: 15px; line-height: 1.7; }
.yareka-summary strong { color: #7b2cbf; }

О проекте

ЯРЕКА — сервис, который закрывает всю «речную» часть жизни Самарской области: переправы через Волгу, скоростные теплоходы «Валдай», речное такси, грузовые паромы, аренда катеров с капитаном, базы отдыха Самарской Луки, плавдома, площадки для мероприятий и прокат снаряжения — от велосипедов до SUP-бордов и квадроциклов.

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

Задача, которую поставил клиент, звучала так: «Сделайте место, куда человек заходит с телефона на причале и за минуту получает ответ». Отдельного сайта, дизайна, брендинга и контентной базы не было — мы начинали с чистого листа.

Задачи и KPI

С клиентом мы договорились о четырёх измеримых целях — намеренно не про «красивый сайт», а про то, что можно проверить:

1. Расписание за один экран. Пользователь на мобильном должен увидеть ближайшие рейсы, цену и время в пути без скроллов и без PDF. Целевой показатель — не более двух тапов от главной.
2. Скорость на слабой сети. LCP на мобильном ≤ 2 секунд при 4G с троттлингом. На берегу Волги связь — это то, что есть, а не то, что хотелось бы.
3. Один вход для всех услуг. Переправа, аренда катера, турбаза и прокат — четыре разных бизнес-сценария, но одна навигация и один телефон.
4. Готовность к сезонному пику. Сайт должен держать всплеск трафика в выходные июля-августа без деградации. Целевой порог — 300 запросов в секунду при времени ответа до 200 мс.

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

Исследование: что мы выяснили до первой линии кода

Три недели ушло на то, чтобы понять, как люди на самом деле пользуются речным транспортом в Самаре. Мы разобрали поисковый спрос, изучили обсуждения в тематических сообществах и провели восемь коротких интервью — с дачниками Рождествено, велотуристами, семьями, которые ездят в Ширяево на выходные, и двумя владельцами турбаз.

Четыре вывода, которые определили всю архитектуру:

• Спрос почти полностью мобильный и «здесь и сейчас». Пиковые обращения — утро выходного дня и вечер пятницы. Человек уже решил ехать, ему нужны время отправления и цена.
• Расписание — главный магнит. Запросы вида «расписание теплохода Самара Ширяево», «переправа Рождествено расписание» дают основную частотность в нише.
• Велосипед — отдельный сценарий. Перевозка велосипеда через Волгу — устойчивый запрос со своими правилами и тарифом. Мы вынесли его отдельным блоком на главную.
• Звонок побеждает форму. В этой нише люди набирают номер. Форма нужна для отложенных сценариев, но телефон должен быть виден на каждом экране.

Информационная архитектура

Портал объединяет четыре разных бизнеса: перевозки, аренду, размещение и прокат. Соблазн был сделать четыре независимых раздела — по факту четыре мини-сайта под одним доменом.

Мы пошли другим путём и построили навигацию не по типам бизнеса, а по намерениям пользователя. Шесть пунктов верхнего меню — «Расписание теплоходов», «Речное такси», «Аренда катера на Волге», «Базы отдыха», «Лучшие пляжи города», «Активный отдых» — это шесть формулировок задачи, с которой человек приходит.

Главная страница собрана как навигационный хаб: сверху — блок речного такси с телефоном в липкой карточке, ниже — популярные направления, затем плитка с расписанием, прокатом и пляжами, отдельный блок баз отдыха. Никакой длинной вводной простыни: первый экран — это сразу действие.

Дизайн и дизайн-система

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

Собрали компактную дизайн-систему: 5 цветовых токенов, 6 типографических стилей, 12 переиспользуемых компонентов. Это дало главное — 11 шаблонов страниц собираются из одного набора блоков, и любую новую страницу редактор клиента может сложить сам, не вызывая разработчика.

Логотип и фирменный знак — стилизованный парус-волна — разработали в том же спринте. Иконки собственные, единой сеткой 24×24, инлайновым SVG-спрайтом: ни одного иконочного шрифта и ни одного растрового значка на сайте нет.

Почему WordPress

Вопрос платформы обсуждали отдельно. Мы выбрали WordPress осознанно по трём причинам:

• Контент обновляется ежедневно и не разработчиком. Расписание меняется в зависимости от дня недели, погоды и спроса. Редактор клиента должен править это сам, за минуту, с телефона.
• Стоимость владения. Проект сезонный и региональный. WordPress с грамотной темой поддерживается силами администратора.
• Скорость до релиза. Пользовательские аккаунты, роли, медиабиблиотека, редактор, REST API — всё из коробки. Мы вложили недели в модуль расписаний, а не в базовую авторизацию.

Тема написана вручную: собственные типы записей, собственные шаблоны, собственная сборка ассетов. Плагинов в продакшене девять. Это принципиальный момент: типовая тема с маркетплейса плюс двадцать плагинов не даёт ни 96 баллов Lighthouse, ни 300 RPS.

План работ

Работали двухнедельными спринтами с демо в конце каждого. С шестой недели фронтенд и бэкенд шли внахлёст: как только был готов макет раздела, он сразу уходил в вёрстку. Последние три недели — безопасность, нагрузка, наполнение и стабилизация.

Бэкенд: шесть сущностей вместо тридцати страниц

Ключевое инженерное решение проекта — не делать статические страницы. Всё содержимое сайта живёт в шести кастомных типах записей со своими наборами полей:

Всего около 180 настроенных полей. Выгода очевидна на примере тарифов: при изменении цены на перевозку велосипеда редактор меняет одно поле, и цифра обновляется в тарифной таблице, в карточке маршрута и в блоке про велосипедную переправу одновременно.

Модуль расписаний

Самый нагруженный по логике блок. Расписание «Валдая» и переправ отличается по дням недели, зависит от сезона (навигация с 1 июня по 30 августа), а отдельные направления могут отключаться в течение дня.

• Маршруты выводятся аккордеоном, внутри — переключатель «Будни / Пятница и выходные», две таблицы по направлениям.
• У каждого маршрута свой статус: активен, временно недоступен, вне сезона. Статус переключается одним селектом и сразу меняет вид карточки.
• Переключение вкладок работает без перезагрузки — обе таблицы отдаются в разметке сразу, скрипт только меняет видимость.
• Сводка над расписанием собирается автоматически из полей маршрутов — рассинхрон технически невозможен.

Каталог проката: UGC с модерацией

Любой владелец велосипеда, SUP-борда, мотоцикла или квадроцикла может зарегистрироваться и разместить оборудование бесплатно. Под это собрали:

• Регистрацию и личный кабинет арендодателя с отдельной ролью и урезанными правами — админка WordPress для этой роли полностью закрыта.
• Форму добавления оборудования на фронтенде с проверкой типа файла, пересжатием и конвертацией в WebP.
• Премодерацию: новое объявление публикуется после проверки редактором.
• Фильтрацию каталога по категориям без перезагрузки страницы.

Формы и обработка заявок

Пять сценариев заявок, каждый со своим набором полей. Технически все работают на одном обработчике с валидацией на двух уровнях — браузерной и серверной. Маска телефона, валидация даты, ограничение по вместимости судна, уведомления на почту и в Telegram менеджерам за 5 секунд, дублирование в админку, защита от спама без CAPTCHA через honeypot и rate limiting.

Производительность

Первая рабочая сборка: 3,4 МБ на страницу и LCP 4,2 секунды. Четыре недели оптимизации:

• Изображения. WebP с фолбэком, восемь размеров под разные брейкпоинты, srcset, ленивая загрузка и явные width/height — последнее одной строкой убрало почти весь CLS.
• Критический CSS. Стили первого экрана инлайном в <head>, остальное — отложенной загрузкой.
• JavaScript. Нет jQuery. Весь интерактив — 24 КБ нативного JS. Скрипты разделены по страницам.
• Шрифты. Локальный хостинг, подмножество кириллицы, font-display: swap.
• Кеширование. Статический кеш Nginx, Redis, Brotli, HTTP/2. TTFB — 180 мс.

Итог: 96 баллов Lighthouse на мобильном, LCP 1,6 с, вес главной 720 КБ. Все Core Web Vitals — в зелёной зоне.

Нагрузочное тестирование

Без кеширования сервер деградирует уже на 100 RPS. Релизная конфигурация — статический кеш + Redis + тюнинг Nginx и PHP-FPM — держит 300 RPS со средним временем ответа 140 мс. Это вчетверо больше пикового трафика первого сезона.

Сделали точечную инвалидацию кеша: при сохранении рейса или маршрута кеш чистится только на затронутых страницах.

Безопасность

На сайте с регистрацией, пользовательским контентом и персональными данными это не абстрактный риск. Контур безопасности закладывали параллельно с разработкой:

• Транспорт. HTTPS, HSTS, CSP, X-Frame-Options, Permissions-Policy.
• Доступ. Нестандартный адрес входа, 2FA, ограничение попыток, отключённый файловый редактор.
• Роли. Четыре роли с минимальными правами. Арендодатель работает только через фронтенд-кабинет.
• UGC. Санитизация, подготовленные запросы, проверка MIME, запрет PHP в uploads.
• Периметр. WAF, rate limiting, закрытие XML-RPC и лишних REST-эндпоинтов.
• Данные. 152-ФЗ, чекбоксы согласия, серверы в России.
• Эксплуатация. Ежедневные бэкапы, staging, мониторинг в Telegram.

За первые шесть недель фильтры отсекли около 24 800 автоматизированных запросов. Успешных инцидентов — ноль.

SEO-фундамент

• ЧПУ-адреса, плоская структура, хлебные крошки.
• Уникальные title и description, шаблонизированные для типовых сущностей.
• Schema.org: Organization, BreadcrumbList, FAQPage, Product, LodgingBusiness.
• Один H1, корректная иерархия, осмысленные alt-атрибуты.
• XML-карта, robots.txt, Яндекс Вебмастер, Google Search Console, IndexNow.
• Open Graph для мессенджеров — в этой нише ссылками активно делятся в чатах.

Результаты за первые 6 недель

Сайт запущен 4 июля 2026 года. Органический рост нового домена без рекламного бюджета:

Ключевые наблюдения:

• Расписание собирает 54 % всех визитов. Гипотеза исследования подтвердилась полностью.
• Звонок побеждает форму. 138 кликов по телефону vs 67 отправленных форм. Соотношение 2:1 стабильно с первой недели.
• Каталог проката — второй по глубине просмотра раздел. Среднее время на странице — 2 мин 40 сек.
• Пик — суббота, 8:00–11:00. Ровно тот сценарий, под который делали кеш.
• Отказы 16 % — низкие даже для информационного сайта. Человек находит нужное на первом экране.

Что не получилось

Опоздали к началу сезона

Навигация идёт с 1 июня по 30 августа. Мы запустились 4 июля — треть сезона потеряна. Правильно было либо стартовать в феврале, либо резать первую версию до минимума и выкатывать прокат вторым релизом.

Онлайн-оплата билетов не запустилась

Модуль был готов, но упёрся в юридическую обвязку агентской схемы. Сейчас кнопка ведёт на бронирование по телефону. Урок: интеграции, зависящие от юридических процессов клиента, нельзя ставить в критический путь релиза.

Готовый плагин расписаний пришлось выбросить

Через полторы недели стало ясно, что логика «разное расписание в разные дни + статусы + сезонность» в него не ложится. Модуль переписали на свои типы записей. Потеряли 10 дней.

UGC-каталог заполняется медленнее, чем планировали

За шесть недель самостоятельно зарегистрировались двое; остальные 9 карточек завела редакция после обзвона. Классическая проблема курицы и яйца у маркетплейсов.

Выводы по нише

1. Дата релиза диктуется сезоном. Опоздание на месяц — потеря трети годовой выручки от канала.
2. Расписание — это продукт. Не служебная страница, а главный магнит трафика.
3. Считайте звонки. Соотношение звонков к формам — 2:1. Сайт без коллтрекинга показывает треть эффективности.
4. Вес страницы — бизнес-метрика. Аудитория на берегу, связь непредсказуема.
5. UGC не запускается сам. Нужен ручной посев и обзвон поставщиков.
6. Один телефон, много сценариев. Навигация строится по намерениям, структура данных — по бизнес-сущностям.

Что дальше

• Запуск онлайн-оплаты билетов после закрытия договорной части
• Интерактивная карта причалов и точек проката
• Подключение коллтрекинга
• Полноценные SEO-работы к следующему сезону
• Вторая версия каталога проката с онлайн-бронированием слотов