Czym są Declarative Web Push Notifications i dlaczego to zmienia wszystko?

W marcu 2025 roku WebKit – silnik napędzający Safari – opublikował coś, co w środowisku web developerów przeszło niemal niezauważone, ale dla branży push marketingu ma naprawdę spore znaczenie. Declarative Web Push to nowy sposób wysyłania powiadomień push, który nie wymaga service workera, jest bardziej prywatny i energooszczędny. I tak – w XPUSH mamy to już wdrożone.

Jak działał Web Push do tej pory?

Żeby zrozumieć, co zmienia nowy standard, trzeba najpierw wiedzieć, z czym mamy do czynienia dziś. Klasyczny Web Push działa w oparciu o service worker – kawałek JavaScriptu działający w tle przeglądarki. Kiedy serwer wysyła powiadomienie push do przeglądarki, to właśnie service worker je odbiera, parsuje i decyduje, co pokazać użytkownikowi.

Brzmi w miarę sensownie. Problem w tym, że ta architektura od początku miała swoje bolączki, szczególnie na urządzeniach Apple. WebKit (Safari) podszedł do tematu bardzo ostrożnie i wprowadził kilka restrykcji, które miały chronić prywatność i baterię użytkownika:

• Wymóg flagi userVisibleOnly = true – żadnych cichych push w tle, każde powiadomienie musi być widoczne. Logiczne, ale trudne do wyegzekwowania technicznie.
• ITP (Intelligent Tracking Prevention) – Safari automatycznie usuwa dane stron, których nie odwiedzałeś od jakiegoś czasu. Włącznie z rejestracją service workera. Co oznaczało, że push subskrypcja przestawała działać – po cichu, bez żadnego ostrzeżenia.
• Kara za brak powiadomienia – jeśli service worker z jakiegoś powodu nie pokazał powiadomienia (błąd w skrypcie, warunki sieciowe, cokolwiek), przeglądarka mogła odebrać subskrypcję. Debugowanie tego było… przyjemnością.

W efekcie wdrożenie Web Push na Safari wymagało dużo więcej uwagi niż na Chrome czy Firefox. I to właśnie WebKit postanowił rozwiązać od podstaw.

Declarative Web Push – push bez JavaScriptu

Idea jest prosta i elegancka: zamiast kazać przeglądarce uruchamiać JavaScript, żeby wyświetlić powiadomienie, wystarczy wysłać gotowy opis tego powiadomienia w formacie JSON. Przeglądarka sama go odczyta i wyświetli – bez żadnego kodu po drodze.

To właśnie „deklaratywność" – zamiast instruować przeglądarkę krok po kroku co robić (imperatywnie), po prostu opisujesz co chcesz osiągnąć (deklaratywnie).

Wiadomość push w nowym formacie wygląda tak:

{
  "web_push": 8030,
  "notification": {
    "title": "Nowa oferta tylko dla Ciebie!",
    "lang": "pl",
    "dir": "ltr",
    "body": "Twój ulubiony produkt właśnie wrócił do sklepu.",
    "navigate": "https://twojasklep.pl/produkt/xyz",
    "silent": false,
    "app_badge": "3"
  }
}

Pole web_push: 8030 to magiczny klucz – nawiązanie do RFC 8030, który definiuje protokół push w HTTP. Jego obecność mówi przeglądarce: „to jest wiadomość deklaratywna, obsłuż ją samodzielnie". Reszta to po prostu opis powiadomienia: tytuł, treść, URL do otwarcia po kliknięciu i opcjonalna odznaka aplikacji.

Co dokładnie się zmienia?

Poza samym formatem wiadomości, Declarative Web Push wprowadza jeszcze jedną ważną zmianę w API. Do tej pory jedynym sposobem na uzyskanie subskrypcji push był:

// stary sposób – wymaga service workera
const registration = await navigator.serviceWorker.register('/sw.js');
const subscription = await registration.pushManager.subscribe({ ... });

Teraz można to zrobić bez service workera w ogóle:

// nowy sposób – bez service workera
const subscription = await window.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: arrayForPublicKey
});

window.pushManager – to małe API ma duże znaczenie. Oznacza, że push subskrypcja staje się niezależna od service workera i jego cyklu życia. ITP może spokojnie usuwać dane – subskrypcja nadal żyje.

A jeśli masz service workera i go używasz? Też działa. Gdy Declarative Web Push dotrze do urządzenia, service worker może nadal przechwycić wiadomość i zmienić treść powiadomienia (np. odszyfrować zawartość albo pobrać dodatkowe dane). Jeśli tego nie zrobi w czasie – przeglądarka po prostu wyświetli wersję z JSON. Żadnych kar, żadnych utraconych subskrypcji.

