Declarative Web Push چیست؟ اعلان وب در Safari بدون وابستگی به سرویس‌ورکر

در مسیر رایج وب‌پوش، رسیدن پیام کافی نیست؛ کد سرویس‌ورکر باید آن را پردازش کند و اعلان بسازد. Declarative Web Push یا وب‌پوش اعلانی برای مرورگرهای پشتیبان، توضیح آماده اعلان را به خود مرورگر می‌دهد. این تغییر، بخش نمایش را کمتر به اجرای موفق کد وابسته می‌کند. برای یک سایت، سؤال اصلی این است که چگونه از این مسیر استفاده کند و در همان زمان، کاربران مرورگرهای دیگر را از دست ندهد.

این راهنما درباره معماری و تصمیم‌های مهاجرت است. امکان ارسال چنین قالبی از یک ارائه‌دهنده پوش باید جداگانه بررسی شود؛ توضیح این قابلیت به معنی فعال‌بودن آن در SDK یا پنل پوشفا نیست.

وب‌پوش اعلانی چه چیزی را تغییر می‌دهد؟

در وب‌پوش معمولی، سرویس‌ورکر رویداد پوش را می‌گیرد، داده را می‌خواند و با showNotification اعلان می‌سازد. در مدل اعلانی، پیام حاوی توصیفی است که مرورگر پشتیبان می‌تواند مستقیم نمایش دهد. سرویس‌ورکر همچنان می‌تواند برای پردازش اختیاری حضور داشته باشد. توضیح معماری WebKit این استقلال مسیر نمایش از JavaScript را توضیح می‌دهد.

برای فهم اثر عملی، دو خرابی را جدا کنید: «پیام به محیط دریافت نمی‌رسد» و «پیام رسیده ولی کد نمایش شکست می‌خورد». مدل اعلانی برای مسئله دوم مسیر جایگزین دارد؛ مشکل شبکه، مجوز لغوشده یا مقصد اشتراک نامعتبر را خودبه‌خود حل نمی‌کند. پس در گزارش پشتیبانی، علت‌های انتقال و علت‌های نمایش همچنان باید جدا ثبت شوند.

اگر هنوز نقش اشتراک، VAPID و سرویس‌ورکر برایتان روشن نیست، ابتدا راهنمای زیرساخت فنی وب‌پوش را بخوانید. تغییر قالب اعلان، جای طراحی درست ثبت و نگه‌داری اشتراک را نمی‌گیرد.

پشتیبانی Safari و شرط نصب در آیفون

Apple در جلسه WWDC25 درباره Declarative Web Push مسیر استفاده را برای Safari نسخه ۱۸٫۵ و بالاتر در macOS، و وب‌اپ‌های اضافه‌شده به صفحه اصلی در iOS و iPadOS نسخه ۱۸٫۴ و بالاتر معرفی کرده است. در آیفون، یک تب معمولی را معادل وب‌اپ نصب‌شده فرض نکنید. راهنمای فعال‌سازی وب‌پوش در آیفون مسیر عضویت را جدا توضیح می‌دهد.

برای انتشار واقعی، یک جدول سازگاری با دستگاه‌های مخاطبان خود بسازید. ستون‌ها شامل مرورگر، نسخه سیستم‌عامل، حالت تب یا وب‌اپ، مسیر ثبت اشتراک و نتیجه نمایش باشند. بررسی وجود قابلیت، از حدس براساس نام مرورگر بهتر است؛ وجود window.pushManager نشانه‌ای برای انتخاب مسیر ثبت است، اما آزمون ارسال و کلیک را جایگزین نمی‌کند.

پشتیبانی این نسخه‌های Apple به معنی پشتیبانی همه مرورگرها نیست. کاربران مسیر قدیمی را تا زمانی نگه دارید که ثبت، ارسال و نمایش در مسیر تازه برای محیط واقعی آن‌ها بررسی شده باشد.

قالب پیام چه شکلی است؟

برای پردازش اعلانی، JSON باید ساختار مورد انتظار مرورگر را داشته باشد. کلید web_push با مقدار 8030 آن را مشخص می‌کند؛ توضیح اعلان زیر notification می‌آید و عنوان غیرخالی و مقصد navigate ضروری‌اند. نمونه زیر صرفاً قالب آموزشی است:

{
  "web_push": 8030,
  "notification": {
    "title": "وضعیت سفارش به‌روز شد",
    "body": "جزئیات تازه را در حساب خود ببینید.",
    "lang": "fa",
    "dir": "rtl",
    "navigate": "https://example.org/orders"
  }
}

ساختار در مستند معرفی WebKit آمده است. این JSON درخواست آماده ارسال به API پوشفا نیست؛ ارائه‌دهنده باید قالب را بدون تغییر ناسازگار به مسیر Web Push برساند. صرف افزودن این کلیدها به یک payload دلخواه FCM، سازگاری را اثبات نمی‌کند.

برای تیم محتوا، اهمیت نمونه در کوتاه‌بودن پیام و روشن‌بودن مقصد است. جزئیات سفارش را روی صفحه حساب نشان دهید؛ عنوان اعلان محل مناسبی برای نام کامل، شماره تماس یا اطلاعات پرداخت نیست. صفحه مقصد نیز باید دسترسی کاربر را دوباره بررسی کند.

Fallback را مانند متن اصلی طراحی کنید

در حالت پردازش اختیاری، پیام می‌تواند با mutable از سرویس‌ورکر کمک بگیرد. اگر پردازش جایگزین موفق نشود، توصیف اولیه اعلان می‌تواند نمایش داده شود؛ این رفتار در توضیح Apple درباره سرویس‌ورکر اختیاری آمده است. بنابراین fallback بخشی از تجربه کاربر است و نباید متنی آزمایشی یا حاوی داده حساس باشد.

