פיתוח אפליקציית PWA ב-1C-Bitrix: מטמון, פוש, אופליין

מדוע PWA על Битрикс נשבר בערוץ חלש

PWA על Битрикс נופל לרוב לא בגלל "אינטרנט חלש" כשלעצמו, אלא במפגש של שלושה דברים: service worker מחזיר מטמון מיושן של האפליקציה, הבקשה לשרת נקטעת באמצע, וטופס ההזמנה נשלח שוב.

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

התקלה הראשונה — אסטרטגיית המטמון. אם סטטיקה ו-HTML נשמרים במטמון "לנצח", לאחר שחרור גרסה המשתמש רואה במשך שבועות גרסה ישנה של העמוד, בעוד שהבנייה החדשה נמצאת על השרת ואיש אינו מבקש אותה.

זה לא מתוקן על ידי כיבוי המטמון, אלא על ידי הפרדה: מעטפת האפליקציה מתעדכנת לפי גרסת הבנייה, הנתונים — דרך הרשת עם עדכון ברקע, ותשובות API כבדות אינן נשמרות במטמון כלל.

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

לכן פעולות קריטיות (ביצוע הזמנה, בקשה, תשלום) מוכנסות לתור עם מזהה פעולה: השרת לפי זה מבין שזו אותה בקשה, ואינו יוצר ישות שנייה.

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

מפרקים כיצד זה נסגר בצד Битрикс: גרסאות מטמון, שליחת טפסים אידמפוטנטית והתנהגות צפויה בעת ניתוק החיבור.

מה משתנה לאחר הטמעת PWA

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

עמידות בפני ניתוקי תקשורת היא התוצאה המדידה השנייה. Service worker מיירט בקשות רשת ומחזיר תגובות שנשמרו מראש במטמון, ולכן באינטרנט סלולרי חלש או במעבר בין רשתות הדף לא "קורס" עם שגיאה. המשתמש ממשיך לעבוד עם הממשק, והטפסים שנשלחו מוכנסים לתור ויוצאים לשרת ברגע שהחיבור מתחדש.

מכניקה זו בדיוק פוגעת ישירות בפניות שאבדו. קודם לכן ניתוק תקשורת ברגע שליחת הטופס означал שהנתונים לא הגיעו והלקוח עזב. כעת הפנייה נשמרת מקומית ונשלחת שוב באופן אוטומטי — שיעור הפניות שאבדו יורד, ובעקבותיו יורד גם העומס על המנהלים, שאינם צריכים להתקשר שוב כדי לברר.

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

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

דרכים למימוש PWA: השוואת גישות

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

מה קובע את הבחירה

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

היכן מתחילות המגבלות

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

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

אנחנו מנתחים את המשימה שלכם ומתאימים אפשרות לתרחיש השימוש, ולא להפך.

שלבי הטמעת PWA ב-Bitrix

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

כיצד בנוי התהליך

1. ביקורת. ממפים את העמודים והבקשות, בוחנים אילו נתונים מחזיר השרת ומה ניתן להחזיר מהמטמון. בנפרד מנתחים את האימות, סל הקניות והטפסים — אותם אין לשמור במטמון כסטטי, אחרת המשתמש יראה נתונים של אחרים. בתום השלב — רשימת מסלולים עם סימון "נשמר במטמון / רשת בלבד / היברידי".

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

3. הגדרה. רושמים service worker, מניפסט, אייקונים ומסכי פתיחה, ומחברים התראות push דרך צד השרת. מגדירים את ההתנהגות בעת ניתוק החיבור: מה מציגים מהמטמון ומה מכניסים לתור לשליחה.

4. בדיקה בערוץ חלש. בודקים לא במשרד עם אינטרנט מהיר, אלא בתנאי חיבור איטי ובמצב לא־מקוון מלא: פתיחה, ניווט, כניסה חוזרת, שליחת טופס לאחר חידוש החיבור. בוחנים כיצד המטמון מתנהג בעת עדכון גרסה.

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

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

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

תארו את הפרויקט שלכם — נחזור עם הערכה ותוכנית עבודה לפי שלבים אלה.

מטמון וסנכרון נתונים

