Невидимая угроза: как кэш браузера ломает твою воронку в PWA (и как это починить)

0
105

Нашел свежий сочный оффер, обновил креосы, заменил ссылки в PWA-приле, рассчитывая на высокий конверт, проверил настройки таргетинга, биды и добавил интерактивный преленд, а через 1-2 дня в статистике все та же печальная картина по CR. Депов практически нет, CR топчется на месте, а бюджет продолжает сливаться в трубу. Первое, на что большинство арбитранов пеняет в такие моменты — проблема в оффере или крео. Но реальная причина может скрываться там, где ее совсем не ждешь — в кэше браузера целевой аудитории.

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

Почему кэш — одновременно друг и враг байера?

Прежде чем бороться с врагом, надо изучить его. Кэш браузера — это, по сути, локальное хранилище на девайсе пользователя, где хранятся статические элементы веб-страниц: изображения, файлы стилей, скрипты. Это сделано для ускорения загрузки. Когда юзер попадает на PWA впервые, браузер смотрит на специальные инструкции от сервера (Cache-Control) и определяет, что можно и нужно сохранить. При следующем визите он не загружает эти файлы заново, а подтягивает из памяти. Для юзера это плюс — страница грузится мгновенно, опыт взаимодействия положительный.

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

  • День 1. Пользователь кликает на рекламу, переходит на PWA, ему нравится дизайн, бонусы, а отзывы не вызывают сомнений. Он устанавливает прилу на главный экран. Браузер кэширует все содержимое: картинки, кнопки, текст о приветственном бонусе и, самое главное, линк из партнерки или трекера, вшитый в прилу;
  • День 3. Веб видит, что конверт по офферу начал проседать даже после замены крео. Афф, найдя нового рекламодателя с лучшими условиями, заходит в редактор PWA, меняет дизайн баннеров, иконку, текст «Бонус 100%» на «Бонус 150% + 50 FS» и обновляет партнерскую ссылку;
  • День 5. Первый юзер, установивший PWA, получает в приле дожимающее push-уведомление: «Не забудь забрать свой супер-бонус!». Он открывает прилу, но браузер, желая «помочь» и ускорить процесс, подгружает старую, закэшированную версию.

В результате десятки или даже тысячи юзеров видят старый баннер, старый бонус «100%» и, кликнув на кнопку, переходят по старой, возможно, уже нерабочей ссылке. Веб не получает лиды, юзеры разочаровываются, и вся воронка ломается на последнем этапе. Даже если в воронке используется эффективный инструмент в виде гибкой цепочки push-уведомлений, конверсия резко падает, так как ссылка на прилу в объявлениях ведет на ее старую версию. В подобных случаях у веба больше контроля над ситуацией и самой PWA, если прила изначально создавалась в конструкторе от PWA Group, где каждый элемент и строка кода уже оптимизированы под залив трафика.

Методы борьбы с кэшем для PWA

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

Основной метод — это «cache busting» (дословно — «сброс кэша»). Как отмечают многие разработчики, суть этой идеи проста: нужно изменить URL-адрес файла, чтобы браузер подумал, что это совершенно новый файл, и снова загрузил его с сервера. Самый распространенный способ, который можно встретить в кастомных PWA от фрилансеров, — добавление к названию файла уникального параметра, например, версию. Словом, вместо style.css используем style.css?v=1.2. Когда вносим очередные изменения в прилу, просто меняем версию на style.css?v=1.3, и браузер вынужден загрузить обновленный файл. Более продвинутый метод — добавлять хэш к названию файла, например, style.a1b2c3d4.css. Это самый надежный способ, но он требует автоматизированных систем сборки, что уже выходит за рамки компетенций рядового арбитражника. Вот, что по этому поводу пишут пользователи reddit в ветке разработчиков:

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

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

Управление через HTTP-заголовки (Server-Side Control)

Это фундаментальный способ, с помощью которого  сервер общается с браузером на девайсе юзера и дает ему инструкции, как обращаться с файлами. Главный инструмент здесь — заголовок Cache-Control. Он может содержать разные директивы:

  • no-cache. Это самая важная и чаще всего неправильно понятая директива. Она не означает «не кэшировать». Это больше что-то в духе «Прежде чем использовать файл из кэша, сверься с сервером, не появилась ли новая версия». Если новой версии нет, сервер ответит кодом 304 Not Modified, и браузер снова использует кэшированный файл. Это идеальный вариант для главного HTML-файла PWA. Юзер всегда получит свежую версию логики, но если ничего не изменилось, это произойдет мгновенно за счет подтягивания информации из кэша;
  • no-store. В отличие от no-cache это уже «ядерная» опция. Она полностью запрещает браузеру сохранять файл в любом кэше. Используется редко, обычно для чрезвычайно чувствительных данных, но для арбитража это неоправданно, т.к. может негативно влиять на производительность прилы;
  • max-age=[количество секунд]. Согласно этой директиве браузер действует по сценарию «можно использовать этот файл из кэша в течение X секунд, не обращаясь к серверу». Этот вариант больше подходит для статичных элементов, которые меняются редко — логотипов, файлов шрифтов, фонового изображения и т.п.

