Миграция PWA на новый домен в Chrome 150:
Смена origin без потери пользователей

Введение: какую проблему решает миграция origin PWA

С момента появления Progressive Web Apps одним из самых болезненных ограничений была жёсткая привязка идентичности PWA к его веб-ориджину. Если вы развернули PWA на www.example.com/social, а затем понадобилось перенести его на social.example.com, то поддерживаемого пути не существовало. Пользователи, установившие ваше приложение, оказывались в тупике — единственным выходом было вручную удалить приложение, найти новую кнопку установки и переустановить.

Изменение start_url без стабильного поля id создавало ещё более серьёзную проблему: браузер воспринимал новый start_url как совершенно другое приложение, создавая дублирующиеся установки — пресловутый баг «раздвоения приложения». Пользователи получали две иконки одного и того же приложения, одна из которых вела на старый путь, а другая на новый.

Chrome 150 представляет миграцию origin PWA — платформенную функцию, которая раз и навсегда решает эту проблему. Разработчики теперь могут переносить установленные PWA на новый origin в пределах одного сайта через диалог обновления в один клик. Анонсированная 3 июня 2026 года, это одно из самых значительных улучшений платформы PWA со времён появления возможности устанавливать PWA на десктоп.

Что даёт миграция origin — реальные сценарии использования

Функция открывает несколько практических сценариев, которые ранее были невозможны или требовали болезненных обходных путей:

Свобода архитектурных решений

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

• app.example.com → saas.example.com (ребрендинг продукта)
• example.com/old-app → new-app.example.com (выделение продукта)
• example.com/user → user.example.com (выделенный поддомен для функции)

Исправление проблемы «раздвоения приложения»

Если start_url вашего PWA когда-либо менялся без стабильного id, существующие пользователи получали дублирующиеся установки. Миграция origin предоставляет чистый способ консолидировать эти разделённые установки в единое, правильно идентифицированное приложение.

Ребрендинг и реструктуризация доменов

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

Миграция с мультитенантного на выделенный домен

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

Как это работает — двухстороннее рукопожатие (Two-Way Handshake)

Миграция origin PWA использует протокол двухстороннего рукопожатия между старым и новым ориджинами. Обе стороны должны явно участвовать — бесшумные захваты невозможны. Разберём каждый шаг.

Шаг 1: Новое приложение объявляет предшественника

Манифест целевого (нового) приложения должен включать поле migrate_from, перечисляющее ориджины, с которых происходит миграция.

// Манифест на https://new-app.example.com/manifest.json
{
  "name": "New App Name",
  "id": "/app/",
  "start_url": "/app/index.html",
  "migrate_from": [
    "https://old-app.example.com/"
  ]
}

Важно: Поле id в целевом манифесте обязательно. Без него браузер не сможет надёжно связать новую установку с идентификатором мигрированного приложения, и вы рискуете воссоздать тот самый сценарий раздвоения приложения, который пытаетесь исправить.

Шаг 2: Старый origin подтверждает миграцию

Старый origin должен явно авторизовать миграцию, развернув well-known конфигурационный файл. Это предотвращает враждебные захваты — новый сайт не может в одностороннем порядке перехватить установочную базу существующего приложения.

// Файл на https://old-app.example.com/.well-known/web-app-origin-association
{
  "https://new-app.example.com/app/": {
    "allow_migration": true
  }
}

Этот файл располагается в директории .well-known старого origin, повторяя шаблон, используемый другими функциями веб-платформы, такими как web-app-origin-association для обработки URL. Браузер загружает этот файл в процессе миграции для проверки авторизации.

Шаг 3: Упреждающее оповещение (опционально)

Чтобы инициировать миграцию упреждающе — не дожидаясь, пока пользователи посетят новый сайт — обновите манифест старого приложения, добавив поле migrate_to, указывающее на новый origin.

// Обновлённый манифест на https://old-app.example.com/manifest.json
{
  "name": "Old App",
  "start_url": "/",
  "migrate_to": {
    "id": "https://new-app.example.com/app/",
    "install_url": "https://new-app.example.com/app/install"
  }
}

Когда браузер видит поле migrate_to в старом манифесте, он упреждающе предлагает пользователю вариант миграции — ему не нужно сначала переходить на новый сайт.

Шаг 4: Обработка редиректов (опционально)

Если вы настроили перенаправления со старых URL на новый origin, включите install_url внутрь поля migrate_from. Это сообщает браузеру, где найти старый манифест, не следуя по цепочке перенаправлений.