Dlaczego to jest naprawdę lepsze?

• Energooszczędność. Brak uruchamiania JavaScriptu przy każdym powiadomieniu oznacza mniejsze zużycie CPU i baterii. Apple kładzie na to duży nacisk i tu Declarative Web Push dostarcza to, czego IOS-owi brakowało w oryginalnej specyfikacji.
• Prywatność przez design. Push bez service workera oznacza mniej danych przechowywanych przez stronę, mniej punktów, które ITP musi czyścić, i mniej możliwości śledzenia użytkownika w tle.
• Prostota dla dewelopera. Mniej kodu, mniej rzeczy, które mogą pójść nie tak. Nowy format JSON jest jednolity dla wszystkich projektów, co zmniejsza koszty utrzymania i ułatwia onboarding nowych developerów.
• Wsteczna kompatybilność. Jeśli wyślesz Declarative Web Push do starszej przeglądarki, która tego nie obsługuje, jej service worker obsłuży wiadomość po staremu – o ile jest do tego odpowiednio napisany. Migracja jest stopniowa, bezbolesna.
• Koniec z „cichymi push". Skoro powiadomienie jest opisane deklaratywnie w samej wiadomości, przeglądarka zawsze ma co pokazać. Nie ma możliwości wysłania cichego push, który obudzi urządzenie bez wiedzy użytkownika.

Gdzie to już działa?

Declarative Web Push jest dostępny od: iOS 18.4, iPadOS 18.4 i macOS 15.5. WebKit ogłosił to w marcu 2025 roku, jednocześnie aktywnie pracując nad ustandaryzowaniem rozwiązania w W3C – zmiany trafiły już do specyfikacji Push API i Notifications API.

Chrome i Firefox na razie tego nie implementują, ale WebKit aktywnie zachęca innych vendorów. Propozycje zmian w specyfikacjach zostały dobrze przyjęte na forum W3C podczas TPAC 2023. To kwestia czasu.

XPUSH już to wdrożył – i odczuliśmy różnicę

Kiedy WebKit opublikował specyfikację, wiedzieliśmy, że to nie jest coś, na co można czekać. Declarative Web Push rozwiązuje dokładnie te problemy, na które skarżyli się nasi klienci korzystający z Safari i iOS – subskrypcje padające przez ITP, błędy service workerów, które trudno było zdebugować.

Wdrożyliśmy Declarative Web Push w infrastrukturze XPUSH i efekty były widoczne szybko:

• Integracja narzędzia stała się prostsza. Klienci wdrażający XPUSH na swoich stronach nie muszą już martwić się o konfigurację service workera pod Safari. Jeden snippet kodu, jedno API – działa wszędzie.
• Dotarcie do użytkowników iOS wzrosło. Subskrypcje na urządzeniach Apple przestały „znikać" po dłuższej nieobecności użytkownika. Baza aktywnych subskrybentów jest stabilniejsza, a kampanie docierają do większej liczby osób.
• Mniej problemów technicznych do debugowania. Deklaratywny format JSON jest przewidywalny. Wiadomo co zostanie wyświetlone jeszcze przed wysłaniem wiadomości. To ogromna ulga dla zespołów, które wcześniej spędzały godziny na tropieniu błędów w service workerach.

Declarative Web Push to jeden z tych standardów, które sprawiają, że web staje się lepszy dla wszystkich – użytkowników, deweloperów i firm takich jak XPUSH, które budują na nim swoje produkty.

Co z tego wynika dla Ciebie?

Jeśli prowadzisz stronę lub aplikację webową i chcesz wysyłać powiadomienia push do użytkowników Safari na iPhone i Mac, Declarative Web Push to najlepsza opcja jaką dziś masz. Prostsza niż klasyczny Web Push, bardziej niezawodna i gotowa na przyszłość.

A jeśli korzystasz z XPUSH – masz to już z pudełka. Nie musisz nic konfigurować. Nasz system automatycznie wysyła wiadomości w formacie deklaratywnym do przeglądarek, które to obsługują, a do starszych – w klasycznym. Żadnych kompromisów po Twojej stronie.

• Nie potrzebujesz service workera do push subskrypcji na Safari.
• ITP nie zniszczy już subskrypcji Twoich użytkowników iOS.
• Format JSON jest wstecznie kompatybilny – stare przeglądarki nadal obsługiwane.
• Integracja z XPUSH oznacza wsparcie dla nowego standardu bez żadnego dodatkowego wysiłku z Twojej strony.

Web push właśnie stał się łatwiejszy. Czas to wykorzystać.

Źródło: WebKit Blog – Meet Declarative Web Push (Brady Eidson, 27 marca 2025)