Как это применить на практике?

Все эти заголовки настраиваются на уровне сервера. Например, в конфигурационном файле .htaccess для сервера Apache можно добавить правила, чтобы для файла index.html всегда использовался no-cache, а для изображений из папки /images — max-age=86400, то есть сутки. Но, как можно заметить, этот метод требует доступа к настройкам сервера и базовых знаний в его администрировании.

Service Worker

Это самый мощный и гибкий метод, который можно считать сердцем технологии PWA. Service Worker — скрипт, работающий в фоновом режиме, отдельно от веб-страницы. Он действует как прокси-сервер между прилой, браузером и сетью. Такой подход позволяет реализовать наиболее сложные стратегии кэширования.

Вот самые популярные из них:

  • Cache First, который идеален для статических ресурсов. По сути браузер получает команду «сначала ищи в кэше, а если не нашел — иди в сеть»;
  • Network First. «Сначала попробуй загрузить из сети. Если не удалось (нет интернета) — отдай версию из кэша». Лучший вариант для динамического контента или главного файла, когда актуальность важнее скорости, но в то же время нужно обеспечить корректную оффлайн-работу;
  • Stale-While-Revalidate. Это «золотая середина» и самая продвинутая стратегия. Работает она по такой схеме: юзер делает запрос → Service Worker мгновенно отдает ему устаревшую версию из кэша. Страница загружается молниеносно. Но одновременно  с этим в фоновом режиме Service Worker делает запрос к сети, чтобы проверить наличие обновлений. Если есть обновленная версия, он тихо загружает ее и помещает в кэш. При следующем визите юзер уже получит самую свежую версию. Правда, чтобы вернуть юзера в обновленную версию прилы, после того, как он увидел до этого неактуальную информацию, потребуется, как минимум отправка пуша.

Используя контроль на уровне прилы, веб получает и мгновенную загрузку, и гарантированное обновление контента, не заставляя юзеров ждать. Но для написания и настройки Service Worker даже с условным ChatGPT не обойтись без знаний в JavaScript и асинхронном программировании. Порой, это сложная задача даже для опытных разработчиков, не говоря уже об арбитражниках.

Лучший способ — не создавать себе проблем с кэшем в PWA

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

Именно поэтому профессиональные конструкторы PWA стали стандартом для многих команд: они автоматически внедряют механизмы контроля версий, освобождая байера от необходимости разбираться в тонкостях кэширования. Обновляя дизайн, ссылки или текст в визуальном редакторе платформы, веб уверен, что система сама добавит необходимые технические параметры для сброса кэша у всех юзеров, установивших PWA. Словом, полное делегирование технички сервису и концентрация на маркетинге, а не на борьбе с невидимыми проблемами. Доверив управление кешем PWA Group, вебмастеры экономят не только время, но и деньги, которые могли бы потерять из-за неактуальных линков на оффер, дизайнов и других составляющих прогрессивной веб-прилы. С конструктором, даже если возникнет необходимость в кастомных скриптах, JS-скрипт легко можно добавить в прилу простой копипастой.

Вывод

Как видим, технические решения для регулярного обновления PWA без проблем с кэшем браузера существуют, но они сложны. Поэтому лучший метод для медиабайера — использование платформы, которая делает все это «под капотом». Когда работаешь с профессиональным конструктором PWA, «заточенным» под арбитраж, не думаешь о Cache-Control или стратегиях Service Worker и прочих технических нюансах прилы.

В PWA Group уже внедрены самые надежные стратегии. Просто нажимаешь кнопку «Обновить» в визуальном редакторе, а платформа сама заботится о том, чтобы все юзеры, независимо от их девайса или браузера, гарантированно получили самую свежую версию прилы. Словом, для арбитражника самый эффективный метод — это не учиться администрированию серверов (хотя это и может пригодиться в некоторых ситуациях), а делегировать эту сложную техническую задачу специализированному сервису.