פיתוח Progressive Web App (PWA) למובייל

לעתים קרובות פונים אלינו לקוחות עם בקשה לנוכחות ניידת ללא פרסום ב-App Store וב-Google Play. או שכבר יש להם אתר ב-React/Vue/Angular והם צריכים להוסיף מצב לא מקוון, התראות push וסמל מסך בית — מבלי לשכתב הכל מאפס. PWA אמיתי דורש Service Worker עם אסטרטגיית מטמון נכונה, Web App Manifest עם פרמטרים מתאימים לכל פלטפורמה, ו-HTTPS ללא יוצאים מן הכלל. דלגו על אחד משלושת המרכיבים האלה, ותקבלו אפליקציה שלא מתקינה או עובדת לא נכון במצב לא מקוון. בקשו הערכה של הפרויקט שלכם תוך יום אחד — צרו קשר.

היכן PWA בדרך כלל נשברת?

Service Worker ואסטרטגיות מטמון

הטעות הנפוצה ביותר היא שמירת הכל במטמון עם CacheFirst ללא invalidation. המשתמש פותח אפליקציה מעודכנת אבל רואה את הגרסה הישנה כי sw.js מגישה משאבים ממטמון מיושן. Workbox פותר זאת באמצעות StaleWhileRevalidate עבור נכסים סטטיים ו-NetworkFirst עבור בקשות API, אבל צריך להפריד בבירור מה לשמור במטמון באגרסיביות (גופנים, אייקונים, JS bundles עם hashes) ומה תמיד להביא טרי (נתוני משתמש, מלאי, תוכן).

בעיה נוספת היא סנכרון רקע באמצעות Background Sync API. משתמש שולח טופס במצב לא מקוון, ה-Service Worker מיירט את הבקשה ומאחסן אותה ב-SyncManager. כשהקישוריות חוזרת, הבקשה נשלחת. זה נשמע פשוט, אבל registration.sync.register('sync-orders') עובד רק על Chrome/Android. ב-iOS Safari, Background Sync עדיין לא נתמך — יש להתחשב בכך בעת תכנון תרחישים לא מקוונים. לדוגמה, חלופה יכולה להיות שליחת נתונים ידנית כשהחיבור חוזר.

אילו מגבלות קיימות ב-iOS?

אפל מגבילה באופן שיטתי PWAs: עד גרסה 16.4, התראות push ב-PWAs לא עבדו כלל. עכשיו הן עובדות, אבל רק אם האפליקציה נוספה למסך הבית דרך Safari — לא מ-Chrome, לא מ-Firefox. מכסת אחסון ברירת המחדל של IndexedDB ב-iOS היא 50 MB, לעומת גיגה-בייטים באנדרואיד. יש לחשב מראש משאבים שניתן לשמור במטמון. אם אתם מתכננים התראות push, הקפידו להשתמש במפתחות VAPID ושימו לב שב-iOS נדרשת התקנה דרך Safari.

למה PWA עדיפה על פני native בתרחישים מסוימים?

פיתוח PWA מהיר פי 3–5 מאפליקציה native ועולה פי 2–3 פחות. עדכונים מתרחשים אוטומטית, ללא בדיקות חנות. עבור פורטלי מידע, אתרי חדשות ושירותים ארגוניים, PWA לרוב מוכיחה עצמה כיעילה יותר: היא תופסת פחות מקום במכשיר, אינה דורשת התקנה מחנות, וההמרה להתקנה (באמצעות beforeinstallprompt) יכולה להגיע ל-60%. עם זאת, עבור אפליקציות עם אינטגרציה מערכתית עמוקה (מצלמה, Bluetooth, NFC), אפליקציה native נותרה האפשרות היחידה.

איך אנחנו בונים PWAs: שלב אחר שלב

