Адаптивная версия сайта на Tilda в большинстве случаев собирается автоматически - конструктор растягивает и сжимает блоки под ширину экрана без единой строчки CSS с вашей стороны. Но именно эта автоматика чаще всего подводит: на десктопе макет выглядит ровно так, как задумал дизайнер, а на iPhone кнопка оплаты уезжает за край экрана, текст наезжает на картинку, а форма заявки схлопывается в нечитаемую полоску. За несколько лет доработки чужих Tilda-сайтов я собрал список ошибок, которые повторяются от проекта к проекту - от интернет-магазинов с интеграцией СДЭК до лендингов с формой на Т‑Банк-эквайринге. Разбираю их по порядку, с конкретными причинами и способами починить.
Как Tilda считает брейкпоинты и почему адаптив не работает «из коробки»
Конструктор делит макет на пять брейкпоинтов: Desktop (от 1200 px), Notebook (980‑1199 px), Tablet (768-979 px), Tablet vertical (640-767 px) и Smartphone (320-479 px). Каждый блок в редакторе настраивается отдельно под каждый брейкпоинт - можно сдвинуть отступы, изменить размер шрифта, спрятать элемент. Проблема в том, что при редактировании десктопной версии Tilda не пересчитывает настройки для остальных четырёх автоматически везде: текст, картинки и ссылки наследуются, а отступы, позиционирование в Zero Block и порядок колонок остаются такими, какими их настроили в последний раз вручную. Отсюда и берутся разъехавшиеся макеты - правки внесли на десктопе, а на планшете блок живёт по настройкам прошлой версии сайта.
Ошибка №1 - блоки наезжают друг на друга при сужении экрана
Чаще всего это Zero Block с абсолютным позиционированием элементов в пикселях. На десктопе бейдж «Скидка 20%» стоит ровно над ценой, а на Tablet vertical при сужении контейнера тот же бейдж съезжает поверх заголовка карточки, потому что координаты заданы фиксированными числами, а не процентами от ширины блока. Похожая история с отрицательными отступами: дизайнер вытянул картинку за пределы блока на десктопе через margin с минусом, и на мобильном брейкпоинте эта же картинка перекрывает соседний текстовый блок.
Чиню так: прохожу каждый брейкпоинт вручную через переключатель в редакторе, а не только через режим «мобильный предпросмотр» - он показывает лишь Smartphone и часто скрывает баги на Tablet и Tablet vertical. Элементы Zero Block с абсолютным позиционированием перевожу на проценты или на выравнивание группой вместо фиксированных координат.
Ошибка №2 - картинки и видео не оптимизированы под мобильный трафик
Вторая по частоте проблема - retina-картинки 2x, залитые в оригинальном весе, и фоновые видео, которые автоматически проигрываются даже на мобильном брейкпоинте. На одном лендинге фоновое видео в карточке товара весило 14 МБ, и на мобильной сети PageSpeed для мобильной версии падал до 35-40 баллов просто из-за этого одного элемента.
Правлю через отдельную опцию Tilda «мобильная версия изображения» - она подгружает под Smartphone и Tablet vertical сжатую версию картинки вместо десктопной. Автовоспроизведение видео на мобильном брейкпоинте отключаю и заменяю статичным превью, а тяжёлые изображения конвертирую в webp - обычно это сразу минус 40-60% веса без потери качества на глаз.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Ошибка №3 - «скрытый» на мобильной версии блок продолжает грузиться
Опция «скрыть на мобильной версии» в Tilda ставит блоку display:none, но не всегда отменяет загрузку тяжёлых файлов внутри него. Слайдер из восьми изображений по 400 КБ, спрятанный на телефоне, всё равно тянется в фоне и съедает трафик пользователя и время до первой отрисовки контента. То же самое касается скриптов сторонних виджетов внутри HTML-блока - если сам скрипт не проверяет ширину экрана, он выполнится независимо от того, виден блок или нет.
Вместо простого скрытия делаю разный контент под разные брейкпоинты через настройки блока с ленивой загрузкой, а тяжёлые декоративные элементы, которые не нужны на телефоне, удаляю из мобильной версии целиком, а не прячу.
Ошибка №4 - формы и виджеты интеграций не подстраиваются под узкий экран
Самая неприятная категория, потому что от неё зависят деньги клиента. Виджет калькулятора доставки СДЭК, вставленный через HTML-блок с фиксированной шириной 720px, на брейкпоинте 640 px обрезается по правому краю - пользователь физически не видит кнопку «Рассчитать». Форма оплаты через Т‑Банк-эквайринг иногда ведёт себя так же: iframe не резинится под контейнер, и на планшете часть полей уходит за экран с горизонтальным скроллом.
Отдельная беда - размер тап-зон. Кнопка «Оставить заявку» высотой 28 px отлично смотрится на десктопе, но на телефоне в неё почти невозможно попасть пальцем: рекомендованный минимум для тач-интерфейса - около 44 px по высоте.
Чиню так: оборачиваю виджет в контейнер с max-width: 100% и убираю фиксированные px-значения из вставленного кода, увеличиваю кнопки и поля форм на брейкпоинтах Tablet vertical и Smartphone, тестирую не только в браузере, а на реальном телефоне - тач-зоны и поведение клавиатуры эмулятор показывает неточно.
Ошибка №5 - кастомные скрипты игнорируют брейкпоинты Tilda
Калькуляторы стоимости, кастомные слайдеры, чат-виджеты, вставленные через код в блок T123 - частая причина, почему адаптив разваливается именно на границе брейкпоинтов. Скрипт задаёт ширину инпутов в пикселях внутри своего JS, а не в процентах, и на Tablet vertical поля калькулятора вылезают за контейнер, хотя сама верстка Tilda вокруг них выглядит нормально. Чинил похожий калькулятор клиенту: проблема была именно в захардкоженных 320px на инпут, которые никак не реагировали на сужение блока.
Правильный подход - привязывать media-запросы кастомного кода к тем же точкам, что использует сама Tilda (1199px, 979px, 767px, 479px), а не выдумывать свои произвольные значения:
@media screen and (max-width: 767px) {
.custom-calculator__input {
width: 100%;
}
}
@media screen and (max-width: 479px) {
.custom-calculator__button {
min-height: 44px;
}
}Если не хочется отлаживать чужой скрипт с нуля, проще взять готовые скрипты для Tilda с проверенной адаптивностью - там верстка уже прогнана по всем пяти брейкпоинтам и не ломается на границах. Точечная доработка готового скрипта под конкретный дизайн у меня стоит от 3 000 ₽, а комплексная интеграция вроде связки калькулятора с CRM, эквайрингом или СДЭК - от 40 000 ₽, потому что там правки идут не только в верстке, но и в логике самой интеграции.
Чек-лист проверки адаптивной версии перед публикацией
Прогоняю по этой таблице любой Tilda-проект перед сдачей клиенту:
| Брейкпоинт | Ширина | Что проверяю в первую очередь |
|---|---|---|
| Desktop | от 1200 px | Базовая верстка, анимации, работа интеграций (СДЭК, эквайринг, CRM) |
| Notebook | 980‑1199 px | Отступы блоков, не съехали ли колонки и меню |
| Tablet | 768-979 px | Ширина форм и виджетов интеграций, читаемость таблиц |
| Tablet vertical | 640-767 px | Наложение текста на картинки, элементы Zero Block |
| Smartphone | 320-479 px | Размер тап-зон кнопок, вес страницы, действительно ли скрыты скрытые блоки |
Если хотя бы одна строка не пройдена, я не считаю адаптив готовым, даже если десктопная версия выглядит идеально.
От лендинга до интернет-магазина
Сайт / Tilda
от 30 000 ₽
Подробнее →Частые вопросы
Сколько стоит адаптивная верстка сайта на Tilda?
Если делаю сайт с нуля, адаптивная версия входит в стоимость проекта - от 30 000 ₽, тестирование по всем пяти брейкпоинтам входит в работу без отдельной доплаты. Если нужно поправить адаптив на готовом сайте, точечная доработка блока или скрипта обойдётся от 3 000 ₽, а если проблема в комплексной интеграции - эквайринге, СДЭК, CRM - расчёт идёт от 40 000 ₽, потому что правки затрагивают не только верстку, но и саму логику интеграции.
Как проверить адаптивность сайта на Tilda без сторонних сервисов?
В редакторе Tilda есть переключатель брейкпоинтов сверху экрана - прогоняю макет по каждому из пяти вручную, а не только через режим «мобильный предпросмотр», который показывает лишь один вариант и прячет баги на Tablet и Tablet vertical. Отдельно открываю сайт на реальном телефоне и планшете: эмулятор в браузере не всегда точно показывает проблемы с тап-зонами и поведением клавиатуры в формах.
Можно ли использовать Zero Block и сохранить нормальную адаптивность?
Можно, но Zero Block требует ручной проверки каждого элемента на каждом брейкпоинте отдельно - там нет автоматического пересчёта позиций, как в обычных блоках Tilda. Если элемент позиционирован абсолютно в пикселях, при сужении экрана он поедет поверх текста или картинки. Такие элементы я перевожу на проценты от ширины контейнера или заменяю абсолютное позиционирование групповым выравниванием.
Что делать, если после подключения СДЭК или эквайринга верстка съезжает на мобильных?
Обычно причина в фиксированной ширине iframe или контейнера, который вставили в HTML-блок без привязки к ширине экрана. Оборачиваю виджет в контейнер с max-width: 100% и убираю жёсткие px-значения из вставленного кода. Если виджет всё равно не тянется под контейнер - это ограничение самого скрипта интеграции, и тогда нужна точечная доработка на стороне кода, а не правка в визуальном редакторе Tilda.