Islands Architecture: למה לא כל הדף צריך להיות אפליקציית JavaScript

מאת צוות מדיה דיל · 06.07.2026 · פיתוח אתרים · 4 דק׳

Islands Architecture, Partial Hydration, Astro ו-client:visible, הבדל מ-SPA מלא, השפעה על INP, ורינדור סטטי ל-SEO.

אתר תדמית עם עשרה עמודים, שרובם טקסט וסטטי לחלוטין, נבנה כ-Single Page Application ששולח למשתמש כמעט מגה-בייט של JavaScript לפני שהוא יכול לראות אפילו כותרת. הדפדפן מוריד את כל ה-bundle, מפרסר אותו, מריץ אותו, ובונה מחדש DOM שכבר יכול היה פשוט להגיע כ-HTML מוכן. Islands Architecture נולדה מהתובנה הפשוטה הזו: רוב עמוד אינטרנט הוא תוכן סטטי, ורק חלקים קטנים ממנו — טופס, קרוסלה, כפתור "הוסף לעגלה" — באמת זקוקים לאינטראקטיביות בצד הלקוח.

המודל: HTML סטטי עם "איים" של אינטראקטיביות

בגישת Islands, השרת (או תהליך ה-build) מפיק HTML סטטי מלא לכל הדף, ורק רכיבים ספציפיים שמסומנים במפורש כאינטראקטיביים מקבלים JavaScript משלהם שנטען ומופעל בנפרד. שאר הדף — כותרות, פסקאות, תמונות, ניווט סטטי — נשאר HTML טהור בלי שום runtime שמריץ אותו. כל "אי" הוא יחידה עצמאית עם ה-bundle הקטן שלו, במקום שהדף כולו יהיה תלוי בעץ רכיבים אחד גדול שצריך להיטען ולהתאתחל כמכלול.

Partial Hydration לעומת Full Hydration

במודל ה-SPA המסורתי, גם אם רק כפתור אחד בעמוד אינטראקטיבי, כל עץ ה-React (או Vue) עובר Hydration — הדפדפן בונה מחדש את כל ה-Virtual DOM ומצרף event listeners לכל רכיב, כולל אלה שלעולם לא ישתנו. Islands Architecture עושה Partial Hydration: רק ה"אי" המסומן מקבל hydration, ולרוב רק כשהוא נכנס ל-viewport או כשהמשתמש מתקרב אליו באינטראקציה, כמו scroll או hover. זה מוריד דרמטית את כמות ה-JavaScript שרץ ב-Main Thread בטעינה הראשונית ומשפר ישירות את מדד INP מתוך Core Web Vitals.

Astro כדוגמה מובילה

Astro הפך לשם הנרדף לגישה הזו כי הוא בנוי סביב עקרון client:* directives — כל רכיב React, Vue או Svelte שמוטבע בעמוד Astro נשאר HTML סטטי כברירת מחדל, ורק תוספת מפורשת כמו client:visible או client:idle הופכת אותו לאי אינטראקטיבי עם hydration מבוקר. זה מאפשר לערבב פריימוורקים שונים באותו עמוד בלי לגרור את כל ה-runtime שלהם, וזה שונה מהותית מגישת Next.js המסורתית שבה כל הדף הוא בדרך כלל אפליקציית React אחת מקצה לקצה.

מתי זה לא מתאים

Islands Architecture מתאימה פחות לאפליקציות שבהן רוב המסך אינטראקטיבי ומחובר סטייט משותף — לוח בקרה עם גרפים שמתעדכנים בזמן אמת, עורך מסמכים, או כלי SaaS מורכב. שם דווקא מודל SPA עם ניהול state מרכזי ו-React Server Components לחלוקה חכמה בין שרת ולקוח נותן ערך רב יותר, כי רוב הדף ממילא דינמי ואין הרבה "ים סטטי" סביב ה"איים". הבחירה הנכונה תלויה ביחס בין תוכן סטטי לאינטראקטיבי בפועל, לא באידאולוגיה.

השפעה על ביצועים בפועל

בפועל, אתר תדמית או בלוג שעובר מ-SPA מלא ל-Islands Architecture רואה בדרך כלל ירידה של 70-90% בכמות ה-JavaScript שנשלח בטעינה הראשונית, כי רוב העמוד פשוט לא צריך שום bundle. זה מתורגם ישירות לשיפור ב-Time to Interactive ובצריכת סוללה וזיכרון במכשירים חלשים, בלי לוותר על יכולת להטמיע ווידג'טים אינטראקטיביים מורכבים היכן שבאמת נדרש.

שילוב עם SEO ורינדור בצד השרת

מכיוון שה-HTML כבר מוכן ומלא בזמן שהדף מגיע לדפדפן, Islands Architecture פותרת אגב גם בעיה נפרדת: זחלנים שלא מריצים JavaScript טוב רואים תוכן מלא מהרגע הראשון, בלי תלות ביכולת הרינדור של הבוט. זה הופך את הגישה לאטרקטיבית במיוחד לאתרים שתלויים ב-SEO אורגני, בדיוק כמו שדפי SSR פותרים את אותה בעיה עבור אפליקציות React מלאות.

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

תגיות: Islands Architecture · Astro · Partial Hydration · client:visible · SPA · Static HTML

← חזרה לבלוג · צור קשר