סנכרון כרטיסיות בדפדפן: איך להריץ משימות AI בלי להקריס ללקוח את המחשב

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

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

הסיבה פשוטה: האתר הריץ מודל AI קל ישירות בדפדפן באמצעות WebGPU, לצד פולינג תדיר מול שרתי LLM. כל כרטיסייה ביצעה את אותה עבודה בדיוק, במקביל.

ב-2026, כשאנחנו מעמיסים עוד ועוד יכולות AI על הצד של הלקוח, זו בעיה נפוצה.

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

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

• כפילות זיכרון: מודל ה-AI או המשקולות (Weights) נטענים לזיכרון ה-RAM בנפרד עבור כל לשונית.
• קריאות כפולות ל-API: שאילתות מול Claude או ChatGPT נשלחות מספר פעמים במקביל עבור אותו מידע.
• חניקת GPU: הרצת חישובי טנסורים ב-WebGPU בכמה לשוניות משתקת את המעבד הגרפי.

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

אחרי: ארכיטקטורת Leader-Worker מתקדמת

כך נראה האתר כשהוא מנהל את הממשק בצורה חכמה:

המשתמש פותח 10 כרטיסיות. הכרטיסייה הראשונה תופסת בעלות ומסומנת כ-Leader. היא הופכת לתחנת הכוח הבלעדית. כל יתר 9 הכרטיסיות מזהות שיש מנהל בשטח, הופכות ל-Workers, ומשתתקות.

כשאחד מהכרטיסיות המשניות צריכה עיבוד AI, היא שולחת בקשה ל-Leader. ה-Leader מריץ את החישוב, ומחזיר את התוצאה לכולן במקביל.

💡

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

איך לבצע את המעבר: 3 צעדים בקוד

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

הגדרה · Web Locks API

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

צעד 1: בחירת ה-Leader באמצעות Web Locks API

אנחנו משתמשים ב-navigator.locks.request כדי לנסות לקבל את המנעול.

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

navigator.locks.request('ai_processing_leader', async (lock) => {
  // כרטיסייה זו היא ה-Leader!
  setIsLeader(true);
  initializeAIModel();
  
  // מחזיקים את המנעול פתוח כל עוד הכרטיסייה פעילה
  await new Promise(() => {}); 
});

צעד 2: הקמת ערוץ תקשורת עם BroadcastChannel

כעת כשיש לנו Leader, ה-Workers צריכים לדבר איתו.

הגדרה · BroadcastChannel

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

const aiChannel = new BroadcastChannel('ai_sync_channel');

// כרטיסיה משנית שולחת בקשת AI
function requestAITask(payload) {
  aiChannel.postMessage({ type: 'EXECUTE_AI', payload, id: crypto.randomUUID() });
}

// ה-Leader מקשיב לבקשות ומחזיר תשובות
aiChannel.onmessage = async (event) => {
  if (isLeader && event.data.type === 'EXECUTE_AI') {
    const result = await processAI(event.data.payload);
    aiChannel.postMessage({ type: 'AI_RESULT', id: event.data.id, result });
  }
};

צעד 3: ניהול נפילה (Failover) בלייב

מה קורה אם עמרי סוגר את הכרטיסייה שהיתה ה-Leader?

היופי ב-Web Locks API הוא שהשחרור מבוצע אוטומטית. ברגע שהכרטיסייה נסגרת, המנעול משתחרר. הכרטיסייה הבאה בתור מקבלת את ההתראה, הופכת ל-Leader החדש, ומאתחלת את מודל ה-AI שפותח.

זה עובד מדהים.

סיכום: הסטנדרט החדש של אתרי AI ב-2026

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

כשאנחנו בונים אתרים חכמים ב-JustBetter, סנכרון המצב בין הכרטיסיות הוא תנאי סף לקוד ייצור. ניצול נכון של Web Locks API ו-BroadcastChannel חוסך משאבי שרת, מונע קריסות ומבטיח שהאתר יישאר מהיר בכל מצב.

💡

בניה נכונה ב-2026 היא לא רק לדעת להריץ AI, אלא לדעת איפה ומתי להפסיק להריץ אותו.