Доработка Zero-блока в Тильде - как раз с этого чаще всего начинается разговор с клиентом, у которого сайт уже собран на конструкторе, а стандартных настроек блока не хватает. Кому-то нужна форма с валидацией и маской телефона, кому-то расчёт стоимости доставки СДЭК прямо на странице, кому-то анимация появления блоков при скролле, которой из коробки в Zero нет. За практику с Тильдой я перебрал десятки таких задач и знаю, где хватит десяти строк CSS, а где нужна полноценная интеграция с внешним сервисом.
Что не умеет Zero-блок из коробки
Zero - самый гибкий блок в Тильде, но гибкость касается вёрстки, а не логики. В нём легко подвинуть элемент на пиксель, поменять шрифт или собрать нестандартную сетку. А вот условная логика («если выбран регион X, показать поле Y»), запросы к внешним API, сложная валидация полей формы или пересчёт суммы заказа на лету - это уже зона кастомного кода.
На практике задачи разбиваются на три группы:
- Косметика - стили, отступы, шрифты, поведение на мобильных. Решается CSS и минимальным JS.
- Логика форм - маски, валидация, условное отображение полей, отправка в CRM в нужном формате.
- Интеграции - расчёт доставки СДЭК, приём оплаты через эквайринг, уведомления в Telegram при новой заявке.
Первая группа занимает час-два и стоит от 3 000 ₽. Третья - это уже отдельный проект с тестированием на реальных сценариях, от 40 000 ₽, потому что ошибка в обработке ответа СДЭК или эквайринга means клиент либо не получит расчёт доставки, либо деньги спишутся, а заказ не создастся.
Кастомизация стилей Zero-блока: типографика и адаптив
Самая частая заявка - «на телефоне всё едет». Zero собирает вёрстку по брейкпоинтам конструктора, но если внутри блока есть кастомные элементы (кнопки, карточки, галерея), стили под 320-375px конструктор не всегда просчитывает корректно. Плюс частая проблема - шрифт инпутов формы меньше 16px, из-за чего iOS Safari зумит страницу при фокусе на поле.
Правлю это точечными медиа-запросами через блок T123 (HTML-код) или панель «Ещё → Вставка кода»:
@media screen and (max-width: 640px) {
.tn-atom[data-field="text"] {
font-size: 16px !important;
line-height: 1.4 !important;
}
.t-form__inp {
height: 44px !important;
}
.t-form__submit {
width: 100% !important;
}
}
Важный нюанс: классы вида rec123456, которые Тильда генерирует для конкретного блока, меняются, если блок пересобрать или скопировать на другую страницу. Стили лучше вешать на устойчивые селекторы (data-field, свои кастомные классы через настройки блока), а не на автоматически сгенерированные ID - иначе после любой правки вёрстки в редакторе CSS отвалится.
Доработка форм в Zero-блоке: маски, валидация, вебхуки
Вторая по частоте задача - форма ведёт себя не так, как нужно бизнесу. Стандартная валидация Тильды - это «обязательное поле» и проверка формата email/телефона. Маску под российский номер, проверку ИНН, условную логику (поле «Название компании» появляется только при выборе «Юридическое лицо») из коробки не будет.
Маска телефона через JS без сторонних библиотек:
document.addEventListener('DOMContentLoaded', function () {
var phoneInput = document.querySelector('input[name="Phone"]');
if (!phoneInput) return;
phoneInput.addEventListener('input', function (e) {
var digits = e.target.value.replace(/D/g, '').slice(0, 11);
var formatted = '+7 (' + digits.slice(1, 4) + ') ' + digits.slice(4, 7) + '-' + digits.slice(7, 9) + '-' + digits.slice(9, 11);
e.target.value = formatted.replace(/[()-]s*$/, '').trim();
});
});
Отдельная история - отправка данных не туда, куда встроенная интеграция Тильды умеет из коробки. Тильда шлёт лид в почту, Telegram или ограниченный список CRM через нативные настройки. Если нужен amoCRM с кастомными полями, Bitrix24 с привязкой к конкретной воронке или просто вебхук в n8n для дальнейшей маршрутизации - форму дорабатываю так, чтобы она параллельно с нативной отправкой стучалась в нужный вебхук.
form.addEventListener('submit', function () {
var data = new FormData(form);
fetch('https://n8n.example.ru/webhook/tilda-order', {
method: 'POST',
body: JSON.stringify(Object.fromEntries(data)),
headers: { 'Content-Type': 'application/json' }
});
});
Обратите внимание: тут я не вызываю preventDefault - форма продолжает отправляться штатным способом Тильды (письмо, встроенная CRM-интеграция), а вебхук уходит параллельно. Это частая ошибка в самодельных доработках - перехватывают submit, гасят его, а потом забывают вызвать оригинальную логику, и лид просто теряется.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
JS-анимации и интерактивные эффекты в Zero-блоке
Анимация появления блоков при скролле, параллакс на изображении, кастомный слайдер отзывов - типовой набор, который в готовых блоках Тильды либо ограничен пресетами, либо отсутствует. Использую IntersectionObserver вместо scroll-листенеров - не грузит браузер на длинных страницах-лендингах:
var targets = document.querySelectorAll('.zero-fade');
var observer = new IntersectionObserver(function (entries) {
entries.forEach(function (entry) {
if (entry.isIntersecting) {
entry.target.classList.add('zero-fade--visible');
observer.unobserve(entry.target);
}
});
}, { threshold: 0.2 });
targets.forEach(function (el) { observer.observe(el); });
Класс zero-fade вешаю на нужные элементы прямо в настройках блока (поле «Доп. класс» есть у большинства элементов Zero), а CSS-переход описываю отдельно - opacity и transform, без анимации height, чтобы не дёргалась вёрстка на мобильных. Похожие готовые скрипты для типовых сценариев (появление при скролле, счётчики, аккордеоны без плагинов) у меня собраны в библиотеке готовых скриптов для Тильды - часть задач закрывается без написания кода с нуля, просто вставкой готового блока с адаптацией под конкретную вёрстку.
Кастомный слайдер вместо стандартной галереи
Стандартная галерея Тильды не умеет, например, показывать по 3.5 карточки с обрезкой следующей - приём, который увеличивает CTR по кликам на карусель за счёт визуальной подсказки «тут ещё есть контент». Такие вещи собираю на нативном JS без подключения тяжёлых библиотек типа Swiper, если функциональности достаточно свайпов и стрелок - страница грузится быстрее, а лишний скрипт на 40-60 Кб не тянется ради одной карусели.
Интеграция Zero-блока с СДЭК, эквайрингом и уведомлениями
Самые дорогие по времени доработки - не косметика, а интеграции с внешними сервисами. Три сценария встречаются регулярно:
| Задача | Что делаю | Ориентир по срокам |
|---|---|---|
| Расчёт доставки СДЭК на странице | Запрос к API СДЭК по адресу, вывод стоимости и сроков прямо в форме заказа | 2-4 дня |
| Приём оплаты | Виджет эквайринга (например, T‑Bank) поверх формы Zero, обработка статуса оплаты | 3-5 дней |
| Уведомления о заявке | Вебхук из формы в n8n → маршрутизация в Telegram-бот на aiogram или в CRM | 1-2 дня |
Пример: интернет-магазин на Тильде с товарами, где нужен точный расчёт доставки СДЭК до пункта выдачи. Стандартная форма Zero про доставку ничего не знает - она просто собирает поля. Добавляю скрытое поле, которое подтягивает тариф через прокси-сервер (прямые запросы к API СДЭК с фронтенда не сделать из-за CORS и авторизации), и обновляю итоговую сумму заказа при выборе города.
Для уведомлений часто беру n8n как связующее звено: вебхук из Тильды падает в n8n, там разбирается по условиям (сумма заказа, регион, наличие комментария), и дальше уходит либо в CRM, либо ботом в Telegram менеджеру. Так не приходится городить логику маршрутизации прямо в JS на сайте - она живёт в отдельном сервисе, который проще менять без правок кода на самом лендинге.
Частые ошибки при доработке zero-блока в Тильде
| Ошибка | Почему возникает | Как избежать |
|---|---|---|
| Скрипт вставлен в каждый блок отдельно | Копипаст кода на несколько страниц вместо общего файла | Выносить общий JS в «Настройки сайта → Ещё → Вставка кода», а не дублировать в T123 на каждой странице |
| Конфликт с нативным обработчиком формы | preventDefault без вызова оригинальной логики отправки | Отправлять кастомный запрос параллельно, не гасить штатный submit |
| Стили привязаны к автогенерируемым классам | CSS написан под rec123456, который меняется при пересборке блока | Использовать data-атрибуты и собственные классы из настроек блока |
| Скрипт не протестирован на мобильной версии | Тильда рендерит мобильную и десктопную версию по-разному, DOM отличается | Проверять на реальном экране, а не только в режиме предпросмотра |
Отдельно про обновления платформы: Тильда время от времени меняет внутреннюю структуру Zero-блока - добавляет атрибуты, меняет порядок обёрток. Скрипт, написанный полгода назад под конкретный data-атрибут, может однажды перестать находить нужный элемент. Это не значит, что доработку нужно переписывать каждый месяц, но если сайт активно используется и приносит заявки, за такими вещами стоит следить - особенно после того, как в Тильде выкатили заметное обновление редактора.
Когда стандартных блоков не хватает
Кастомный скрипт
от 3 000 ₽
Подробнее →Частые вопросы
Сколько стоит доработка Zero-блока в Тильде?
Простая доработка - маска на телефон, кастомный стиль, готовая анимация без интеграций - от 3 000 ₽. Комплексная интеграция с CRM, эквайрингом или расчётом доставки СДЭК - от 40 000 ₽, потому что добавляется работа с внешним API, обработка ошибок и проверка на разных сценариях оформления заказа, а не только на «счастливом пути».
Можно ли дорабатывать Zero-блок без знания программирования?
Часть задач закрывается через панель Тильды: отступы, стили, готовые анимации из встроенного набора эффектов. Как только нужна логика - условия, запросы к API, валидация сложнее «обязательное поле» - без JS не обойтись, и разумнее отдать это разработчику, чем разбираться методом проб на живом сайте с реальными заявками.
Как добавить кастомный скрипт в Zero-блок, чтобы он не сломался после обновления Тильды?
Вставлять код через блок T123 или панель «Настройки сайта → Ещё → Вставка кода», не завязываться на автоматически сгенерированные классы вроде rec123456, и обязательно тестировать поведение отдельно на мобильной версии - верстка там формируется по другим правилам, чем на десктопе.
Что делать, если после доработки форма перестала отправляться в CRM?
Первым делом проверить, не перехватывает ли добавленный скрипт submit формы через preventDefault без вызова оригинальной логики отправки Тильды - это самая частая причина потери лидов после кастомизации. Вторая по частоте причина - CRM ждёт поля в другом формате, чем отправляет форма после доработки, и вебхук просто не проходит валидацию на стороне CRM.