یک فروشگاه میخواهد روی شبکه ناپایدار سبد کاربر از بین نرود؛ تیم خدمات میدانی میخواهد فرم بازدید را بدون اینترنت پر کند؛ رسانه میخواهد مقاله ذخیرهشده خوانده شود. پاسخ هر سه الزاماً «ساخت PWA» نیست. شاید کش درست، Draft محلی یا وبسایت Responsive کافی باشد؛ شاید هم محدودیت Background، سختافزار یا Store، اپ Native را منطقی کند. PWA نام یک خروجی جادویی نیست؛ مجموعهای از قابلیتهای وب است که باید بر اساس Task، مرورگر و ریسک بهصورت Progressive Enhancement اضافه شود.
این راهنما PWA را از شعار «بهترین وب و اپ» جدا میکند. Product fit، Manifest، Service Worker، نصب، Cache، Offline، Push، Update، امنیت، SEO، iOS/Android، سنجش هزینه و برنامه Pilot را پوشش میدهیم. وضعیت قابلیتها در مرداد ۱۴۰۵ بازبینی شده است؛ Feature support و سیاست Store/Browser متغیرند، پس پیش از تعهد از Feature detection و تست روی Device هدف استفاده کنید.
خلاصه اجرایی: آیا PWA برای شما مناسب است؟
PWA را در Shortlist نگه دارید اگر یک یا چند نیاز واقعی زیر دارید:
- کاربر تکراری است و Launch از Home screen یا Window مستقل اصطکاک را کم میکند؛
- Read-only یا Task محدود باید در قطع/ضعف شبکه ادامه یابد؛
- Push یا Badge برای رویداد زماندار با رضایت کاربر ارزش روشن دارد؛
- یک URL قابلاشتراک و دسترسی بدون Store مزیت توزیع است؛
- تیم میتواند Cache، Version، Queue، Conflict و Browser matrix را اداره کند.
فعلاً PWA نسازید یا ابتدا Prototype کنید اگر تنها دلیل «مد روز»، «SEO بهتر»، «هزینه همیشه کمتر» یا «ارسال Notification بیشتر» است؛ Task بدون شبکه تعریف نشده؛ داده حساس روی Device مشترک میماند؛ API حیاتی در Browser هدف پشتیبانی نمیشود؛ یا تیم Owner برای Service Worker و Incident ندارد.
PWA چیست و چه چیزی نیست؟
Progressive Web App یک Web application است که با قابلیتهای Platform میتواند نصب، در Window مستقل اجرا، بخشی از تجربه را Offline ارائه و در Browserهای سازگار از Push/Badge/Share و APIهای دیگر استفاده کند. «Progressive» یعنی قابلیتها بر اساس پشتیبانی و Permission اضافه شوند و نسخه پایه وب همچنان کار کند.
PWA یک Framework، فایل APK/IPA، استاندارد واحد با Checklist ثابت یا مترادف SPA نیست. ممکن است Multi-page/SSR باشد، Service Worker محدود داشته باشد یا فقط نصبپذیری را هدف بگیرد. همچنین Responsive design جای خود را به PWA نمیدهد؛ نمایش و تعامل موبایل پایهای مستقل است.
| مفهوم | وظیفه | رابطه با PWA |
|---|---|---|
| Responsive web | تطبیق Layout/Interaction با Viewport و Input | پایه ضروری، اما Offline/Install/Push نمیدهد |
| SPA | Navigation و State عمدتاً سمت Client | ممکن است PWA باشد یا نباشد؛ الزام نیست |
| Web App Manifest | Metadata نصب/Launch مانند نام، Icon، Start URL و Display | بخش کلیدی تجربه نصبشده در User agentهای سازگار |
| Service Worker | Proxy برنامهپذیر برای Request/Eventهای پسزمینه | Cache، Offline و Push را ممکن میکند؛ خودکار نیست |
| Native app | بسته پلتفرمی و API/Store integration عمیقتر | گزینه جایگزین یا مکمل |
| Cross-platform wrapper | کد مشترک با Runtime/Bridge و بسته Store | Trade-off متفاوت از PWA و Web-only |
سه لایه اصلی معماری PWA
۱. وب قابلاستفاده بهعنوان پایه
پیش از Manifest و Service Worker، URLها، HTML، فرم، Navigation، Accessibility، Performance و Error state باید سالم باشند. اگر JavaScript یا قابلیت پیشرفته شکست، کاربر باید دستکم محتوای ضروری و راه بعدی را ببیند. برای تست پایه موبایل، از راهنمای Mobile-friendly برای SEO و UX استفاده کنید.
۲. Metadata نصب و Launch
Web App Manifest یک فایل JSON است که User agent از آن برای نام، Icon، start_url، scope، display، id، جهت و زبان استفاده میکند. Snapshot رسمی W3C در مه ۲۰۲۶ هنوز Working Draft است و صریح میگوید پیادهسازیها ممکن است برای استفاده کامل، Memberهای متفاوتی بخواهند: Web Application Manifest.
۳. قابلیتهای Event-driven
Service Worker خارج از DOM و مستقل از عمر یک Tab اجرا میشود و میتواند Requestهای داخل Scope، Push و برخی Eventهای سازگار را مدیریت کند. این لایه قدرتمند است، چون پاسخ Cache یا Network را تعیین میکند؛ و پرریسک است، چون Bug میتواند نسخه قدیمی، Loop یا پاسخ اشتباه را به تعداد زیادی کاربر برساند.
Manifest را مثل قرارداد هویت اپ طراحی کنید
| Member/Asset | تصمیم | خطای رایج |
|---|---|---|
id | هویت پایدار نصب مستقل از تغییر Start URL | تغییر ناخواسته و ایجاد نصب/Identity جدا |
name/short_name | نام روشن در Launcher و UI محدود | نام تبلیغاتی بریده یا ناسازگار با برند |
start_url | صفحه Launch امن و معنادار | UTM ثابت، Redirect chain یا صفحه Login بنبست |
scope | مرز Navigation تحت تجربه اپ | خروج ناگهانی به Browser یا Scope بیشازحد |
display | Browser/standalone/fullscreen بر اساس Task | حذف کنترل Browser بدون Back/Recovery داخلی |
icons | اندازه، Purpose و Safe area چندپلتفرمی | Icon تار، Cropشده یا متن ریز |
dir/lang | هویت فارسی/RTL در سطح Manifest | نام و Shortcut با جهت اشتباه |
| Shortcuts/Screenshots | ورودی سریع و توضیح نصب در Surface سازگار | فرض پشتیبانی یکسان در همه Browserها |
Manifest را Version-controlled، با MIME درست، URLهای ۲۰۰ و Iconهای قابلدسترسی منتشر کنید. Deep link داخل Scope، Launch از حالت Login/Logout و تغییر دامنه را در Test plan بیاورید.
نصب PWA در iOS، Android و Desktop یکسان نیست
عبارت «کاربر با یک کلیک، بدون Store نصب میکند» عمومی نیست. Browser و OS درباره Install surface، Prompt، Package و Launch تصمیم میگیرند. برخی User agentها حتی هر Website را بهشکل App نصب میکنند؛ Manifest همچنان برای هویت و تجربه سفارشی مفید است.
وضعیت عملی نصب
- در Chromium، Install UI و امکان Trigger کردن Dialog در شرایط سازگار وجود دارد؛
beforeinstallpromptاستاندارد وب نیست و عمدتاً Chromium-based است؛ UI نصب را فقط وقتی Event/Feature موجود است نشان دهید؛- در iOS/iPadOS مسیر Add to Home Screen و رفتار UI با نسخه سیستم تغییر کرده است؛ Safari ۲۶ اعلام کرده Website اضافهشده به Home Screen بهطور پیشفرض Web app باز میشود و کاربر میتواند گزینه را تغییر دهد؛
- در Desktop، Safari/Chromium/Edge رفتارهای متفاوت دارند و Firefox الزاماً نصب Manifest-based ارائه نمیکند؛
- بستهبندی برای Store ممکن است با TWA/WKWebView/Package انجام شود، اما Policy، Billing، Review و API Store را باید جدا ارزیابی کرد.
منبع جاری WebKit: قابلیتهای Web App در Safari ۲۶. برای محدودیت Prompt نیز راهنمای Install prompt در MDN هشدار میدهد که beforeinstallprompt غیراستاندارد و Chromium-specific است.
UX نصب سالم
- در ورود اول Prompt ندهید؛ بعد از اینکه کاربر ارزش تکرارشونده را تجربه کرد پیشنهاد کنید؛
- Benefit مشخص بگویید: «دسترسی سریع به سفارشها» نه «تجربه بهتر»؛
- اگر نصب پشتیبانی نمیشود، CTA مرده یا دستور اشتباه نشان ندهید؛
- ردکردن را محترم بشمارید و Prompt داخلی را هر Session تکرار نکنید؛
- Uninstall و پاککردن داده را در Help توضیح دهید؛
- Install rate را با Eligibility/Exposure/Prompt/Accept/Launch مرحلهبندی کنید.
Offline یک Spectrum است، نه Checkbox
Service Worker خودبهخود سایت را Offline نمیکند. باید برای هر Task تعیین کنید در حالت Online، Flaky، Offline و Reconnect چه رخ میدهد.
| سطح | تجربه | سناریوی مناسب |
|---|---|---|
| Offline fallback | صفحه توضیح و راه Retry | حداقل قابلقبول برای مسیر Network-only |
| Read last known | نمایش داده Cache با زمان آخرین Update | مقاله، کاتالوگ یا سفارش گذشته |
| Local draft | ورودی روی Device ذخیره و بعداً ارسال میشود | فرم طولانی یا عملیات میدانی |
| Queued mutation | درخواست با Idempotency و وضعیت Pending صف میشود | اقدام کمریسک و قابلتکرار کنترلشده |
| Offline-first data | Local database و Sync/Conflict model کامل | محصولی که Offline هسته ارزش آن است |
چه چیزی را Offline وانمود نکنیم؟
قیمت، موجودی، مجوز، وضعیت لحظهای و پرداخت نیازمند Freshness یا Verify سرورند. کاربر میتواند سبد را Offline ویرایش کند، اما «خرید موفق» نباید پیش از تأیید Server/درگاه نمایش داده شود. داده Cache باید برچسب «آخرین بهروزرسانی» و Retry داشته باشد.
استراتژی Cache را بر اساس نوع داده انتخاب کنید
یک Cache-first سراسری علت رایج محتوای کهنه و Bug است. Cache API جدا از HTTP cache است و Routeها به سیاستهای متفاوت نیاز دارند. مستند رسمی Chrome/Workbox پنج Strategy رایج را توضیح میدهد: Service worker caching strategies.
| Resource | Strategy شروع | Guardrail |
|---|---|---|
| Asset هششده | Cache first/Precache | Version hash، Expiration و Atomic deploy |
| HTML/Navigation | Network first با Fallback | Timeout، Offline page و جلوگیری از App shell برای ۴۰۴ |
| تصویر عمومی | Stale-while-revalidate یا Cache first | Quota، Expiration، Variant و CORS |
| مقاله عمومی | Network first یا SWR بر اساس Freshness | زمان Update و Purge محتوای اصلاحشده |
| قیمت/موجودی | Network first/Network only | TTL کوتاه، Timestamp و Verify در Commit |
| حساب/داده شخصی | Network only یا Cache خصوصی طراحیشده | Partition بر User، Logout purge و Device مشترک |
| پرداخت/Callback | Network only | Idempotency، Reconciliation و Unknown state |
برای مرزبندی Browser/CDN/Object/Application cache، راهنمای معماری Cache سایت را کنار PWA policy بخوانید.
چرخه Service Worker و مشکل نسخه کهنه
Service Worker جدید معمولاً Install میشود و تا بستهشدن Clientهای تحت کنترل در حالت Waiting میماند. این رفتار برای جلوگیری از اجرای همزمان نسخه ناسازگار Shell و Asset طراحی شده است. skipWaiting() همگانی میتواند صفحه باز را وسط کار به Worker جدید بسپارد و قرارداد نسخه را بشکند.
Release policy پیشنهادی
- Assetها را Content-hash و Manifest build را Atomic منتشر کنید.
- HTML را طوری Cache کنید که Asset نسخه حذفشده را اشاره نکند.
- Worker جدید را در Waiting شناسایی و برای تغییر ناسازگار Prompt «نسخه جدید آماده است» نشان دهید.
- Draft/Checkout فعال را پیش از Reload حفظ یا تکمیل کنید.
- Cacheهای قدیمی را فقط پس از Activation امن حذف کنید.
- Telemetry نسخه Page/Worker/API را برای تشخیص Split-brain ثبت کنید.
- Kill switch، Rollback و Unregister کنترلشده داشته باشید.
راهنمای رسمی چرخه Service Worker lifecycle هدف Waiting/Activation و Update را تشریح میکند.
ذخیره Draft، Queue و Conflict
Offline write از نمایش Cache پیچیدهتر است. هر Mutation باید شناسه پایدار، وضعیت و قانون تکرار داشته باشد.
| مسئله | کنترل |
|---|---|
| ارسال تکراری | Idempotency key و Deduplication سرور |
| Retry بینهایت | Backoff، سقف تلاش و وضعیت Failed قابلمشاهده |
| تغییر همزمان | Version/ETag و Conflict UI؛ نه Last-write-wins پنهان |
| تغییر Schema | Migration IndexedDB با Rollback و Backup محدود |
| Logout/تعویض حساب | Partition و پاکسازی Draft/Cache حساس |
| Device مشترک | Timeout، Encryption متناسب و عدم ذخیره داده پرریسک |
| صف پرشده | Quota/Size limit و انتخاب/حذف توسط کاربر |
Background Sync در همه Browser/حالتها یکسان نیست؛ Queue باید هنگام بازشدن دوباره App نیز قابل ارسال باشد. Feature detection و Pending UI الزامیاند.
Push Notification: Permission یک کانال بازاریابی رایگان نیست
Push میتواند برای وضعیت سفارش، پیام عملیاتی یا Deadline ارزشمند باشد؛ درخواست Permission هنگام اولین بازدید معمولاً Context کافی ندارد. ابتدا Preference داخلی بگیرید، Benefit و Frequency را توضیح دهید، سپس در پاسخ به تعامل مستقیم Permission سیستم را بخواهید.
iOS و Web Push
WebKit از iOS/iPadOS ۱۶.۴ برای Web app اضافهشده به Home Screen، Web Push را پشتیبانی میکند و درخواست Permission باید در پاسخ به تعامل مستقیم کاربر باشد. این به معنای پشتیبانی یکسان در همه Browser/نسخهها یا اجازه Silent push نیست. منبع رسمی: Web Push for Web Apps on iOS and iPadOS.
سیاست Push سالم
- Transactional، Reminder و Marketing را Preferenceهای جدا کنید؛
- هر Notification ارزش، فرستنده و Destination امن داشته باشد؛
- داده حساس را روی Lock screen فاش نکنید؛
- Frequency cap، Quiet hours و Unsubscribe ساده بدهید؛
- Token/Subscription منقضی را پاک و Consent proof را نگهداری کنید؛
- Delivery را معادل دیدهشدن یا Conversion نگیرید؛
- Provider/Endpoint خارجی را از نظر دسترسی، حریم خصوصی و Exit بررسی کنید.
امنیت PWA و Service Worker
Service Worker داخل Origin مانند یک Network proxy برنامهپذیر عمل میکند؛ XSS یا Supply-chain compromise میتواند Cache و Requestها را تحتتأثیر قرار دهد. HTTPS شرط Secure context است، اما امنیت کامل نیست.
- Scope Worker را حداقل و فایل آن را First-party و قابلممیزی نگه دارید؛
- CSP، Subresource policy، Dependency pinning و Build provenance را اجرا کنید؛
- Response قبل از Cache از نظر Status، Origin، Content type و Cacheability اعتبارسنجی شود؛
- Response احرازشده را در Cache عمومی/مشترک نریزید؛
- Logout، Revocation و حذف حساب باید Cache، IndexedDB و Queue حساس را پوشش دهد؛
- Push payload و Deep link را Untrusted input بدانید؛
- Update Worker، Manifest و Offline page در Incident/Revocation plan باشند؛
- پرداخت و تغییر حساس فقط پس از Authorization/Validation سرور انجام شود.
برای دفاع Browser-side و Rollout بدون شکستن Scriptهای لازم، راهنمای Content Security Policy و XSS را ببینید.
PWA ذاتاً سریع نیست
Cache میتواند Navigation تکراری را سریعتر کند، اما Bundle سنگین، Hydration، Long task، Service Worker startup یا Precache بزرگ تجربه اول را بدتر میکنند. Performance را روی First visit، Repeat، Installed، Online/Flaky و Deviceهای اقتصادی جدا بسنجید.
بودجه عملکرد
- JS اولیه و زمان Main thread؛
- حجم Precache و Runtime cache؛
- LCP/INP/CLS واقعی به تفکیک Mode؛
- زمان Launch نصبشده و Route transition؛
- Service Worker install/activate/fetch error؛
- Quota eviction و Cache hit/stale rate؛
- مصرف داده/باتری برای Sync و Push.
راهنمای سرعت سایت و Performance budget روش اتصال Lab، Field/RUM و KPI کسبوکار را توضیح میدهد.
Accessibility در حالت Standalone
وقتی Chrome مرورگر پنهان میشود، App باید Navigation و Recovery خود را درست انجام دهد. این موارد را تست کنید:
- Back، Deep link، Refresh، Escape و بازگشت از لینک خارج Scope؛
- Focus پس از Route transition و Dialog نصب/Update؛
- Screen reader announcement برای Offline/Pending/Sync/Updated؛
- Keyboard و Pointer در Desktop installed window؛
- Zoom، Reflow، Safe area، Orientation و Virtual keyboard؛
- Reduced motion و عدم استفاده از Animation بهعنوان تنها Status؛
- رنگ/آیکون/نام مناسب در Launcher و App switcher؛
- فارسی/RTL، Bidi و اعداد/تاریخ/ارز در Manifest و UI.
PWA چه اثری بر SEO دارد؟
PWA چون روی Web و URLهاست میتواند محتوای قابل Crawl داشته باشد، اما نصبپذیری، Manifest یا Service Worker رتبه بهتر تضمین نمیکنند. App shell خالی، CSR شکستخورده، URLهای بدون Deep link، Soft ۴۰۴ یا Cache قدیمی میتوانند Discovery/Render/Index را بدتر کنند.
HTML اولیه، URL مستقل، Link واقعی، Status، Canonical، Metadata/Schema Route-aware و برابری محتوا را حفظ کنید. جزئیات در راهنمای سئو PWA، رندر JavaScript و Index آمده است.
PWA، Native یا Cross-platform؟
| معیار | Responsive/PWA | Cross-platform wrapper | Native |
|---|---|---|---|
| توزیع URL | مستقیم و قابلاشتراک | Web + Store بسته به معماری | عمدتاً Store/Deep link |
| نصب | وابسته به Browser/OS | Package و Store | Store/Enterprise |
| Offline | قابلطراحی با SW/Storage | قابلطراحی با Runtime/Native storage | کنترل عمیقتر، همچنان نیازمند معماری |
| API دستگاه | Feature-dependent و ناهمسان | Bridge/Plugin-dependent | عمیقتر و سریعتر به API جدید |
| Background | محدود به سیاست Browser/OS | به Plugin/Policy وابسته | کنترل بیشتر با محدودیت OS |
| عملیات | Web deploy + SW lifecycle | Web/Native build و Store review | چند Release train و Store |
| هزینه | ممکن است کمتر باشد، نه تضمینی | Reuse بیشتر با هزینه Bridge | بالاتر در برخی Scopeها، اما مناسب قابلیت عمیق |
Decision gates
- سه Task اصلی و Frequency بازگشت کاربر چیست؟
- چه Taskای باید Offline/Poor network کار کند و Definition of done آن چیست؟
- API/Permission لازم در Browser/OS/نسخه هدف واقعاً پشتیبانی میشود؟
- آیا Store discovery، In-app purchase یا Device integration جزء مدل کسبوکار است؟
- داده روی Device چه حساسیت و Retentionی دارد؟
- هزینه Browser matrix، Service Worker operations و Support چقدر است؟
- نسخه Web بدون قابلیت پیشرفته چه تجربهای دارد؟
- کدام Evidence در Pilot تصمیم Go/No-go میسازد؟
سناریوهای مناسب و نامناسب
| سناریو | تناسب | دلیل |
|---|---|---|
| رسانه با مطالعه ذخیرهشده | خوب برای Pilot | Read offline، URL و Update کنترلپذیر |
| کاتالوگ فروش با سبد محلی | خوب با Guardrail | Browse ضعیفشبکه؛ قیمت/موجودی/پرداخت باید Online Verify شود |
| فرم بازدید میدانی | قوی اما پیچیده | Draft/Queue ارزش دارد؛ Conflict/Encryption/Sync لازم است |
| وبلاگ کمبازگشت | اغلب کمارزش | هزینه Install/SW ممکن است از Benefit بیشتر باشد |
| بازی گرافیکی با API عمیق | نیازمند Benchmark | Performance، Store و Device API تعیینکنندهاند |
| پرداخت کامل Offline | نامعتبر | Authorization، موجودی و Verify نیازمند Server/شبکهاند |
ملاحظات ویژه کاربران ایران
- شبکه: Offline را از روی کلیشه نسازید؛ RUM و پژوهش نشان دهد کدام Route/ISP/Device مشکل دارد.
- سرویس خارجی: Push provider، Font، Map، Captcha، Analytics و CDN را برای دسترسی، Policy، Failover و Exit ارزیابی کنید.
- پرداخت: Cart/Draft میتواند Local باشد، اما مبلغ/موجودی و موفقیت پرداخت باید Server-side تأیید شوند؛ Callback در Cache نیفتد.
- OTP: Delay/Resend/Expiry و بازگشت به App نصبشده را روی Android/iOS تست کنید.
- RTL: Manifest
dir/lang، Shortcut، Notification، Bidi URL/شماره و فونت فارسی را پوشش دهید. - Device: Precache بزرگ و JS سنگین روی گوشی اقتصادی و Storage محدود هزینه دارد.
- حریم خصوصی: Push، Location، Camera و Draft حساس نیازمند Purpose، Permission و Retention روشناند.
- Store: PWA میتواند دسترسی مستقیم وب بدهد، اما نصب، Discovery و Policy روی همه Platformها یکسان نیست.
اندازهگیری موفقیت PWA
Install و Push opt-in هدف نهایی نیستند. Metric tree را به Task و Outcome وصل کنید.
| لایه | Metric | Guardrail |
|---|---|---|
| Eligibility/Install | Eligible→Exposed→Prompt→Accepted→First launch | Prompt fatigue و Uninstall |
| Offline | Offline task success، Draft saved، Sync success/time | Conflict، duplicate، stale data و queue loss |
| Push | Opt-in، Delivery، Open، Task completion | Unsubscribe، complaint و frequency |
| Performance | CWV، launch/route time و cache hit/stale | JS/Storage/Data/Battery |
| Reliability | SW error، update mismatch، API/error و rollback | Incident by version/browser |
| Business | Contribution، qualified task، retention افزایشی | Attribution و Control group |
Installed users خودانتخابگر و احتمالاً وفادارترند؛ مقایسه خام آنها با Web users اثر PWA را ثابت نمیکند. انتشار مرحلهای، Eligibility-matched cohort یا Experiment مناسب بسازید. برای TCO/Payback و Counterfactual از راهنمای محاسبه ROI طراحی سایت استفاده کنید.
Test matrix پیش از انتشار
| محور | Caseهای حداقلی |
|---|---|
| Browser/OS | Chrome/Android، Safari/iOS جاری و یک نسخه پشتیبانیشده، Desktop هدف |
| Mode | Browser tab، Installed/Standalone، Deep link و بازشدن از Notification |
| Network | Online، Slow، Flaky، Offline، Reconnect و DNS/API failure |
| Version | Fresh install، Update waiting، چند Tab، Rollback و Asset حذفشده |
| Identity | Guest، Login، Logout، تعویض حساب و Device مشترک |
| Storage | Quota کم، Eviction، Corrupt DB و Migration |
| Task | Read، Draft، Queue، Conflict، Payment return و Error recovery |
| Accessibility | Keyboard، Screen reader، Zoom، RTL، reduced motion و status announcement |
Logها باید Page version، Worker version، Route، Browser/OS class و Mode را بدون Fingerprinting غیرضروری ثبت کنند. برای SLO، Alert، Trace و Release annotation، راهنمای Observability سایت را ببینید.
برنامه Pilot هشتهفتهای
هفته ۱–۲: Discovery و Feature matrix
- Task، Segment، Network و Browser target را از داده واقعی انتخاب کنید.
- Responsive baseline و مشکل قابلحل را اندازه بگیرید.
- API/Permissionها را با Feature detection روی Device تست کنید.
- TCO، Risk register، Success/Guardrail و Kill criteria بسازید.
هفته ۳–۴: Vertical slice
- Manifest، Icon، Launch و یک Task مستقل را پیاده کنید.
- Cache policy Route-specific و Offline fallback بسازید.
- Update/rollback و نسخه Worker/Page/API را ثبت کنید.
- Security/Privacy/Accessibility review اجرا کنید.
هفته ۵–۶: Offline/Push با دامنه محدود
- فقط یک Draft/Read task را Offline کنید.
- Idempotency، Queue، Retry و Conflict را تست کنید.
- Push را برای یک Use case زماندار و Opt-in اجرا کنید.
- Browser/OS/Network matrix واقعی را کامل کنید.
هفته ۷–۸: انتشار مرحلهای و تصمیم
- Rollout کوچک با RUM، Error و Support monitoring انجام دهید.
- Installed/eligible/control را بدون Selection-bias ساده مقایسه نکنید.
- Benefit، هزینه عملیات و Incident را با فرض اولیه بسنجید.
- Go/Iterate/Stop را بر Task success و Guardrail تصمیم بگیرید.
چکلیست نهایی PWA
- نیاز Install/Offline/Push از Task واقعی آمده، نه Trend.
- نسخه Web پایه بدون قابلیت پیشرفته قابلاستفاده است.
- Manifest، id/start_url/scope/display/icons/dir/lang تست شدهاند.
- Install UX بر اساس Feature detection است و Prompt مزاحم نیست.
- برای هر Route سیاست Cache، TTL، Version و Purge داریم.
- قیمت، موجودی، حساب و پرداخت Stale یا عمومی Cache نمیشوند.
- Offline state، Timestamp، Pending، Retry و Conflict روشناند.
- Mutationها Idempotency، Dedup و سقف Retry دارند.
- Service Worker update، Waiting، rollback و Kill switch تست شدهاند.
- Logout/تعویض حساب Cache، DB و Queue حساس را پاک میکند.
- Push Purpose، Permission، Frequency، Privacy و Unsubscribe دارد.
- CSP، Dependency، Cache validation و Deep link امناند.
- First/repeat/installed و Browser/OS/Network واقعی سنجیده میشوند.
- Standalone navigation و Accessibility کامل تست شدهاند.
- SEO به HTML/URL/Status/Canonical متکی است، نه نصبپذیری.
- TCO، Owner، Monitoring و معیار Go/No-go ثبت شدهاند.
سؤالات متداول
PWA چیست؟
PWA یک Web application است که با Progressive enhancement میتواند قابلیتهایی مانند نصب، Window مستقل، Offline محدود، Push و Integration پلتفرمی را در Browserهای سازگار ارائه دهد. PWA Framework یا مترادف SPA نیست و هر قابلیت به Manifest، Service Worker، Permission و پشتیبانی Platform وابسته است.
آیا PWA روی همه گوشیها نصب میشود؟
مسیر و سطح نصب میان Browser، OS و نسخه متفاوت است. beforeinstallprompt عمدتاً Chromium-specific و روی iOS پشتیبانی نمیشود؛ iOS مسیر Add to Home Screen خود را دارد. Manifest و Feature detection بسازید و روی Deviceهای هدف تست کنید.
آیا PWA بدون اینترنت کامل کار میکند؟
نه خودکار و نه لزوماً کامل. شما تعیین میکنید چه Asset/دادهای Cache، چه Draftی Local و چه Mutationی Queue شود. پرداخت، قیمت و موجودی معمولاً به Network و Verify سرور نیاز دارند. Offline باید Timestamp، Pending، Retry و Conflict داشته باشد.
آیا PWA از اپ Native ارزانتر است؟
گاهی، اما تضمینی نیست. یک Codebase وب میتواند هزینه را کم کند، ولی Browser matrix، Service Worker، Sync، Store packaging، Security، QA و Operations هزینه دارند. مقایسه را با Scope و TCO یکسان انجام دهید.
آیا PWA سئو را بهتر میکند؟
نصب، Manifest یا Service Worker سیگنال تضمینی رتبه نیستند. چون PWA روی Web است میتواند URL و HTML قابل Crawl داشته باشد؛ اما CSR، App shell، Status، Canonical و Cache غلط ممکن است Index را آسیب بزنند. اصول JavaScript SEO را مستقل اجرا کنید.
جمعبندی
PWA آینده قطعی همه سایتهای موبایل نیست؛ یک گزینه معماری برای Taskهای مشخص است. ارزش آن زمانی شکل میگیرد که نصب، Offline یا Push درد واقعی را حل کند و تیم بتواند Cache، Update، Queue، Security و Browser fragmentation را اداره کند.
از Responsive web سالم شروع کنید، یک Vertical slice بسازید و قابلیتها را با Feature detection اضافه کنید. نتیجه را با Task success، Reliability، هزینه عملیات و Outcome افزایشی بسنجید. اگر Pilot نشان داد ارزش بیشتر از پیچیدگی است، PWA را گسترش دهید؛ اگر نه، همان وب خوب پاسخ بهتری است.