// Расширенный migrate_from с install_url
{
  "migrate_from": [
    {
      "id": "https://old-app.example.com/",
      "install_url": "https://old-app.example.com/installwebapp?from=migrate"
    }
  ]
}

Управление пользовательским опытом — Suggest vs Force

Chrome 150 поддерживает два режима поведения миграции, определяющих, как миграция представляется пользователям:

Режим Suggest (по умолчанию)

Поведение: Пассивное уведомление в меню приложения. Пользователи могут обновиться, удалить приложение или полностью проигнорировать миграцию.

Когда использовать: Первоначальные развёртывания, A/B-тестирование, постепенные миграции с минимальным disruption для пользователей. Те, кто готов мигрировать, могут это сделать; те, кто предпочитает старый опыт, могут остаться.

Режим Force

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

{
  "migrate_from": [
    {
      "id": "https://old-app.example.com/",
      "behavior": "force"
    }
  ]
}

Когда использовать: Когда старый origin выводится из эксплуатации, срок действия старого домена истекает, или для корпоративных миграций, где все пользователи должны перейти на новый origin к определённому сроку.

Важные ограничения принудительной миграции

Даже в режиме force изменение названия и иконки откладывается. После завершения миграции отображаемое имя и иконка приложения обновляются через стандартный процесс обновления приложения, а не в диалоге миграции. Это предотвращает путаницу, когда пользователь видит совершенно другое название приложения в подтверждении миграции.

Рекомендация: Сначала разверните в режиме suggest, отслеживайте показатели принятия через вашу аналитику, затем переключайтесь на force, когда убедитесь в стабильности нового origin и привыкании пользователей к переходу.

Полная сквозная миграция: конфигурация из 5 файлов

Полный эталонный пример со всеми пятью файлами для миграции PWA с old.example.com на new.example.com. Каждый файл необходим для успешного процесса миграции.

Файл 1: Манифест нового origin

Целевой манифест объявляет origin-предшественник и задаёт режим миграции.

// https://new.example.com/manifest.json
{
  "name": "App Rebranded",
  "short_name": "AppRebrand",
  "id": "/app/",
  "start_url": "/app/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0f766e",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "migrate_from": [
    {
      "id": "https://old.example.com/",
      "behavior": "suggest"
    }
  ]
}

Файл 2: Well-known авторизация старого origin

Развёртывается на старом origin для авторизации нового. Без этого файла браузер отказывает в миграции.

// https://old.example.com/.well-known/web-app-origin-association
{
  "https://new.example.com/app/": {
    "allow_migration": true
  }
}

Файл 3: Манифест старого origin (упреждающий сигнал)

Обновлённый манифест на старом origin для упреждающего уведомления пользователей, которые ещё не посетили новый сайт.

// https://old.example.com/manifest.json
{
  "name": "Original App",
  "id": "/",
  "start_url": "/",
  "display": "standalone",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ],
  "migrate_to": {
    "id": "https://new.example.com/app/",
    "install_url": "https://new.example.com/manifest.json"
  }
}

Файл 4: Service Worker на новом origin

Service Worker нового origin обрабатывает миграцию кеша и обеспечивает резервное поведение в переходный период.

// https://new.example.com/sw.js
const CACHE_NAME = 'app-v2';

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.addAll([
        '/app/',
        '/app/index.html',
        '/app/styles.css',
        '/app/app.js'
      ]);
    })
  );
});

self.addEventListener('activate', (event) => {
  event.waitUntil(clients.claim());
  event.waitUntil(
    caches.keys().then((keys) => {
      return Promise.all(
        keys.filter((k) => k !== CACHE_NAME)
          .map((k) => caches.delete(k))
      );
    })
  );
});

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached || fetch(event.request);
    })
  );
});

Файл 5: Конфигурация редиректов

Серверные редиректы обеспечивают graceful перенаправление старых URL на новый origin во время миграции. Пример для NGINX.

# /etc/nginx/sites-available/old.example.com
server {
    listen 443 ssl;
    server_name old.example.com;

    location / {
        return 301 https://new.example.com/app/$request_uri;
    }

    location /.well-known/ {
        alias /var/www/old-app/.well-known/;
        try_files $uri =404;
    }
}

Стратегия миграции Service Worker и данных

Миграция origin PWA обрабатывает перенос записи об установке приложения, но данные приложения — IndexedDB, Cache Storage и состояние service worker — НЕ мигрируются автоматически. Необходима продуманная стратегия обеспечения непрерывности данных.

Вариант 1: Доступ к данным старого origin с нового