یک قاعده پیشنهادی: متن پایه باید حتی بدون اجرای هیچ منطق سفارشی، درست و قابل فهم بماند. «جزئیات سفارش تغییر کرده» از «بسته شما دقیقاً ساعت ۱۴ می‌رسد» ایمن‌تر است، اگر زمان رسیدن ممکن است بعد از تولید پیام تغییر کند. صفحه مقصد آخرین وضعیت را از سرور بخواند.

این قابلیت راهی برای پوش نامرئی نیست؛ هدف آن حفظ اعلان قابل مشاهده است. کم‌کردن صدا با حذف نمایش فرق دارد. اگر هدف شما تازه‌کردن داده داخل یک صفحه باز است، آن نیاز را جدا از کانال اعلان کاربر طراحی کنید. تفاوت این دو در راهنمای Silent Push در وب و اپلیکیشن بررسی شده است.

یک مثال فرضی برای مهاجرت فروشگاه

فرض کنید فروشگاهی برای تغییر وضعیت سفارش، وب‌پوش می‌فرستد. بعضی مشتریان وب‌اپ آیفون دارند و بقیه از مرورگرهای دیگر استفاده می‌کنند. هدف مهاجرت این است که متن مفید در محیط پشتیبان نمایش داده شود و مسیر کاربران دیگر نیز کار کند.

1. رویداد را ثابت نگه دارید: یک تغییر واقعی سفارش، مبنای تولید پیام باشد. تغییر فرمت نباید به ساخت دو رویداد مستقل تبدیل شود.
2. قالب و کانال را جدا انتخاب کنید: ابتدا نیاز پیام و مقصد را تعیین کنید، سپس براساس توان مسیر ارسال، توصیف مناسب بسازید.
3. سرویس‌ورکر قدیمی را هماهنگ کنید: برای مرورگر فاقد پشتیبانی، کد باید قالب تازه را بفهمد. فقط تغییر JSON در سرور کافی نیست.
4. نمایش تکراری را بررسی کنید: روشن باشد کدام لایه اعلان را می‌سازد؛ رفتار خودکار مرورگر و منطق سفارشی نباید بدون بررسی هم‌زمان فعال شوند.
5. نتیجه را مرحله‌ای بخوانید: پذیرش ارسال، نمایش و کلیک را جدا بسنجید؛ کاهش خطای کد را از افزایش تحویل شبکه نتیجه نگیرید.

این تقسیم کار را به یک سند کوتاه تبدیل کنید: مسئول قالب، مسئول سرویس‌ورکر و مسئول گزارش‌گیری مشخص باشند. در مرور تغییرات، نمونه پیام و نتیجه دستگاه واقعی را کنار هم ببینید. تحلیل این مراحل در راهنمای سنجش تحویل، کلیک و تبدیل توضیح داده شده است.

چک‌لیست انتشار تدریجی

پیش از تغییر مسیر همه مشترکان، یک گروه محدود آزمایشی انتخاب کنید. این چک‌لیست پیشنهادی، خطاهای مربوط به قالب، نمایش و مقصد را از هم جدا می‌کند:

• امکان ارسال قالب اعلانی را با ارائه‌دهنده و نسخه SDK بررسی کرده‌اید.
• عنوان فارسی، راست‌به‌چپ بودن، متن و مقصد معتبر در نمونه واقعی دیده شده‌اند.
• رفتار وب‌اپ نصب‌شده را از تب معمولی جدا ثبت کرده‌اید.
• حالت صفحه باز، صفحه بسته و شکست پردازش اختیاری بررسی شده است.
• مرورگر فاقد پشتیبانی، هنوز از سرویس‌ورکر سازگار اعلان می‌گیرد.
• پیام پایه بدون داده حساس، دقیق و مستقل از JavaScript است.
• کلیک، کاربر خارج‌شده از حساب را به اطلاعات خصوصی راه نمی‌دهد.
• روش برگشت به مسیر قبلی و نسخه قالب پیام مشخص است.

برنامه بازگشت فقط برگرداندن کد سرور نیست؛ سرویس‌ورکرهای نصب‌شده روی دستگاه‌ها هم ممکن است نسخه متفاوت داشته باشند. پیش از انتشار، تعیین کنید چه ترکیبی از نسخه قدیمی و جدید پشتیبانی می‌شود. هدف، یک مسیر قابل توضیح برای هر کاربر است، نه حذف فوری فایل‌های قبلی.

پرسش‌های متداول

آیا می‌توان سرویس‌ورکر سایت را حذف کرد؟

فقط پس از بررسی نیازهای سایت و سازگاری کاربران. اختیاری‌شدن آن در مسیر اعلانی پشتیبان، وابستگی مرورگرهای دیگر یا قابلیت‌های آفلاین سایت را حذف نمی‌کند.

آیا اعلان اعلانی بدون اجازه کاربر نمایش داده می‌شود؟

خیر. این مدل مسیر نمایش را تغییر می‌دهد؛ مجوز و اشتراک معتبر همچنان لازم‌اند. درخواست عضویت را به انتخاب روشن کاربر مرتبط کنید.

آیا با تغییر payload، پشتیبانی پوشفا فعال می‌شود؟

چنین نتیجه‌ای نمی‌توان گرفت. سازگاری قالب با مسیر ارسال و SDK باید بررسی شود؛ این مقاله ادعای پشتیبانی فعلی پوشفا را مطرح نمی‌کند.

پشتیبانی و منابع رسمی این راهنما در ۲۰۲۶-۰۹-۳۰ بررسی شده‌اند.