1. ביקורת — בדיקת HTTPS, Core Web Vitals, וה-Service Worker הנוכחי (אם קיים).
2. תצורה — אנו משתמשים ב-Workbox 7.x דרך vite-plugin-pwa. מצב generateSW יוצר אוטומטית precache manifest מה-bundle.
3. Manifest — name, short_name, start_url עם הפרמטר ?source=pwa, display: standalone, theme_color, background_color, אייקונים 192×192 ו-512×512, בתוספת גרסת maskable לאנדרואיד.
4. Service Worker — הגדרת אסטרטגיות: StaleWhileRevalidate עבור נכסים סטטיים, NetworkFirst עבור APIs, CacheFirst עבור משאבים בלתי ניתנים לשינוי.
5. התראות push — רישום מפתחות VAPID, הרשמה דרך PushManager.subscribe().
6. בדיקות — ניפוי באגים עם Lighthouse, Chrome DevTools (Application → Service Workers → Offline) ועל מכשירים אמיתיים.

איך להשיג המרת התקנה גבוהה?

Chrome מציג את הבאנר "הוסף למסך הבית" כאשר מתקיימים קריטריונים: HTTPS, manifest תקין, ו-Service Worker רשום עם fetch handler. Lighthouse בודק את כל התנאים. לשליטה עצמאית, אנו משתמשים באירוע beforeinstallprompt: מיירטים אותו דרך event.preventDefault(), דוחים אותו, ומציגים ממשק משלנו ברגע הנכון, ואז קוראים ל-prompt(). זה נותן לנו שליטה על מתי ולמי להציע התקנה. ב-iOS, ההתקנה היא ידנית בלבד דרך Share → "הוסף למסך הבית" — ללא הנחיות אוטומטיות.

התראות push באמצעות Web Push Protocol

מפתחות VAPID נוצרים פעם אחת, המפתח הציבורי מועבר ללקוח בעת ההרשמה דרך PushManager.subscribe(). בשרת, אנו משתמשים בספריית web-push עבור Node.js או מקבילה. אובייקט ההרשמה עם endpoint, p256dh ו-auth נשמר במסד הנתונים — זה מה שנדרש לשליחה.

// Регистрация подписки
const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: urlBase64ToUint8Array(PUBLIC_VAPID_KEY)
});

השוואה בין PWA לאפליקציות native

מה כלול בעבודה

בשלב הביקורת, אנו בודקים ביצועים (Core Web Vitals), תצורת HTTPS, וה-Service Worker הנוכחי אם קיים. לאחר מכן אנו מפתחים Service Worker עם אסטרטגיות מטמון עבור נתיבים ספציפיים, יוצרים manifest, אייקונים בכל הגדלים, ומסכי splash עבור iOS. אם נדרשות התראות push, אנו מגדירים Web Push ובודקים תרחישים לא מקוונים ב-Chrome DevTools ועל מכשירים אמיתיים. בממוצע, הוספת PWA לאתר קיים אורכת 3–7 ימים, ופיתוח מלא מאפס אורך 2–4 שבועות.

התוצאה מאומתת באמצעות ביקורת PWA של Lighthouse — כל הפריטים חייבים להיות ירוקים. אנו עובדים על PWAs למעלה מחמש שנים, וכל פרויקט עובר בדיקה כזו. הניסיון שלנו כולל אינטגרציה עם Firebase ו-Supabase עבור התראות push וסנכרון רקע.

טעויות אופייניות ביישום PWA:

• התעלמות מ-invalidation של מטמון — משתמשים רואים תוכן מיושן.
• חסר אייקון // Регистрация подписки const subscription = await registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array(PUBLIC_VAPID_KEY) }); — באנדרואיד, האייקון מופיע עם רקע לבן.
• התראות push ללא בדיקת תמיכה ב-iOS.
• שימוש רק ב-CacheFirst עבור APIs — אובדן טריות הנתונים.

לוחות זמנים

הוספת PWA לאפליקציית אינטרנט קיימת: 3–7 ימים. פיתוח PWA מאפס עם לוגיקה לא מקוונת והתראות push: 2–4 שבועות. העלות מחושבת לאחר ניתוח המחסנית הנוכחית והדרישות לפונקציונליות לא מקוונת. אנו נעריך את הפרויקט שלכם תוך יום אחד — צרו קשר לייעוץ.