Я начал эту заметку как обычное сравнение сервисов для генерации картинок.

Хотел взять одну обложку, повторить ее в разных местах и посмотреть, где удобнее. Без большого исследования рынка, без таблицы на двадцать пунктов. Просто один понятный макет: темный фон, Хабр сверху, две строки заголовка на голубой подложке, Практика снизу. Размер обычный для соцсетей: 1200x630.

Референс: повторяю общую композицию, не официальный шаблон.

План был простой: сделал картинку, поменял заголовок, получил новую картинку.

Потом я понял, что это плохой план.

Потому что нормальный финиш для такой картинки — не PNG в загрузках браузера. Финиш — это запись в WordPress, у которой в коде страницы стоит правильный og:image. Чтобы Telegram, VK и остальные площадки взяли именно эту обложку, а не первую попавшуюся картинку из записи.

С этого места сравнение стало менее веселым, зато более честным.

Что я вообще пытался повторить

Мне нужна была картинка:

• 1200x630;

• Хабр сверху;

• две строки заголовка:

  • Сервисы для OG-картинок:

  • генерируем одну обложку везде;

• Практика снизу;

• русский текст без сюрпризов.

На первый взгляд задача глупая. Почти любой редактор умеет поставить текст на фон.

Но в этой обложке есть мелочь, из-за которой все становится интереснее: голубая подложка под заголовком. Она должна идти за текстом. Заголовок стал длиннее — подложка стала длиннее. Заголовок стал короче — подложка тоже стала короче.

Если после каждой новой статьи надо руками тянуть прямоугольник под строкой, повторяемости тут нет. Это просто ручная верстка с красивой вывеской.

Первый заход: собрать картинку прямо в адресе

Cloudinary я взял первым, потому что там давно умеют делать картинки из параметров в ссылке.

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

Cloudinary: картинка собрана через текстовые слои и параметры в адресе.

Фрагмент такой ссылки выглядит примерно так:

.../l_text:Roboto_48_bold:Сервисы...,co_rgb:14232c,b_rgb:9bd5ef/fl_layer_apply,x_60,y_242/...

То есть прямо в адресе лежит все: текст, шрифт, цвет, фон, координаты, отступы.

Пока слой один, это даже нравится. Когда слоев становится несколько, адрес превращается в штуку, которую страшно трогать руками. Ошибся в числе — текст уехал. Забыл, где меняется фон, — ищешь кусок посреди длинной строки.

И тут я впервые вернулся к вопросу из конца пути: а кто будет жить с этой ссылкой в WordPress?

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

Второй заход: может, через html проще

APITemplate.io сначала хотелось проверить через редактор.

Логичный путь такой: создать чистый макет 1200x630, собрать слои, потом менять данные запросом. Я вернулся к редактору отдельно, чтобы не делать вывод по первой случайной попытке.

Но быстро чисто не получилось. В создании шаблона картинки я видел размеры вроде 1200x900, 1024x512 и рекламные баннеры, а нужный 1200x630 не нашел. Потом попробовал поменять размер у маленького шаблона 800x150: в настройках поля менялись, но после сохранения и повторного открытия снова стояло 800x150.

Может быть, я не нашел правильное место. Поэтому писать “редактор не умеет” было бы нечестно.

Зато другой путь у APITemplate.io сработал хорошо: сверстать обложку как маленькую html-страницу и попросить сервис вернуть png.

APITemplate.io: результат через HTML-to-PNG.

Тут уже проще думать головой разработчика. Есть html, есть стили, есть размер 1200x630, есть текст и фон под ним. Получается аккуратно.

Но это снова возвращает к финальному вопросу. Для разработчика — ок. Для автора в WordPress — не готовый путь. Нужна своя связка: где хранить шаблон, как подставлять заголовок, как сохранить результат в медиафайлы, кто пропишет og:image.

PNG есть. Пути до публикации пока нет.

Третий заход: описать картинку JSON-ом

Creatomate оказался ближе к тому, что мне обычно нравится.

Там можно описать картинку через RenderScript. Если без красивых слов, это JSON: размер, прямоугольники, текст, координаты, цвета.

Creatomate: результат RenderScript; в этом тесте бесплатный путь отдал уменьшенный размер.

После длинных Cloudinary-ссылок такой формат воспринимается почти как облегчение. Шаблон можно хранить рядом с кодом, смотреть diff, менять параметры без охоты за запятыми в URL.

Но бесплатный аккаунт сразу напомнил, что у любого сервиса есть не только интерфейс, но и тариф. Я просил 1200x630, а получил 480x252. Для проверки нормально. Для реальной обложки — нет.

С WordPress ситуация та же: картинку можно сгенерировать, но дальше нужен свой код, плагин, Make, Zapier или еще какая-то прослойка.

На этом месте я понял, что три первых сервиса отвечают на один вопрос: “как получить картинку”. А мой настоящий вопрос уже стал другим.

Середина: я проверял не то слово

Я вроде сравнивал генераторы картинок, но каждый раз спотыкался не о картинку.

Cloudinary спотыкался о длинный адрес. APITemplate через html — о то, что это уже верстка. Creatomate — о тариф и размер. У всех трех можно получить результат, но после результата начинается отдельная работа.

