רינדור בצד שרת מול צד לקוח - מוסבר בפשטות

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

מה זה בעצם "רינדור" במקרה הזה

רינדור, בהקשר הזה, זה התהליך שבו מידע (רכיבי ריאקט, נתונים) הופך ל-HTML שהדפדפן יכול להציג למשתמש. השאלה המרכזית היא - איפה זה קורה? בשרת, לפני ששולחים משהו למשתמש? או בדפדפן של המשתמש עצמו, אחרי שהוא כבר קיבל את הדף?

CSR - רינדור בצד לקוח

זו הגישה ה"קלאסית" של אפליקציית ריאקט רגילה, בלי Next.js. כשמשתמש נכנס לאתר, השרת שולח לו HTML כמעט ריק, בערך ככה:

<div id="root"></div>
<script src="bundle.js"></script>

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

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

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

SSR - רינדור בצד שרת

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

<div id="root">
  <h1>כותרת שכבר שם</h1>
  <p>תוכן שכבר שם</p>
</div>
<script src="bundle.js"></script>

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

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

החיסרון - זה דורש שרת שמריץ ג'אווהסקריפט בכל בקשה (או לפחות בחלקן), מה שמוסיף עומס ומורכבות תשתיתית בהשוואה לאתר CSR שאפשר לארח כקבצים סטטיים בלבד.

אז איך בוחרים בפועל

זה תלוי לגמרי בסוג האפליקציה שאתם בונים:

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

למה זה לא באמת "או-או" יותר

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

למה כדאי להבין את זה, לא רק להשתמש בו

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

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

לסיכום

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

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

הצטרפו לקהילה בדיסקורד