Incremental Static Regeneration: עדכניות של דף דינמי במחיר של דף סטטי

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

Incremental Static Regeneration, Next.js, Stale-While-Revalidate, On-Demand Revalidation, הבדל מ-SSR ו-Static Generation, והשפעה על עומס שרת.

דף מוצר בחנות עם עשרות אלפי פריטים לא יכול להיבנות מחדש כ-Static Site בכל פעם שהמחיר משתנה — build מלא לוקח דקות עד שעות, וזה לא ריאלי לעדכן מחיר בזמן אמת דרך תהליך כזה. אבל רינדור מלא בצד השרת בכל בקשה (SSR) מייצר עומס שרת ואיטיות שלא נחוצה כשהתוכן משתנה רק פעם בכמה דקות. Incremental Static Regeneration פותרת בדיוק את הפער הזה: היא מגישה דף סטטי מוכן מראש כמו CDN רגיל, אבל מרעננת אותו ברקע לפי טווח זמן שמוגדר, בלי לחסום את המשתמש שמבקש אותו.

איך זה עובד בפועל

בבקשה הראשונה לדף, ה-framework (בדרך כלל Next.js) מגיש עותק סטטי שכבר נבנה ונשמר בקאש. כל עוד לא עבר ה-revalidate interval שהוגדר לדף — למשל 60 שניות — כל בקשה נוספת מקבלת בדיוק אותו עותק סטטי, מהיר כמו קובץ HTML רגיל. ברגע שעובר הזמן שהוגדר, הבקשה הבאה עדיין מקבלת את הגרסה הישנה (stale-while-revalidate), אבל ברקע מופעל תהליך שבונה גרסה חדשה ומחליף אותה בקאש עבור כל הבקשות הבאות.

ISR מול Static Generation טהור

ב-Static Generation קלאסי, כל שינוי בתוכן מחייב build מחדש ופריסה מחדש של כל האתר — תהליך שיכול לקחת דקות במקרה הטוב ושעות באתר גדול עם אלפי דפים. ISR מוציאה את דף בודד מהתהליך הזה: אפשר לעדכן רק את הדפים שבאמת השתנו, בלי לגעת בשאר האתר, ובלי להריץ build כולל בכל פעם שעורך תוכן משנה כותרת במערכת ה-CMS.

On-Demand Revalidation

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

מתי לבחור ISR על פני SSR מלא

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

השפעה על עומס שרת וביצועים

מכיוון שרוב הבקשות נענות ישירות מהקאש בלי להפעיל שום קוד שרת, ISR מורידה דרמטית את מספר ה-Function Invocations בסביבות serverless כמו Vercel, וכתוצאה מכך גם את העלות התפעולית. מבחינת המשתמש הקצה, זמן התגובה זהה לדף סטטי טהור — ללא תלות בזמינות מסד הנתונים או API חיצוני, כי כל בקשה רגילה מקבלת עותק שכבר מוכן, ורק תהליך הרענון ברקע נוגע במקורות הנתונים המקוריים.

מלכודות נפוצות

הטעות הנפוצה ביותר היא להגדיר revalidate ארוך מדי לתוכן שמשתנה הרבה, מה שגורם למשתמשים לראות נתונים לא עדכניים לזמן ארוך; והטעות ההפוכה — revalidate קצר מדי לדף שכמעט לא משתנה, שמייצר build מיותרים ללא תועלת. חשוב גם לזכור שהגרסה הראשונה שמוצגת אחרי תפוגת התוקף היא עדיין הישנה (stale), ורק הבקשה שאחריה רואה את הגרסה המעודכנת — לכן ISR לא מתאימה לתוכן שדורש עדכניות מוחלטת ומיידית לכל משתמש בו-זמנית.

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

תגיות: ISR · Incremental Static Regeneration · Next.js · Stale While Revalidate · On-Demand Revalidation · Static Generation

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