Сайт на Тильде долго грузится: что реально ускорить

Сайт на Тильде долго грузится, и почти всегда дело не в самой платформе, а в том, как страница собралась за годы правок. Я веду поддержку нескольких Tilda-проектов и вижу одну и ту же картину: десяток блоков с фоновым видео, три шрифта с четырьмя начертаниями каждый, скрипты чатов и эквайринга в head, которые запускаются раньше основного контента. Разберу, что реально влияет на скорость и что стоит проверить в первую очередь, прежде чем думать о переезде на другую платформу.

Почему сайт на Тильде медленно загружается: главные причины

Прежде чем что-то трогать, я всегда прогоняю страницу через PageSpeed Insights и смотрю на разбивку по времени: сколько уходит на изображения, сколько блокирует рендер JS, где узкое место в LCP. В девяти случаях из десяти проблема укладывается в 3-5 типовых причин, и все они видны в этой разбивке без доступа к коду.

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

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

Изображения и Zero Block: где теряется скорость загрузки

Изображения обычно дают больше половины веса страницы. Тильда сжимает картинки при загрузке автоматически, но алгоритм ориентируется на разрешение и формат исходника, а не угадывает, насколько крупно картинка реально показывается на экране. Если загрузить фото 4000 на 3000 пикселей в блок шириной 800 пикселей, браузер всё равно скачает файл в полном размере. Статику Тильда раздаёт через собственный CDN, так что сама доставка файла до пользователя обычно не узкое место, тормозит именно вес самого файла, который приходится обрабатывать браузеру при первом рендере.

На практике я делаю так: экспортирую изображение в 2x от реальной ширины блока, сохраняю в JPEG с качеством 60-80% или в WebP, если дизайн такое допускает. Для интернет-магазина на Tilda с карточками товаров это снижает вес каталожной страницы в разы без видимой потери качества.

Отдельно проверяю фоновые видео в Zero Block. Автовоспроизводимый ролик на весь экран - частая причина медленного LCP на мобильном, потому что браузер обязан скачать хотя бы первый кадр до момента, который замеряет метрика. На длинных лендингах с историей компании встречал по 4-5 фоновых роликов сразу, и суммарный вес такой страницы легко переваливал за 20 МБ ещё до текста. Если видео декоративное, я меняю его на статичную картинку с кнопкой воспроизведения, а сам ролик подключаю по клику.

Скрипты и код в head, которые тормозят сайт на Tilda

На втором месте по вкладу в медленную загрузку - сторонний JS. За годы на сайт обычно накапливаются: код Яндекс.Метрики, пиксель ВКонтакте, виджет чата, скрипт эквайринга вроде Т‑Банка для приёма оплаты, калькулятор доставки СДЭК. Каждый из них - отдельный запрос, и если все они лежат в head, браузер ждёт их ответа до того, как начнёт показывать сам контент.

В настройках сайта в Tilda есть разделение: код можно вставить в head, а можно в поле «перед /body», это футер, который выполняется уже после отрисовки основного контента. Я переношу туда всё, что не обязано работать мгновенно: чаты, счётчики аналитики, отложенные виджеты. В head оставляю только то, что реально должно сработать до первой отрисовки, например верификационные метатеги.

На одном из проектов с приёмом оплаты через Т‑Банк и расчётом доставки через калькулятор СДЭК в head оказалось шесть отдельных тегов script, из которых для первого отображения контента не был нужен ни один. После переноса всех в футер время до интерактивности страницы заметно сократилось, а сама оплата и расчёт доставки продолжили работать без изменений, потому что тело скрипта осталось тем же, поменялось только место его запуска.

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

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

Шрифты, видео и анимации: что урезать без потери дизайна

Каждое подключённое начертание шрифта - отдельный файл, который браузер должен скачать до того, как покажет текст этим шрифтом. Если в проекте три семейства и у каждого подключены Light, Regular, Medium и Bold, набегает 10-12 запросов только на типографику. Я обычно оставляю одно акцентное семейство для заголовков и одно для текста, максимум с двумя-тремя начертаниями каждое, этого хватает почти для любого дизайна.

Анимации при скролле и параллакс-эффекты в Zero Block недорогие сами по себе, но их количество имеет значение: если на странице 30 анимированных элементов, браузер держит 30 обработчиков события скролла одновременно. Я оставляю анимацию там, где она реально работает на восприятие, и убираю с второстепенных секций.

Настройки Тильды, которые ускоряют загрузку страницы

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

Дальше смотрю на структуру страницы: количество Zero Block-секций, повторяющиеся блоки, которые можно объединить в один с вариациями. И отдельно на мобильную версию: если под неё не настроены отдельные, более лёгкие изображения, телефон скачивает ту же картинку, что и десктоп, просто сжимая её на экране.

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

Когда чистки уже недостаточно: кастомная оптимизация Tilda

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

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

Я беру такие задачи как кастомную доработку Tilda: простая правка вроде переноса скриптов из head или ручного сжатия партии изображений обычно укладывается в цену от 3 000 ₽, а комплексная работа с интеграциями (эквайринг, CRM, доставка) - от 40 000 ₽, потому что там приходится проверять, что оптимизация не ломает передачу данных в сторонние сервисы.

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

Условия и возможности Тильды меняются, поэтому перед запуском я уточняю их у самого сервиса.

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

Сколько времени занимает оптимизация скорости сайта на Tilda?

Чистка изображений, перенос скриптов из head и настройка шрифтов на одном лендинге у меня обычно занимает от одного до двух дней, включая проверку, что после правок ничего не сломалось - формы, оплата, интеграции с СДЭК. Комплексный аудит на сайте с десятками страниц и историей в несколько лет займёт дольше, потому что приходится разбирать код блок за блоком.

Влияет ли скорость сайта на позиции в поиске?

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

Можно ли ускорить сайт, не трогая дизайн?

Да, большая часть правок из этой статьи не меняет визуал: сжатие изображений в тех же пропорциях, перенос скриптов из head в футер, включение отложенной подгрузки. Дизайн затрагивается только там, где я сознательно предлагаю заменить автовоспроизводимое фоновое видео на статичную картинку с кнопкой запуска.

Что делать, если после чистки сайт всё равно долго грузится?

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