Как email выглядит в разных клиентах: тестирование рендеринга

Вы нарисовали письмо. В превью оно смотрится отлично. Потом открываете в Outlook, и вёрстка поехала. Gmail вырезал стили. Yahoo сдвинул отступы. Apple Mail отрисовал идеально, но в тёмной теме логотип растворился в фоне. Это не ошибка в вашем коде. Так устроены почтовые клиенты.

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

Веб-браузеры договорились о стандартах. Chrome, Firefox, Safari рендерят CSS одинаково с минимальными отличиями. У email-клиентов такого соглашения нет. Каждый применяет собственные правила: вырезает одни CSS-свойства, переписывает другие, добавляет свои стили поверх ваших.

Outlook на Windows использует движок Microsoft Word для отображения HTML. Не браузерный движок - Word. Отсюда отсутствие поддержки flexbox, grid, ограниченная работа с фоновыми изображениями и непредсказуемое поведение отступов. Gmail вырезает весь блок <style> из <head>, если HTML превышает 102 КБ, и переименовывает CSS-классы даже когда оставляет их. Apple Mail поддерживает почти весь современный CSS, но в тёмном режиме агрессивно инвертирует цвета. Яндекс.Почта и Mail.ru имеют собственные конвейеры санитизации с ограничениями на max-width, позиционирование и обработку изображений.

Итог: одно письмо - четыре разных вида в четырёх клиентах. Если вы тестировали только в одном, три четверти получателей увидели то, что вы не планировали.

Что ломается и где: по клиентам

Outlook (Windows). Движок Word не понимает border-radius - кнопки со скруглениями становятся прямоугольниками. Фоновые изображения требуют VML-разметки. Padding на <div> часто игнорируется - используйте ячейки таблиц. Вертикальные отступы рассчитываются иначе, чем в любом другом клиенте. Стандартный обходной путь - условные комментарии <!--[if mso]>, которые вставляют HTML только для Outlook.

Gmail. Все имена классов получают префикс, поэтому CSS-селекторы, завязанные на вложенность или сложную специфичность, могут сломаться. Media queries работают в большинстве интерфейсов Gmail, но не всегда стабильно в Android-приложении для не-IMAP аккаунтов. Лимит в 102 КБ на размер HTML - жёсткая граница. Превысили - Gmail обрезает письмо со ссылкой «Показать целиком». Большинство подписчиков не кликнут.

Apple Mail. Самый лояльный клиент. Поддерживает веб-шрифты, media queries, CSS-анимации и prefers-color-scheme. Подвох - тёмная тема. Apple Mail автоматически инвертирует светлые фоны в тёмные и наоборот. Если дизайн использует средние тона или изображения с прозрачным фоном на предполагаемо белой подложке, автоинверсия может дать нечитаемые сочетания.

Яндекс.Почта и Mail.ru. Оба клиента популярны в России и СНГ. У обоих собственные конвейеры санитизации, вырезающие определённые CSS-свойства. Яндекс поддерживает media queries, но иногда перебивает размер шрифта в мобильном приложении. Mail.ru игнорирует max-width на <div>, но корректно применяет его на ячейках таблиц. Если аудитория русскоязычная, тестирование в этих двух клиентах обязательно.

Три подхода к тестированию

Они не взаимоисключающие - лучше всего работают в связке.

Автоматические сервисы превью. Litmus и Email on Acid берут ваш HTML, рендерят его в 90+ клиентах и устройствах, возвращают скриншоты. Вы видите именно то, что увидят подписчики: Gmail на Android, Outlook 2019 на Windows, Apple Mail на iPhone, Samsung Mail и десятки других. Стоимость - от $80 до $150 в месяц. Для команд с регулярными рассылками они окупаются за счёт сэкономленного времени.

Ручное тестирование на реальных аккаунтах. Заведите почтовые ящики на Gmail, Outlook.com, Yahoo, Яндексе, Mail.ru, iCloud. Отправьте себе тестовое письмо. Откройте на десктопе и мобильном. Включите тёмную тему. Отключите показ картинок. Это медленнее Litmus, но бесплатно - и даёт живой опыт вместо статичного скриншота. Минимальный набор: Gmail (веб), Outlook (десктоп Windows), Apple Mail (iOS), плюс один российский клиент.

Проверка на уровне кода. HTMLHint с email-правилами или редактор Parcel находят типичные ошибки ещё до отправки теста. Отсутствующие alt, неподдерживаемые CSS-свойства, вес HTML больше 102 КБ, пропущенные инлайн-стили. Это не замена визуальному тестированию, но отсечение явных проблем на раннем этапе.

Частые проблемы рендеринга и как их решать

Сломанная раскладка в Outlook. Используйте таблицы для структуры. Внешняя таблица 100% ширины для фона, внутренняя на 600px для контента. Колонки заворачивайте в условные комментарии для Outlook, а для современных клиентов применяйте display: inline-block на div-обёртках. Такой гибридный подход рендерится корректно везде.

Обрезанное письмо в Gmail. Держите общий вес HTML ниже 102 КБ. Минифицируйте разметку. Уберите лишние комментарии и пробелы. Если в письме длинный список товаров, сократите количество позиций и дайте ссылку на полный каталог на сайте.

Невидимый логотип в тёмной теме. Используйте PNG с прозрачным фоном и добавьте тонкую белую или светлую обводку по краям логотипа. Или подготовьте две версии и переключайте через @media (prefers-color-scheme: dark). Для клиентов без поддержки этого медиа-запроса покажется светлая версия - поэтому она должна работать на обоих фонах.

Заблокированные изображения. Корпоративные установки Outlook и некоторые веб-клиенты блокируют картинки по умолчанию. Письмо должно быть читаемым совсем без картинок. Описательный alt-текст, фоновые цвета в контейнерах изображений, критическая информация - только текстом.

Разные шрифты на разных клиентах. Веб-шрифты работают в Apple Mail, iOS Mail, Samsung Mail. Gmail и Outlook их игнорируют. Проектируйте письмо на системных шрифтах - Arial, Helvetica, Georgia. Веб-шрифт добавляйте как улучшение. Подберите fallback-стек с похожими метриками, чтобы раскладка не ехала у получателей, чей клиент отбросил кастомный шрифт.

Рендеринг - половина дела. Доставляемость - вторая половина.

Можно оттестировать рендеринг во всех клиентах на свете и всё равно проиграть, если письмо не дойдёт. Отлично свёрстанное сообщение в папке «Спам» - невидимое сообщение. А одна из главных причин попадания в спам - отправка на невалидные адреса. Высокий bounce rate сигнализирует ISP, что отправитель не поддерживает список. Репутация домена падает, последующие рассылки уходят в нежелательную почту.

Валидация списка получателей перед отправкой убирает мёртвые адреса, выявляет одноразовые ящики, помечает спам-ловушки. Bounce rate снижается, репутация восстанавливается, и ваше аккуратно протестированное письмо действительно попадает в inbox - туда, где рендеринг имеет значение.

Тестировать рендеринг без проверки базы - всё равно что полировать кузов машины без двигателя. Выглядит хорошо, но никуда не едет.