Почему мы не делаем сайты на конструкторах: честный технический разбор

Почти каждый разговор о новом проекте начинается с одного и того же вопроса: «На Тильде обещают собрать за три дня и двадцать тысяч, а у вас дороже и дольше — почему?». Вопрос честный, и мы отвечаем на него честно и по-инженерному, без маркетинговой мишуры. Разница между конструктором и кастомным сайтом — это не разница в дизайне и не «у нас красивее». Это разница в том, что именно вы получаете на выходе: арендованную витрину, которую в любой момент можно потерять, или собственный актив, который годами работает на вас. Ниже — техническая аргументация, которую мы обычно проговариваем на первой встрече.

Вопрос, который нам задают чаще всего

Сравнение «три дня против трёх недель» кажется убедительным ровно до того момента, пока вы не заглядываете под капот. Конструкторы вроде Tilda, Wix и связки WordPress с тяжёлыми визуальными билдерами устроены так, чтобы любой человек без навыков программирования мог перетащить блок мышкой и получить результат. Это гениальная бизнес-модель и полезный инструмент — мы не собираемся его демонизировать. Но у этой универсальности есть цена, которую платите вы, а не платформа: чтобы «перетаскивание мышкой» работало для миллионов людей одновременно, движок вынужден генерировать максимально общий, избыточный и защищённый от ошибок код. Универсальное решение почти всегда проигрывает специализированному по производительности — это фундаментальный закон инженерии, а не наше мнение.

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

Сколько мусорного кода генерирует конструктор

Возьмём простейший элемент — обычную кнопку «Оставить заявку». В чистом коде это несколько строк: сам элемент <button>, немного стилей и один обработчик события. В конструкторе та же кнопка нередко оборачивается в пять-семь вложенных контейнеров <div>, каждый со своим служебным классом, атрибутами и инлайновыми стилями, потому что движку нужно уметь двигать, центрировать, анимировать и ресайзить этот элемент в редакторе. Вы видите одну кнопку — браузер разбирает целую матрёшку из тегов.

Теперь умножьте это на всю страницу. Каждая секция, каждый заголовок, каждая картинка обрастает служебной обвязкой. К разметке добавляются библиотеки «на всякий случай»: тяжёлый пакет для слайдеров, даже если слайдера на странице нет; библиотека анимаций целиком, даже если анимируется один блок; собственный движок сеток; полифилы для старых браузеров; аналитические скрипты платформы. В итоге вес абсолютно пустой страницы — просто шапка и один экран — легко достигает 5–10 мегабайт. Для сравнения: аккуратно собранная кастомная страница с тем же визуальным наполнением умещается в сотни килобайт, то есть в десять-двадцать раз легче.

Этот «мусор» — не эстетическая придирка перфекциониста. Каждый лишний килобайт нужно скачать через мобильную сеть, распарсить процессору телефона и отрисовать. Дешёвый смартфон в метро с неуверенным сигналом — это ваш реальный посетитель, а не абстракция. Он не будет ждать, пока прогрузится матрёшка из <div> и десяток ненужных библиотек. Он закроет вкладку.

Скорость, Core Web Vitals и SEO

Здесь техническая проблема превращается в деньги. И Google, и Яндекс давно ранжируют сайты не только по текстам и ссылкам, но и по реальному пользовательскому опыту, который измеряется метриками Core Web Vitals. Их три, и каждая напрямую страдает от избыточного кода конструктора.

LCP (Largest Contentful Paint) — время отрисовки самого крупного видимого элемента, по сути «когда страница выглядит загруженной». Чистый сайт на оптимизированном коде отдаёт первый экран за 0,1–0,3 секунды. Шаблонный сайт, который сначала тянет мегабайты скриптов, а потом из них собирает страницу, показывает контент за 2–4 секунды и больше. Разница — на порядок. INP (Interaction to Next Paint), пришедший на смену устаревшему FID, измеряет отзывчивость: как быстро страница реагирует на клик или ввод. Когда процессор телефона занят разбором тонны лишнего JavaScript, интерфейс «залипает», и INP проваливается. CLS (Cumulative Layout Shift) отвечает за визуальную стабильность — как сильно элементы «прыгают» во время загрузки. Тяжёлые шаблоны, которые дорисовывают блоки по мере подгрузки скриптов, славятся этими скачками, когда вы целитесь в одну кнопку, а нажимается другая.

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