מטמון ב-PWA על 1С-Битрикс אינו "שמירת העמוד בשלמותו", אלא מערכת אסטרטגיות לכל סוג נתונים. קטלוג ומשאבים סטטיים מוגשים לפי עיקרון "תחילה מטמון, רענון ברקע": הממשק נפתח באופן מיידי גם ברשת חלשה, והגרסה המעודכנת נטענת לאחר מכן.

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

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

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

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

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

מה הלקוח מקבל לידיו

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

• תצורות מטמון — אסטרטגיות לסטטיקה, לתגובות API ולכרטיסי מוצר: מה מכניסים ל-precache בעת ההתקנה, מה מעדכנים ברקע, ומה מגישים מהרשת עם נסיגה לעותק. עם ציון זמן החיים של הרשומות וכללי invalidatsיה בעת שינוי תוכן.
• סכמות סנכרון — דיאגרמות של זרימות נתונים: אילו ישויות נכנסות לתור הרקע בהיעדר קישוריות, באיזה סדר נשלחות בעת השחזור, וכיצד נפתרים קונפליקטים של גרסאות בין המכשיר לשרת.
• מדיניות גישה — מטריצת תפקידים והרשאות ברמת ה-PWA: אילו מדורים ונתונים זמינים לאורח, למשתמש מאומת ולעובד; כיצד מתחדשים הטוקנים ומה קורה עם פקיעת הסשן.
• תרחישי Push — רשימת טריגרים (סטטוס הזמנה, הודעה חדשה, מבצע), תבניות התראות וכללי סגמנטציה של נמענים, כדי שהתפוצה לא תהפוך לספאם.
• תיעוד — תיאור הארכיטקטורה, נקודות האינטגרציה עם 1С ו-Битрикс, והוראות להרצה מקומית ולבנייה עבור מפתחים.
• נהלי עדכון — סדר הוצאת גרסה חדשה: כיצד מודיעים ללקוחות על החלפת המטמון, כיצד חוזרים לגרסה קודמת, ומי ומתי בודק תאימות לליבה הנוכחית.
• צ'ק-ליסט קבלה — תרחישים שלפיהם בודקים מצב אופליין, התקנה על מסך הבית, פעולת ההתראות ונכונות הנתונים לאחר דה-סינכרון.

כל זה מועבר במאגר שלכם עם גישה לצוות. תארו את המשימה — נחזור עם הערכה ותוכנית לפי קווי המתאר שלכם.

במה שונה PWA מאפליקציה נייטיבית?

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

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

עלות הבעלות שונה באופן עקרוני. אפליקציה נייטיבית היא שניים-שלושה פרויקטים מקבילים לפלטפורמות שונות, שלכל אחד מהם מחזור שחרור משלו, בדיקות משלו בחנויות ודרישות עדכון משלו. PWA נבנית על קוד אחיד מעל האתר על Битрикс: הלוגיקה, העיצוב והאינטגרציות נעשים בהם שימוש חוזר ולא משוכפלים. הוצאות התחזוקה מפסיקות להיות מוכפלות במספר הפלטפורמות — הצוות מתחזק מוצר אחד במקום כמה.

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

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

ישנם גם גבולות. תוכנית נייטיבית עובדת לעומק עם החומרה: מצלמה, Bluetooth, מיקום גיאוגרפי ברקע, התראות מערכת זמינים ללא הגבלות. PWA מכסה את רוב התרחישים — push, מצב לא מקוון, עבודה עם מצלמה — אך במקום שנדרש גישה קבועה לחיישנים ברקע, בנייה נייטיבית נשארת מדויקת יותר. לכן הבחירה אינה "או-או", אלא שאלה של אילו פונקציות קריטיות לתרחיש שלכם.

מקרה בוחן: כיצד PWA צמצם אובדן פניות

הלקוח — חברת שירות עם צוותים ניידים — קיבל פניות דרך טופס אינטרנט באתר המנוהל על ידי 1С-Битрикс. ראשי הצוותים עבדו עם מחשבי לוח במרתפים ובאתרים ללא קישוריות יציבה: הטופס נשלח, אך בעת ניתוק הרשת הבקשה אבדה, והלקוח ראה "שגיאת שליחה". האובדן הגיע עד לרבע מהפניות בשעות שיא, והמוקדנית נודעה על ההיעלמות רק משיחת טלפון של לקוח ממורמר.

