Vanilla JS: почему мы пишем фронтенд без фреймворков

Во что обходится фреймворк на обычном сайте

Фреймворк — это библиотека, которая рисует интерфейс в браузере посетителя. Прежде чем человек увидит страницу, телефон должен скачать и выполнить этот код: React с обвязкой — ориентир 150–300 КБ сжатого JavaScript ещё до вашего контента.

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

• На среднем смартфоне в мобильной сети первый экран появляется на 1,5–3 секунды позже.
• Часть посетителей уходит, не дождавшись загрузки, — бюджет рекламы на них уже потрачен.
• Яндекс и Google ранжируют медленный сайт ниже быстрых конкурентов.

Что мы строим на чистом JavaScript

Vanilla JS — это не «сайт без интерактива». Современный браузер из коробки умеет почти всё, ради чего десять лет назад брали фреймворк. На чистом JavaScript у нас в продакшене работают:

• Квизы — пошаговые опросы с ветвлением и передачей ответов менеджеру вместе с заявкой.
• Калькуляторы стоимости — расчёт цены по параметрам изделия без перезагрузки страницы.
• Живой поиск — подсказки по каталогу с первых букв.
• Формы — валидация, защита от спама, отправка в CRM и цели в Метрику.

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

PageSpeed 90+ — следствие, а не подвиг

«Оптимизация до зелёной зоны» у большинства студий — борьба с последствиями: сжать, отложить, закешировать тяжёлый фреймворк. Мы не грузим лишнее с самого начала, поэтому PageSpeed 90+ на мобильных — не услуга, а свойство архитектуры: рукописная WordPress-тема, чистый JS, страницы легче мегабайта.

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

На этой базе растут SEO-результаты: у завода металлоконструкций — 2 566 запросов в ТОП-10 Яндекса, у поставщика бетона — трафик ×6,3 за месяц. Быстрый сайт — не единственная причина, но обязательное условие.

Два подхода в цифрах

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

Когда фреймворк оправдан — и когда наш подход не нужен

Мы не «против React» — мы против инструмента не по задаче. Фреймворк оправдан, когда интерфейс по сути программа:

• личные кабинеты с десятками экранов и правами доступа;
• дашборды с данными в реальном времени;
• SaaS-продукты и системы со сложным состоянием: конструкторы, редакторы.

Мы сами строим такие системы: отчётность продаж для завода металлоконструкций с интеграцией Битрикс24 и PostgreSQL, SEO-мониторинг девяти сайтов, SaaS-платформу мониторинга брендов в нейросетях. Поэтому понимаем, где фреймворк экономит месяцы, а где просто добавляет мегабайты.

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

Что это значит для вашего проекта

1. Сроки и бюджет. Без слоя фреймворка меньше работы: лендинг — от 80 000 ₽ с запуском за 5–10 дней, корпоративный сайт — от 200 000 ₽. Полные вилки — на странице цен.
2. Отдача от продвижения. Быстрый сайт усиливает и SEO, и Директ: тот же бюджет даёт больше заявок, потому что трафик не разбивается о загрузку. Примеры — в кейсах.
3. Независимость. Код открыт, стандартен и понятен любому веб-разработчику — вы не привязаны к нам.

FAQ