העברה חלקה של מקורות PWA: שינוי דומיינים בלי לאבד משתמשים

Dibyajyoti Pal

Dan Murphy

Marijn Kruisselbrink

תאריך פרסום: 3 ביוני 2026

אפליקציות מסוג Progressive Web App ‏ (PWA) חוללו מהפכה באינטרנט בכך שהן מציעות חוויית שימוש שדומה לזו של אפליקציה. אבל אחד היתרונות הגדולים שלהם הוא גם אתגר מתמשך: זהות האפליקציה קשורה באופן הדוק למקור האינטרנט.

כדי למתג מחדש את הארכיטקטורה או לשנות את המבנה שלה (לדוגמה, מעבר מ-www.example.com/social ל-social.example.com), נתקלתם בדילמה לא פשוטה. אי אפשר 'להעביר' אפליקציית PWA שהותקנה. המשתמשים נאלצו להסיר ידנית את האפליקציה הישנה ולחפש את לחצן ההתקנה של האפליקציה החדשה.

צוות PWA שמח להציג את העברת מקורות של PWA ב-Chrome 150. התכונה החדשה הזו בפלטפורמה מאפשרת מעבר חלק של אפליקציות PWA מותקנות למקור חדש באותו אתר עם הפרעה מינימלית למשתמשים, תוך שמירה על שקיפות מספקת כלפי המשתמשים.

מה אפשר לעשות באמצעות העברת נתונים מ-Origin

אתם יכולים לשנות את ארכיטקטורת האתר בלי לפגוע בחוויית המשתמש:

• חופש בארכיטקטורה הטכנית: אפשר לשנות את נתיב האפליקציה או את שם הדומיין שלה.
• תיקון מצבים של אפליקציה מפוצלת: נפתרה הבעיה שבה שינוי של start_url בלי מזהה יציב יצר בטעות התקנות כפולות של האפליקציה.

המשתמשים יכולים להעביר את האפליקציות שלהם באמצעות תיבת דו-שיח פשוטה לעדכון. הם מקבלים הודעה על המיגרציה בדומה לעדכון לאפליקציה. בלחיצה אחת מסירים את האפליקציה הישנה ומתקינים ומפעילים את האפליקציה החדשה.

איך מעבירים PWA

כדי להעביר PWA, פועלים לפי השלבים הבאים. בהמשך הפוסט מפורטים עוד פרטים:

1. פריסת הלחיצת יד:
   • מוסיפים את migrate_from לאפליקציה החדשה.
   • מוסיפים את השדה allow_migration לקובץ /.well-known/web-app-origin-association במקור הישן.
2. בחירת התנהגות: suggest (או ריק) מונעת שיבוש של חוויית המשתמש, וזה יכול להיות שימושי בשלב ההשקה הראשוני. force חוסמת את המשתמש ומחייבת את ההעברה, אם המשתמש לא יכול להמשיך להשתמש בכתובות ה-URL הישנות.
3. שומרים על עדכניות של האפליקציה הישנה: אם האתר הישן מפנה לאתר החדש, צריך להשתמש במאפיין install_url בבלוק migrate_from כדי לוודא שהדפדפן עדיין יכול למצוא את המניפסט הישן לצורך עדכונים פוטנציאליים.
4. מטמיעים את id בקובץ מניפסט של אפליקציית היעד: ב-Chrome נדרש שבקובץ מניפסט של אפליקציית היעד יהיה שדה id. כך אפשר לוודא שהאפליקציה לא תיתקל בטעות הנפוצה של יצירת אפליקציות מפוצלות על ידי שינוי start_url בלי להגדיר id.

איך מתבצעת לחיצת היד הדו-כיוונית

כדי להבטיח אבטחה ולמנוע השתלטות עוינת, המעבר דורש לחיצת יד מאובטחת בין המקורות הישנים והחדשים. הלחיצת יד הזו מבטיחה ששני האתרים נשלטים על ידי אותה ישות.

שלב 1: האפליקציה החדשה מציינת את האפליקציה הקודמת (חובה)

מוסיפים שדה migrate_from לקובץ מניפסט של אפליקציה של אפליקציית האינטרנט של האפליקציה החדשה.

// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    "https://drive.google.com/"
  ]
}

שלב 2: המקור הישן מאשר את ההעברה (חובה)

כדי למנוע מאתר חדש לחטוף באופן חד-צדדי אפליקציה ישנה, המקור הישן צריך לאשר את ההעברה באופן מפורש. הוא עושה זאת באמצעות .well-knownקובץ הגדרה.

// File at https://drive.google.com/.well-known/web-app-origin-association
{
  "https://fileman.google.com/files/": {
    "allow_migration": true
  }
}

שלב 3: איתות פרואקטיבי (אופציונלי)

כדי להפעיל את העדכון בלי לחכות שהמשתמש יבקר באתר החדש, צריך לעדכן את המניפסט של האפליקציה הישנה כך שיצביע על האפליקציה החדשה.

// Manifest at https://drive.google.com/manifest.json
{
  "name": "Drive",
  "start_url": "/",
  "migrate_to": {
    "id": "https://fileman.google.com/files/",
    "install_url": "https://fileman.google.com/drive/installwebapp?usp=migrate"
  }
}

שלב 4: טיפול בהפניות אוטומטיות (אופציונלי)

במקום להשתמש בשדה migrate_to, אפשר לסמן את המעבר על ידי הפניה אוטומטית של כתובות ה-URL של האפליקציה הישנה לאפליקציה החדשה, ולהסתמך על scope_extensions כדי שבאפליקציה הישנה לא יוצג הבאנר 'מחוץ לתחום'. המשמעות היא שהמניפסט של האפליקציה הישנה לא יוצג אף פעם, ולכן אי אפשר לעדכן אותו. כדי לאפשר לאפליקציה הישנה להמשיך להתעדכן לפני העברת האפליקציה, צריך להגדיר את install_url בתוך migrate_from כדי להודיע לדפדפן על כתובת URL שאפשר לאחזר ממנה את המניפסט הישן שמצורף ללא הפניה אוטומטית.

// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    {
      "id": "https://drive.google.com/",
      "install_url": "https://drive.google.com/drive/installwebapp?usp=migrate"
    }
  ]
}

זהו! חוויית המשתמש דומה לזו שמשמשת לעדכון אפליקציות, שבה המשתמש מקבל הודעה בפינה השמאלית העליונה של חלון האפליקציה:

לחיצה על בדיקת עדכון האפליקציה מציגה את ממשק המשתמש הבא (בהתאם לשינויים במניפסט):

שליטה בחוויית המשתמש

אפשר לבחור את רמת האגרסיביות של ההעברה באמצעות הדגל behavior:

1. הצעה (ברירת מחדל): המשתמש מקבל התראה פסיבית (לדוגמה, בתפריט האפליקציה). הם יכולים לבחור לעדכן או להסיר את האפליקציה, או להתעלם מההעברה על ידי הפעלת תיבת הדו-שיח.
2. כפייה: בהפעלה הבאה של האפליקציה, תוצג למשתמש תיבת דו-שיח חוסמת. הם צריכים לעדכן את האפליקציה למקור החדש או להסיר אותה (ראו צילום מסך בהמשך).

בדוגמה הבאה אפשר לראות איך מגדירים את הבחירה הזו,

"migrate_from": [
  { 
    "id": "https://example.com/social/",
    "behavior": "force" // or suggest
  }
]

סיכום

התכונה 'העברת PWA' מאפשרת למפתחים להמשיך לבנות ארכיטקטורות אינטרנט מודרניות וגמישות בלי להשאיר את המשתמשים מאחור.