מה שינו

הרכבנו מעטפת PWA מעל הפרונטאנד הקיים: service worker מיירט את שליחת הטופס, מכניס את הפנייה לאחסון המקומי של המכשיר וחוזר על הבקשה ברגע שהרשת חוזרת. קונפליקטים נפתרים לפי מזהה הפנייה בצד הלקוח — כפילויות בשליחה חוזרת אינן נוצרות.

התראות Push דרך ה-service worker מודיעות למוקדנית על פניות חדשות, ולראש הצוות — על שינוי סטטוס, גם כשהלשונית סגורה.

מדדים לפני ואחרי

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

ספקות טכניים נפוצים

שכבת ה-PWA מונחת מעל הליבה הקיימת של 1С-Битрикс, ולא מחליפה אותה: ה-service worker מיירט בקשות ומחזיר תשובות מהמטמון, בעוד הליבה והמודולים ממשיכים לפעול כרגיל.

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

מודולים סטנדרטיים («חנות אינטרנט», «בלוקי מידע», «רשימות אוניברסליות») אינם דורשים כתיבה מחדש: עבורם מוגדרות אסטרטגיות נפרדות — תוכן סטטי וקטלוג נשמרים במטמון, ותשובות מותאמות אישית עוברות רק דרך הרשת.

אבטחת נתונים: מה נכנס למטמון במכשיר?

רק משאבים ציבוריים נכנסים למטמון — קוד התצוגה, סקריפטים, תמונות, קטלוג. אסימוני אימות, תוכן האזור האישי ונתוני תשלום אינם נשמרים במטמון: עבורם מוגדר במפורש מצב «רשת בלבד». מינווי Push נשמרים בנפרד מנתוני המשתמש ומקושרים לסשן, וביציאה מהחשבון המינוי מבוטל.

כיצד PWA משפיע על SEO ואינדוקס?

רובוטים של מנועי החיפוש מקבלים את אותו HTML מהשרת כמו קודם — ה-service worker אינו מופעל עבורם. כתובות העמודים אינן משתנות, ולכן המיקומים שנצברו ומסת הקישורים נשמרים. התקנת האפליקציה על המכשיר מוסיפה ערוץ נוסף להחזרת משתמשים, מבלי להתחרות בתעבורת החיפוש.

מה עם מצב לא מקוון ועדכון תוכן?

במצב לא מקוון מוחזר סט שנבחר מראש: עמוד הבית, הקטלוג, עמודים שנפתחו קודם לכן. כאשר החיבור חוזר, ה-service worker מסנכרן שינויים ברקע, וגרסת המטמון מתעדכנת אוטומטית — המשתמש אינו צריך להתקין מחדש את האפליקציה כדי לראות נתונים עדכניים.

בואו נדון במשימה שלכם

כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים הקשר לגבי המשימה שלכם. תארו מה כבר עובד ומה כואב: איזה מדור בקטלוג או אזור אישי צריך לעבור לאופליין, אילו פעולות הן קריטיות ללא רשת, האם קיימת אימות פעיל וכיצד בנוי החילוף עם 1С. זה מספיק כדי להבין את ההיקף ולהציע תוכנית מציאותית.

מה כדאי לצרף לתיאור:

• כתובת האתר או האב-טיפוס הנוכחית ותיאור קצר של המוצר;
• אילו תרחישים צריכים לעבוד באופליין ואילו נתונים נדרשים עבורם;
• כיצד בנויים כיום כניסת המשתמש, הסל וביצוע ההזמנה;
• מאיפה מגיעות ההתראות ומה צריך להיכנס ל-push;
• אילו אינטגרציות עם 1С ושירותים חיצוניים כבר קיימות;
• האם יש מגבלות בלוחות זמנים, הרשאות וסביבה;
• מי מצד הלקוח מקבל החלטות לגבי המוצר.

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

תארו את המשימה בצורה נוחה — נחזור עם הערכה, תוכנית וצעדים הבאים.