פיתוח פרונטאנד ב-Next.js: SSR, SSG, ISR ו-App Router

פיתוח Next.js: היכן צוואר הבקבוק ומה נשבר

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

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

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

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

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

מהירות הציור הראשון

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

אינדוקס עמודים

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

עומס על מכשיר הלקוח

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

עמידות בתעבורת שיא

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

פיתוח Next.js: SSR, SSG, ISR ורינדור בצד הלקוח

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

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

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

סיכום לפי מצבים

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

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

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

1. אודיט צד הלקוח. מפרקים את מבנה העמודים והנתיבים, מקורות הנתונים ונפח הקוד שעובר לדפדפן. בפלט — מפת צווארי בקבוק עם הערכת ההשפעה על מהירות ההחזרה.
2. סכמת נתיבים ונתונים. ממיינים את העמודים לפי מצבים: סטטיקה, בנייה בשרת לפי בקשה, עדכון לפי לוח זמנים או אירוע. לכל נתיב — מקור הנתונים וההתנהגות כאשר הוא אינו זמין.
3. הגדרת הרינדור. מעבירים את הסכמה ל-App Router, מסמנים קומפוננטות שרת וקומפוננטות לקוח, קובעים כללי עדכון ואינבלידציה ממוקדת לפי תגים, כדי שעריכה של ישות אחת לא תאפס את כל המטמון.
4. הגירה ללא השבתה. נתיבים חדשים פועלים במקביל לישנים, השוואת המענים מתבצעת על תעבורה חיה, והמעבר — ככל שהם מתלכדים.
5. בדיקה תחת עומס. מודדים את הזמן עד לבייט הראשון, את שיעור השגיאות, את ההתנעה הקרה ואת ההתנהגות בעת כשל של שירותים חיצוניים.
6. קבלת העבודה. משווים מדדים לפני ואחרי, מתעדים רשימת בדיקה של נתיבים, תרחיש חזרה לגרסה הקודמת ותקנון עדכון התוכן.
7. העברה למהנדסים. תיעוד ארכיטקטוני, סכמת נתיבים, הרשאות ותקנונים — הצוות ממשיך להוביל את הפרויקט בעצמו.

תוצרי הפרויקט: מאגר קוד, סכמות, תקנונים

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

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

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

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

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

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

מה השתנה במדדים: זמן התגובה של השרת באחוזון ה-95 — מ-1.9 ל-0.3 שניות, שיעור העמודים באינדקס החיפוש — מ-43% ל-91%, התעבורה האורגנית גדלה בכפי 2.3 בערך ברבעון.

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

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

במה נבדל רינדור בצד השרת מיצירה סטטית?

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

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

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

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

התלבטויות לגבי App Router, מטמון וניתוב

ההתלבטויות לפני ההתחלה הן בדרך כלל טכניות, ונפתרות בשלב התכנון, ולא בשטח. להלן השאלות הנפוצות ביותר כאשר הצוות כבר בחר Next.js ודן במעבר ל-App Router.

האם המטמון לא יתחיל להחזיר מחירים ומלאי ישנים?

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

יש לנו שרת משלנו ופריסה משלנו — נצטרך לבנות הכול מחדש?

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

שירותים חיצוניים מגיבים לאט — האתר יחכה?

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

נדון במשימה: נחזור עם תוכנית והערכת עבודה

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

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

בפלט אתם מקבלים:

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

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