Сравнений WordPress и Tilda в интернете уже достаточно. Обычно они сводятся примерно к одному и тому же набору критериев: стоимость, простота освоения, скорость создания сайта, SEO, количество шаблонов и необходимость заниматься техническим обслуживанием.
В результате вывод тоже часто получается предсказуемым: Tilda проще и быстрее, а WordPress сложнее, зато гибче.
Но если посмотреть на эти платформы глазами веб-разработчика, разница находится немного в другом месте.
Она становится особенно заметной, когда сайт перестаёт быть набором из пяти-десяти страниц и на нём появляются повторяющиеся данные: услуги, проекты, сотрудники, объекты, товары, характеристики, отзывы. А затем эти данные начинают зависеть друг от друга.
Поэтому в этой статье я хочу сравнить WordPress и Tilda не столько по внешним возможностям, сколько по их внутренней логике:
- где и как существует сайт;
- как организован динамический контент;
- насколько контент отделён от дизайна;
- что может изменить разработчик;
- кому принадлежит сама инфраструктура;
- и что происходит, когда проект постепенно усложняется.
Сразу оговорюсь: задача статьи — не доказать, что одна платформа хорошая, а другая плохая. Это разные инструменты, и у каждого есть проекты, для которых он подходит лучше.
WordPress и Tilda — изначально разные продукты
Начать стоит с самого принципиального различия.
WordPress — это CMS с открытым исходным кодом.
Сам WordPress распространяется по лицензии GPLv2 или более поздней версии. Его можно установить на подходящий хостинг или собственный сервер, переносить между серверами, изучать и изменять код, создавать собственные темы и плагины. Для работы WordPress используются PHP и база данных MySQL или MariaDB.
Упрощённо архитектура выглядит так:
Домен
↓
Хостинг / VPS
↓
PHP + MySQL / MariaDB
↓
WordPress
↓
Тема + плагины + собственный код
↓
Сайт
Tilda устроена по-другому.
Это платформа, предоставляемая как сервис. Пользователь регистрируется, создаёт проект внутри инфраструктуры Tilda и использует предоставленные платформой инструменты: стандартные блоки, Zero Block, формы, Каталог, Потоки, CMS Потоки и другие модули.
В пользовательском соглашении сама Tilda называется именно Платформой, использование которой регулируется соглашением между пользователем и компанией Tilda Platform Cloud Services Co. LLC.
Схематично:
Домен
↓
Инфраструктура Tilda
↓
Проект
↓
Блоки / Zero Block / CMS Потоки
↓
Сайт
Разница кажется небольшой, пока мы просто открываем сайт в браузере.
Но архитектурно это два разных подхода.
В случае WordPress CMS является программной частью самого проекта.
В случае Tilda проект существует внутри предоставляемой CMS-платформы.
И это различие дальше влияет практически на всё.
Для обычного лендинга эта разница может вообще не иметь значения
Представим типичный сайт компании:
- первый экран;
- преимущества;
- несколько услуг;
- фотографии;
- отзывы;
- FAQ;
- форма заявки;
- контакты.
Такой сайт можно качественно сделать и на WordPress, и на Tilda.
Для посетителя вообще неважно, какая технология работает внутри. Он видит дизайн, читает информацию, нажимает кнопку и отправляет заявку.
Более того, для небольшого проекта SaaS-подход Tilda может быть очень удобным.
Не нужно отдельно выбирать хостинг, устанавливать CMS, следить за версиями PHP, обновлять ядро, контролировать совместимость плагинов и заниматься частью серверных вопросов.
Пока сайт состоит преимущественно из вручную созданных страниц, сравнивать платформы на уровне архитектуры действительно не очень интересно.
Гораздо интереснее становится после фразы:
А теперь добавим на сайт 50 услуг.
Страница и данные — не одно и то же
Допустим, у компании есть услуги.
Для каждой нужны:
- название;
- краткое описание;
- стоимость;
- срок выполнения;
- изображение;
- подробное описание;
- несколько преимуществ.
Самый прямолинейный способ — создать отдельную страницу для каждой услуги и вручную менять на ней текст.
Получается примерно так:
Страница «Разработка сайта»
Страница «Интернет-магазин»
Страница «Техническая поддержка»
Страница «SEO»
...
Пока страниц пять — никаких проблем.
Когда их становится 50, а потом нужно изменить дизайн всех карточек или добавить новое поле, ручная модель начинает создавать лишнюю работу.
В CMS обычно применяется другой принцип:
Данные услуги
↓
Единый шаблон
↓
Готовая страница
Например, в базе хранится:
Название: Интернет-магазин
Цена: от 150 000 ₽
Срок: 4–6 недель
Изображение: shop.jpg
Описание: ...
А оформление страницы создаётся один раз.
После этого новый элемент контента — это уже не новая вручную собранная страница, а новая запись в определённой структуре данных.
Это и есть один из фундаментальных принципов CMS: отделение данных от их представления.
И здесь современные Tilda и WordPress уже гораздо ближе друг к другу, чем принято считать.
Динамический контент в современной Tilda
Ещё недавно во многих сравнениях Tilda описывали практически исключительно как конструктор страниц.
С появлением настраиваемых CMS Потоков такое описание уже устарело.
Tilda позволяет создать CMS Поток с собственным набором полей или использовать готовую структуру. После этого в Потоке создаются записи, каждая из которых заполняет одну и ту же схему данных.
Например, можно создать CMS Поток:
Услуги
и определить поля:
Название
Цена
Срок
Краткое описание
Изображение
Подробное описание
Популярная услуга
То есть редактор уже работает не с произвольной страницей, а с понятной формой.
Вместо необходимости каждый раз искать нужный текстовый блок на странице он получает условно такую административную модель:
Название: ______________________
Цена: __________________________
Срок: __________________________
Изображение: [ выбрать ]
Описание:
________________________________
________________________________
Популярная услуга: [ ✓ ]
Это уже вполне классический CMS-подход.
Один шаблон для множества записей
Следующий важный момент — представление данных.
Для CMS Потока можно создать единый шаблон страницы в Zero Block и связать его элементы с полями записи.
Допустим:
Заголовок ← Название
Цена ← Цена
Текст ← Описание
Изображение ← Изображение
После этого один шаблон используется для разных записей.
Создадим 50 услуг — их не потребуется собирать в Zero Block 50 раз.
Меняем данные конкретной услуги — меняется её содержимое.
Меняем сам шаблон — изменения применяются к страницам записей, использующим его.
Это очень важный момент: современная Tilda уже умеет отделять данные от дизайна.
Поэтому утверждение в духе «на Tilda каждую динамическую страницу нужно создавать вручную» сегодня будет некорректным. CMS Потоки поддерживают собственную структуру полей, динамический вывод и шаблонное представление данных.
Динамические списки тоже есть
Динамика нужна не только на самой странице услуги.
На главной, например, может находиться блок:
Наши услуги
Вручную создавать каждую карточку необязательно.
Tilda позволяет подключить CMS Поток к подходящему стандартному блоку либо построить собственную динамическую карточку в Zero Block.
Получается схема:
CMS Поток
↓
Выборка записей
↓
Шаблон карточки
↓
Карточка №1
Карточка №2
Карточка №3
...
То есть во многих типичных задачах Tilda сейчас действительно ведёт себя именно как CMS.
Можно создать, например:
- Услуги;
- Проекты;
- Команду;
- FAQ;
- Новости;
- Кейсы.
И управлять ими отдельно от дизайна страниц.
Это важно признать прежде, чем переходить к сравнению с WordPress.
Как та же задача выглядит в WordPress
У WordPress динамическая модель контента существует на более низком уровне самой CMS.
В основе используются несколько базовых сущностей:
- Post Types;
- Taxonomies;
- Metadata;
- Users и другие объекты WordPress.
Для структурированного сайта особенно интересны первые три.
Например, нам нужны услуги.
Можно зарегистрировать собственный тип записей:
service
или в интерфейсе назвать его просто:
Услуги
Стандартный WordPress поддерживает Custom Post Types на уровне ядра, а дополнительные инструменты позволяют создавать их без необходимости каждый раз писать регистрацию вручную.
В этой серии статей для примеров я буду использовать Secure Custom Fields — SCF.
SCF позволяет создавать и управлять собственными Post Types, Taxonomies и наборами полей через административный интерфейс.
Получается похожая структура:
CPT: Услуги
Поля SCF:
— цена
— срок
— изображение
— краткое описание
— преимущества
А дальше создаётся шаблон страницы услуги.
В зависимости от проекта это может быть PHP-шаблон темы, Gutenberg, Bricks, Elementor или другой frontend-инструмент.
Смысл один:
Запись WordPress
↓
Custom Fields
↓
Шаблон
↓
Страница
На этом уровне подходы WordPress + SCF и Tilda CMS Потоки действительно похожи.
Именно поэтому я бы не стал проводить границу между платформами по принципу:
WordPress умеет динамику, а Tilda — нет.
Сегодня это просто неверно.
Граница находится дальше.
Пока у нас одна сущность, обе системы чувствуют себя нормально
Представим простую структуру:
Услуги
У каждой услуги есть десять полей.
Нужно создать 30 записей и вывести их по одному шаблону.
Tilda CMS Потоки такую задачу решают.
WordPress + SCF — тоже.
То же самое можно попробовать сделать с:
Проектами
или:
Специалистами
И снова обе системы способны хранить структурированные данные и выводить их через шаблон.
Поэтому настоящее различие становится интереснее не тогда, когда данных много, а когда данные начинают взаимодействовать между собой.
Представим уже не одну сущность, а четыре:
Услуги
Проекты
Специалисты
Отзывы
Допустим, у нас есть проект.
У него:
- есть одна или несколько услуг;
- есть специалисты, которые над ним работали;
- есть отзыв клиента.
Теперь структура начинает выглядеть так:
Услуга ←→ Проект ←→ Специалист
↓
Отзыв
И вот здесь мы выходим из области простых пользовательских полей в область моделирования данных.
WordPress: Post Types, Taxonomies и Custom Fields
В WordPress для подобных задач можно использовать разные типы данных по их назначению.
Например:
CPT: services
CPT: projects
CPT: specialists
CPT: reviews
Но одних типов записей недостаточно.
Допустим, проекты относятся к разным отраслям:
Строительство
Медицина
Образование
E-commerce
Для этого логично создать отдельную Taxonomy:
industry
Если есть тип проекта:
Интернет-магазин
Корпоративный сайт
Каталог
Сервис
может существовать ещё одна Taxonomy:
project_type
В итоге структура становится примерно такой:
Project
├── Custom Fields
├── Industry
├── Project Type
└── Relationships
Именно сочетание Post Types + Taxonomies + Custom Fields документация WordPress/SCF рассматривает как основу построения более сложной модели контента.
Это уже отличается от простой схемы:
запись → набор полей
Сайт постепенно превращается в небольшую информационную систему.
А затем появляются связи
Допустим, на странице проекта нужно показать специалиста.
Самый простой вариант — добавить текстовое поле:
Специалист: Иван Петров
Но это не настоящая связь.
CMS знает только строку текста Иван Петров.
Она не знает, что где-то существует отдельная запись:
Специалист #128
Иван Петров
Настоящее отношение выглядит иначе:
Project #52
↓
Specialist #128
Теперь проект связан не с текстом, а с конкретным объектом системы.
Это принципиально меняет возможности.
Например, можно:
- изменить имя специалиста в одном месте;
- автоматически показать все его проекты;
- вывести специалиста на страницах связанных услуг;
- использовать его данные в других шаблонах;
- построить запрос по этой связи.
SCF содержит специальные relationship-типы полей. Например, Post Object позволяет связывать записи, страницы и Custom Post Types, включая множественный выбор и двунаправленные отношения.
Именно здесь начинает проявляться одна из наиболее существенных архитектурных разниц между CMS Потоками Tilda и WordPress.
У Tilda можно создать отдельный CMS Поток «Проекты» и другой Поток «Специалисты».
Но по актуальной документации CMS Потоков среди типов пользовательских полей я не нахожу прямого аналога WordPress Post Object / Relationship, предназначенного для формирования полноценного отношения между записью одного типа и записью другого типа.
То есть вопрос уже не в том:
Можно ли создать поле «Специалист»?
Создать поле можно.
Вопрос:
Понимает ли CMS, что значение этого поля является другой самостоятельной сущностью?
И это большая техническая разница.
Во второй части серии мы специально проверим её на практике.
Категория и Taxonomy — тоже не совсем одно и то же
Похожая ситуация возникает с классификацией контента.
В Tilda есть разделы и другие механизмы группировки записей.
Для многих задач этого вполне достаточно.
Но WordPress рассматривает Taxonomy как отдельный системный механизм классификации контента.
Например, у объекта недвижимости могут независимо существовать:
Тип недвижимости:
— квартира
— дом
— участок
Город:
— Москва
— Казань
— Сочи
Статус:
— строится
— сдан
— вторичный рынок
Все три классификации существуют отдельно.
При этом каждая может иметь собственные страницы, запросы, иерархию и программную логику.
SCF позволяет создавать собственные taxonomies через административный интерфейс.
Поэтому разница снова заключается не просто в наличии категории, а в глубине модели данных.
Динамический контент неизбежно приводит нас к запросам
Допустим, на странице услуги нужно показать:
Последние три проекта, в которых использовалась эта услуга.
Или:
Все проекты специалиста Ивана Петрова.
Или:
Все проекты из отрасли «Строительство», где использовалась определённая услуга.
Чтобы это работало автоматически, система должна не только хранить данные, но и уметь делать выборки по их структуре.
Условно:
Получить Projects
где:
service = current_service
сортировка:
date DESC
limit:
3
И вот здесь WordPress снова показывает отличие открытой CMS от SaaS-конструктора.
Разработчик может работать с WP_Query, метаданными, таксономиями, REST API или собственной PHP-логикой.
Если стандартный механизм не подходит, его можно изменить или написать свой.
В Tilda разработчик работает с возможностями платформы, в WordPress — с самой CMS
Это, пожалуй, одна из главных технических мыслей всего сравнения.
Tilda позволяет достаточно много:
- использовать стандартные блоки;
- создавать интерфейсы в Zero Block;
- вставлять HTML, CSS и JavaScript;
- использовать CMS Потоки;
- подключать сторонние сервисы;
- принимать данные через формы;
- работать с API.
Но backend самой платформы остаётся backend Tilda.
Разработчик использует предоставленные механизмы, но не может изменить внутреннюю PHP-логику Tilda или структуру её серверного приложения.
WordPress работает иначе.
У разработчика есть доступ к коду приложения.
Можно использовать:
- PHP;
- Actions;
- Filters;
- REST API;
- собственные плагины;
- собственные REST endpoints;
- WP-Cron;
- WP_Query;
- Database API;
- собственную бизнес-логику.
Hooks в WordPress специально предназначены для взаимодействия одного участка кода с другим без необходимости менять ядро напрямую, а REST API предоставляет программный интерфейс для получения и изменения данных CMS.
Отсюда я бы сформулировал различие так:
В Tilda разработчик расширяет сайт в рамках возможностей платформы. В WordPress разработчик может расширять саму CMS.
Для простого сайта разница практически не заметна.
Для нестандартной системы она может стать определяющей.
API Tilda и REST API WordPress тоже решают разные задачи
У Tilda есть API, и это обязательно нужно учитывать при техническом сравнении.
Но интересно посмотреть на то, для чего сама Tilda предлагает его использовать.
В текущей документации API описан прежде всего как механизм синхронизации созданного на Tilda контента с собственным сервером.
Tilda отдельно указывает, что нельзя обращаться к её API при каждом посещении страницы. Предполагается получить контент, сохранить его на собственном сервере и уже оттуда отдавать пользователю. Сейчас документация также устанавливает лимит 150 обращений к серверу в час.
Основные опубликованные методы API работают с проектами и страницами:
getprojectslist
getprojectinfo
getpageslist
getpage
getpagefull
...
То есть это в значительной степени API публикации и синхронизации.
WordPress REST API является частью самой CMS-модели и предназначен для программного получения и изменения ресурсов WordPress — записей, таксономий и других объектов.
Для обычного корпоративного сайта разница может не иметь никакого практического значения.
Но при интеграции сайта с другими системами архитектурный подход уже заметен.
Что значит «сайт находится у вас»
Здесь возникает ещё одна тема, которую часто слишком упрощают.
Иногда можно услышать:
С Tilda сайт вам не принадлежит, а с WordPress принадлежит.
Так говорить слишком грубо.
Контент пользователя и программная платформа — разные вещи.
Гораздо полезнее разделить вопрос на несколько частей:
- Кто управляет доменом?
- Где находятся файлы сайта?
- Где находится база/структура данных?
- Где находится CMS?
- Можно ли перенести всю систему на другой сервер?
- Сохранится ли после переноса административная часть и вся динамическая логика?
И вот здесь различие намного понятнее.
WordPress можно перенести вместе с CMS
Типичный WordPress-проект состоит как минимум из:
Файлы
+
База данных
Переносим их на другой подходящий сервер, меняем необходимые настройки — и получаем ту же CMS с её:
- записями;
- пользователями;
- Custom Post Types;
- Taxonomies;
- Custom Fields;
- плагинами;
- темой;
- административной частью.
Разумеется, реальный перенос может требовать дополнительных действий, особенно в сложных проектах, но архитектурно система переносится целиком.
WordPress при этом не принадлежит конкретному хостингу.
Сегодня сайт может находиться у одного провайдера, завтра — у другого.
Tilda тоже позволяет экспортировать сайт, но здесь есть важное отличие
В Tilda существует экспорт проекта для размещения на собственном сервере.
И это важная возможность.
Но экспорт фронтенда и перенос всей CMS — разные вещи.
Для CMS Потоков административная и серверная логика продолжает зависеть от платформы.
То есть условно происходит:
Tilda
CMS + данные + система публикации
↓
экспорт
↓
HTML / CSS / JS
на вашем сервере
а не:
CMS + её backend + база
↓
ваш сервер
И это один из самых важных архитектурных моментов во всём сравнении.
Его можно сформулировать очень коротко:
Экспортировать страницы — не то же самое, что экспортировать CMS.
Для многих проектов это совершенно не проблема.
Но если одним из требований является независимость от конкретной SaaS-платформы, учитывать это нужно ещё на этапе выбора технологии.
Свобода WordPress имеет свою цену
На этом месте легко сделать вывод:
Значит WordPress лучше.
Нет.
Потому что контроль означает не только возможности, но и ответственность.
Если проект работает на WordPress, кто-то должен следить за:
- хостингом;
- обновлениями;
- PHP;
- базой данных;
- резервными копиями;
- безопасностью;
- совместимостью плагинов;
- производительностью;
- техническими ошибками.
Разумеется, значительную часть этих задач можно автоматизировать или передать хостингу и разработчику.
Но они существуют.
В SaaS-модели Tilda большая часть базовой инфраструктуры находится на стороне самой платформы.
И иногда именно это является её преимуществом.
Владелец небольшого сайта может вообще не хотеть знать, какая версия PHP работает на сервере и когда пора оптимизировать базу данных.
Ему нужно открыть редактор, изменить текст, нажать «Опубликовать» и заниматься своим бизнесом.
Это нормальное требование.
Поэтому «ограничение» и «преимущество» иногда являются одним и тем же
Закрытая платформа ограничивает разработчика.
Но именно благодаря ограничениям она может дать пользователю более предсказуемую среду.
Открытая CMS даёт разработчику намного больше контроля.
Но этот контроль увеличивает количество решений, которые необходимо принимать самостоятельно.
Получается интересный баланс:
Tilda
меньше контроля
↓
меньше технической ответственности
и:
WordPress
больше контроля
↓
больше технической ответственности
Поэтому выбирать технологию только по количеству доступных возможностей не всегда правильно.
Когда архитектурная разница практически не важна
Представим сайт мероприятия.
Нужно:
- пять страниц;
- программа;
- несколько спикеров;
- форма регистрации;
- контакты.
Проект проживёт несколько месяцев.
Нет сложной базы данных.
Нет нестандартных интеграций.
Нет задачи через три года превратить сайт в отдельную платформу.
В такой ситуации спор о том, что WordPress позволяет создавать собственные REST endpoints, может вообще не иметь смысла.
Техническая возможность, которую никто никогда не использует, сама по себе не приносит пользы проекту.
А быстрый запуск и простое обслуживание могут оказаться гораздо важнее.
Когда архитектура уже начинает иметь значение
Теперь другой проект.
У компании есть:
- 40 услуг;
- 150 проектов;
- 30 специалистов;
- несколько сотен отзывов;
- отрасли;
- направления;
- города.
Проект должен развиваться несколько лет.
На странице услуги нужно автоматически выводить связанные проекты.
На странице проекта — сотрудников, которые над ним работали.
На странице сотрудника — его проекты.
Отзывы нужно связывать с конкретными проектами.
Затем появляется фильтрация.
Потом интеграция с CRM.
Потом API.
Потом ещё один frontend.
В какой-то момент сайт перестаёт быть просто набором страниц.
Он становится информационной системой с собственной моделью данных.
И вот здесь первоначальный выбор архитектуры начинает играть намного большую роль.
Так Tilda — CMS или всё-таки нет?
После появления CMS Потоков отвечать на этот вопрос одним словом мне кажется не очень полезным.
Сказать:
«Tilda — просто конструктор и никакой CMS там нет»
— сегодня уже технически некорректно.
CMS Потоки позволяют создавать собственные структуры полей, хранить структурированные записи, отделять данные от шаблона и динамически выводить контент.
Это вполне реальные CMS-возможности.
Но Tilda при этом остаётся SaaS-платформой, внутри которой эта CMS-функциональность реализована.
WordPress — самостоятельная open-source CMS, которую разработчик может устанавливать, переносить и программно расширять на уровне серверного приложения.
Поэтому точнее сравнивать не:
CMS против конструктора.
А:
open-source CMS против SaaS-платформы с визуальным конструктором и CMS-возможностями.
Мне кажется, это гораздо лучше описывает современное состояние обеих систем.
Что в итоге выбрать: WordPress или Tilda?
После всего написанного хочется дать таблицу:
| Нужно | Выбираем |
|---|---|
| Лендинг | Tilda |
| Корпоративный сайт | WordPress |
| Портфолио | Tilda |
| Каталог | WordPress |
Но я специально не буду этого делать.
Потому что два корпоративных сайта могут иметь совершенно разную архитектуру.
Один состоит из десяти практически неизменяемых страниц.
Другой содержит сотни связанных сущностей, фильтрацию, интеграции и постоянно развивается.
По названию проекта выбрать технологию невозможно.
Гораздо полезнее задать другие вопросы:
Какие данные будут находиться на сайте?
Сколько у них типов?
Как они связаны между собой?
Насколько структура изменится через несколько лет?
Потребуется ли нестандартная серверная логика?
Насколько важна независимость от конкретной платформы?
И кто будет отвечать за техническое обслуживание?
Вот тогда выбор становится намного более осмысленным.
Но мы пока сравнили только теорию
Есть одна проблема.
Фразы вроде:
«WordPress лучше работает со связанными данными»
или:
«Tilda подходит для более простой структуры»
звучат слишком абстрактно.
Поэтому во второй части я хочу проверить всё это на конкретном примере.
Возьмём небольшой сайт компании и создадим четыре типа данных:
Услуги
↕
Проекты
↕
Специалисты
↕
Отзывы
Причём они не должны просто существовать независимо друг от друга.
Проект должен знать, к какой услуге относится.
В проекте нужно выбрать специалистов, которые над ним работали.
Отзыв должен принадлежать конкретному проекту.
А на странице услуги должны автоматически появляться связанные с ней проекты.
Получится примерно такая модель:
Услуги
↕
Проекты
↙ ↘
Специалисты Отзывы
Сначала попробуем реализовать её через CMS Потоки Tilda.
Затем построим ту же структуру через WordPress + Secure Custom Fields.
И уже на конкретном примере посмотрим:
- как создаются типы данных;
- как задаются поля;
- как работают шаблоны;
- как связать одну сущность с другой;
- как получить обратную связь;
- как автоматически делать выборки;
- где достаточно стандартных возможностей;
- где понадобятся обходные решения;
- и в какой момент различие архитектур начинает действительно влиять на разработку.
Потому что именно тогда, когда данные начинают зависеть друг от друга, сравнение WordPress и Tilda становится намного интереснее, чем обычный спор о том, на чём проще собрать лендинг.
Продолжение скоро следует: «Tilda CMS Потоки vs WordPress + SCF на практике: Услуги ↔ Проекты ↔ Специалисты ↔ Отзывы».