Если оба origin используют один и тот же бэкенд, service worker на новом origin может просто заново загрузить данные пользователя:

// Service worker на новом origin: стратегия миграции данных
const DATA_MIGRATION_KEY = 'data-migration-v1';

self.addEventListener('activate', (event) => {
  event.waitUntil((async () => {
    const migrated = await caches.match(DATA_MIGRATION_KEY);
    if (!migrated) {
      const response = await fetch('/api/user/data', {
        credentials: 'include'
      });
      if (response.ok) {
        const cache = await caches.open('user-data');
        await cache.put('/api/user/data', response);
        await cache.put(DATA_MIGRATION_KEY,
          new Response('migrated', { status: 200 }));
      }
    }
  })());
});

Вариант 2: Уведомительная перезагрузка кеша

Отправьте push-уведомление или внутриприложенческую подсказку после миграции, предписывающую клиенту перезагрузить критически важные данные.

Вопросы безопасности и корпоративные аспекты

Функция миграции origin PWA разработана с учётом безопасности как приоритета первого уровня:

Ограничение одним сайтом

Поддерживаются только миграции в пределах одного сайта (same eTLD+1). Вы можете перенести приложение с app.example.com на saas.example.com, но не с example.com на different-domain.com. Это ограничение предотвращает перехват приложений между разными организациями.

Верификация через Well-Known файл

Файл .well-known/web-app-origin-association на старом origin служит механизмом авторизации. Без явного разрешения миграции в этом файле браузер не продолжит процесс. Это предотвращает любой сценарий бесшумного захвата.

Корпоративные политики управления

Для организаций, использующих политику WebAppInstallForceList для управления установками PWA, существует важное ограничение: корпоративные приложения блокируются от автоматической миграции. Поскольку корпоративные политики привязаны к URL/origin, миграция может обойти контроль администратора, переместив управляемое приложение на неуправляемый origin. Пользователи увидят баннер с объяснением, что настройки политики блокируют миграцию.

Корпоративным администраторам следует планировать миграции через обновление групповых политик, а не через функцию миграции origin напрямую.

Чеклист миграции — пошаговое руководство

Следуйте этому чеклисту для бесшовной миграции вашего PWA:

1. Проверьте ограничение same-site — убедитесь, что старый и новый origins имеют одинаковый eTLD+1
2. Добавьте поле id в целевой манифест (обязательно!)
3. Разверните манифест с migrate_from на новом origin
4. Создайте .well-known/web-app-origin-association на старом origin, авторизующий миграцию
5. Выберите поведение: suggest (постепенная) или force (обязательная)
6. (Опционально) Разверните migrate_to в старом манифесте для упреждающего оповещения
7. (Опционально) Установите install_url если старые URL перенаправляют на новые
8. Протестируйте процесс миграции в Chrome 150+ beta или Canary
9. Отслеживайте принятие пользователями — проверяйте показатели завершения обновления через аналитику
10. Выведите из эксплуатации старый origin после завершения окна миграции

До и после Chrome 150

Поддержка браузеров и перспективы

Миграция origin PWA была анонсирована в Chrome 150 beta 3 июня 2026 года. Стабильный релиз ожидается примерно через 6 недель, около июля 2026 года, следуя стандартному циклу релизов Chrome.

Текущая поддержка:

• Chrome 150+ Десктоп и Android — поддерживается
• Chrome 150+ ChromeOS — поддерживается
• Edge, Opera Вероятно, последуют (на Blink)
• Safari Не анонсировано
• Firefox Не анонсировано

Как и в случае с большинством новых функций платформы PWA, Safari и Firefox пока не сообщили о поддержке. Однако поскольку функция использует стандартные поля манифеста и well-known файлы, она ничего не ломает в неподдерживающих браузерах — поля migrate_from и migrate_to просто игнорируются.

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

Часто задаваемые вопросы

Нужна помощь с разработкой PWA?

Миграция origin — лишь одна часть пазла Progressive Web Apps. Создание успешного PWA требует продуманной архитектуры, тщательного подхода к офлайн-стратегиям, управления сервис-воркерами и оптимизации производительности на разных устройствах. Посмотрите мои услуги веб-разработчика — от PWA до полноценных веб-приложений.

Я — full-stack веб-разработчик с глубоким опытом создания PWA для бизнеса в Минске и по всему миру. Если вы планируете PWA-проект, рассматриваете миграцию origin или нуждаетесь в экспертной оценке текущей PWA-архитектуры, свяжитесь со мной. Я предоставляю бесплатные первичные консультации.