И вопрос поменялся.

Не “какой сервис красивее рисует”. А “где я могу один раз собрать шаблон и потом спокойно менять заголовок, не возвращаясь к макету руками”.

И еще жестче: “как эта картинка окажется в WordPress”.

После этого я стал смотреть на сервисы иначе. Не снизу вверх, от редактора к красивому скриншоту. А наоборот: от записи в WordPress назад к инструменту.

Если шаблон сначала собрать руками

Placid хорошо показывает эту разницу.

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

После этого я создал чистый шаблон Open Graph 1200x630 и собрал его руками: фон, Хабр, заголовок на голубой подложке и Практика снизу. Так результат сразу стал нормальным.

Placid: чистый шаблон, собранный вручную; после этого его уже можно кормить данными.

Для себя я записал так: Placid не должен придумывать макет за вас. Он хорош, когда у вас уже есть аккуратная основа, а дальше нужно менять текст, картинки и данные. Для WordPress тут есть важный плюс: у Placid есть плагин. То есть путь до записи хотя бы существует не только на бумаге.

Bannerbear: сначала редактор, потом запрос

Bannerbear я изначально считал одним из главных кандидатов. У него есть редактор, API и WordPress-интеграция. На бумаге он прямо попадает в задачу.

Первый заход у меня получился кривым: я слишком быстро полез смотреть API. А Bannerbear устроен не так. Сначала руками собираешь шаблон в редакторе, потом уже меняешь данные в слоях запросом.

Поэтому я вернулся к нему отдельно. Создал шаблон 1200x630, добавил фон, Хабр, заголовок на голубой подложке и Практика снизу.

Bannerbear: шаблон собран вручную в редакторе, картинка получена через API.

После сохранения шаблона в API появились редактируемые слои: фон и три текстовых блока. Я отправил запрос на генерацию и получил PNG 1200x630.

Вот здесь подход становится понятным. API не заменяет редактор. Он берет уже собранную основу и меняет в ней значения.

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

Русскоязычный ручной путь

Из русскоязычных сервисов ближе всего к задаче оказался SUPA.

Там я пошел обычным ручным путем: создал картинку 1200x630 и собрал черновик обложки в редакторе. Темный фон, Хабр, две строки заголовка на голубой подложке, Практика снизу.

SUPA: ручной редакторский вариант после подгонки цветов и текста.

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

У SUPA есть документация по рендеру через API. Это делает сервис интереснее, чем просто еще один редактор картинок. Но в этом проходе я проверил именно редактор. До полноценной проверки API там надо отдельно дойти: получить доступ, понять, как называются объекты в дизайне, и уже потом пробовать подставлять данные запросом.

То есть как ручной инструмент он понятен. Как автоматический путь до WordPress — пока не доказан.

Что если все держать внутри WordPress

После внешних сервисов захотелось проверить противоположный вариант: вообще не ходить наружу.

Я поставил Sharing Image в локальный WordPress.

Что увидел:

• плагин живет внутри wp-admin;

• в бесплатной версии есть один демо-шаблон;

• новый шаблон помечен как платная функция;

• в редакторе записи появляется отдельная панель;

• плагин смог сгенерировать JPEG 1200x630.

Sharing Image: результат генерации внутри WordPress.

Мне этот кусок теста был важен не из-за конкретного плагина. Он показывает другую модель: картинка не где-то в отдельном сервисе, а сразу рядом с записью.

Но у WordPress-плагинов начинается своя скучная жизнь. Кто ставит мета-теги? Кто перезаписывает чужие? Что будет рядом с SEO-плагином? Куда сохраняется файл? Будет ли картинка обновляться после изменения заголовка?

Это все не очень эффектно выглядит в статье, зато именно там потом ломается реальный сценарий.

Как бы я проверял следующий сервис

После этого прогона я бы не начинал с лендинга и красивых примеров.

Я бы сразу шел по скучному списку:

• можно ли задать 1200x630;

• нормально ли работает русский заголовок;

• можно ли сделать фон под текстом без отдельного ручного прямоугольника;

• можно ли получить новую картинку запросом;

• где окажется файл;

• кто пропишет og:image;

• что будет рядом с WordPress и SEO-плагинами;

• сколько ручных действий останется после первого шаблона.

Если на этом пути все спокойно, редактор уже можно обсуждать.

Если нет, красивый PNG в кабинете сервиса мало что решает.

Вместо вывода

В начале я думал, что выбираю генератор картинок.

В конце оказалось, что выбираю путь: от заголовка до картинки в коде страницы.

Cloudinary, APITemplate через html и Creatomate мне понятны как инструменты для разработчика. Placid и Bannerbear лучше выглядят там, где сначала собирают хороший шаблон, а потом меняют данные. SUPA похож на нормальный ручной редактор, но API надо проверять отдельно. WordPress-плагины надо смотреть не по скриншоту редактора, а по тому, что они делают с og:image.

Ни один из этих вариантов не стал для меня универсальным победителем.

Если я пропустил хороший сервис, особенно с нормальным путем до WordPress, напишите в комментариях. После этого теста мне самому интересно прогнать еще пару вариантов уже не до PNG, а до настоящего финиша.