Vendor lock-in: ловушка, из которой не выбраться

Предположим, скорость вас пока не пугает — сайт маленький, трафик небольшой. Есть вторая, более коварная проблема, и она проявляется именно тогда, когда бизнес начинает расти. Это vendor lock-in — привязка к платформе.

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

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

Кастомный код устроен ровно наоборот. Он написан на открытых, стандартных технологиях — например, Node.js на сервере и PostgreSQL в качестве базы данных — и является вашей интеллектуальной собственностью. Исходники передаются вам. Сайт можно развернуть на любом сервере, у любого провайдера, переехать в любой момент без потерь. Его можно наращивать бесконечно: сегодня это лендинг, через год — портал с личными кабинетами и внутренней аналитикой, и всё это на том же фундаменте, без переписывания с нуля. Вы вкладываете деньги не в аренду, а в актив, который остаётся с вами и растёт в цене вместе с бизнесом.

Когда конструктор — нормальный выбор

Будем честны до конца: конструктор — не абсолютное зло, и мы не советуем никому переплачивать из принципа. Если вам нужно за выходные собрать страницу-визитку для разовой акции, протестировать гипотезу перед запуском продукта или сделать простой одностраничник, который проживёт месяц, — конструктор отлично справится, и звать студию для этого странно. Инструмент нужно выбирать под задачу.

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

Частые вопросы

А если у меня уже есть сайт на конструкторе — всё пропало? Нет. Это рабочая точка старта: у вас есть проверенная структура и понимание, что конвертирует. Мы можем перенести смыслы и дизайн-идеи на чистый код, заодно исправив то, что тормозило скорость и SEO. Переезд — обычная и предсказуемая процедура.

Разве нельзя ускорить сайт на Tilda или WordPress, не переписывая с нуля? Частично да — сжать картинки, убрать часть скриптов, подключить кэширование. Но вы боретесь с архитектурой движка, а не с симптомами: мусорную разметку и лишние библиотеки, которые генерирует сам конструктор, оптимизацией до конца не убрать. Это лечение следствий, а не причины.

Кастомный сайт сложнее поддерживать без программиста? Наоборот, при правильной сборке им управляют через удобную панель, а редактирование текстов и картинок не требует навыков. Разница в том, что глубокие изменения делает разработчик по вашему коду, а не платформа по своим правилам — и вы всегда можете обратиться к любому исполнителю, потому что код открыт и стандартен.

Насколько реально быстрее чистый код? Речь идёт о разнице на порядок: сотни килобайт против мегабайтов, доли секунды на отрисовку против нескольких секунд. Это не проценты — это принципиально другой класс скорости, который поисковики и пользователи замечают сразу.

Коротко о главном

Разница между конструктором и кастомной разработкой — это не про красоту и не про амбиции перфекциониста. Конструктор ради удобства редактирования генерирует избыточный код, из-за которого страницы весят мегабайты и грузятся секундами, проваливают Core Web Vitals, теряют позиции в поиске и конверсию. Плюс вы попадаете в зависимость от платформы: сайт нельзя забрать, перенести и нарастить сложной логикой.

Мы пишем чистый код не из снобизма, а потому что отвечаем за результат: за скорость, за место в выдаче, за то, что сайт останется вашей собственностью и будет расти вместе с бизнесом. Если ваш сайт — рабочий инструмент, а не разовая визитка, эта разница окупается. Если хотите обсудить, что именно нужно вашему проекту, — напишите нам, и мы разберём вашу задачу без обязательств.