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

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

Что определяет скорость загрузки сайта на Тильде

Скорость страницы на Тильде складывается из нескольких независимых вещей, и работать с ними нужно по отдельности.

• Вес и формат картинок на странице.
• Количество и сложность блоков, особенно собранных в Zero Block.
• Сторонние скрипты: счётчики, чаты, виджеты соцсетей, пиксели рекламных кабинетов.
• Шрифты, если на сайт подключены нестандартные семейства.
• Видео и анимации в фоне блоков.
• Сервер и CDN, через которые отдаётся статика, это уже зона ответственности платформы.

Из этого списка платформа отвечает только за последний пункт. Статика на Тильде отдаётся через CDN, и на эту часть повлиять нельзя, да и не нужно, с ней всё в порядке. Всё остальное собирает тот, кто наполняет сайт, и именно там чаще всего теряются секунды загрузки.

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

Изображения - главный источник лишнего веса страницы

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

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

Что делаю на практике перед загрузкой в Тильду:

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

Отдельно проверяю favicon и мелкие декоративные иконки: если их десяток и каждая весит по 200-300 КБ вместо SVG на пару килобайт, набегает заметная задержка ещё до того, как пользователь увидел основной контент.

Zero Block и перегруженная вёрстка замедляют рендеринг

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

Что стоит проверить в такой вёрстке:

• Не размножены ли одинаковые анимации на каждый элемент блока вместо одной общей.
• Не остался ли в кастомном коде блока JS или CSS от предыдущей версии дизайна.
• Не вложены ли контейнеры друг в друга там, где хватило бы одного уровня.

Кастомный код, вставленный через настройки сайта в раздел «перед