כיום, ישנם יותר ויותר אתרים המבוססים על פריימוורקים וספריות של JS כגון React ,Angular node.js וכו׳.
מה יכולה להיות הבעיה עם זה?
בשונה מאתרי HTML שעדיין נחשבים לדומיננטיים ברחבי האינטרנט ונסרקים בתדירות גבוהה, אתרים אשר מבוססים JS דורשים ממנועי החיפוש הרבה יותר מאמץ לסרוק אותם מאשר אתרי HTML רגילים, דבר היכול להוביל לפגיעה בתקציב הזחילה ובנראות עמודי האתר למנועי חיפוש. גוגל בעצמם הודיעו שסריקת עמודים מבוססי JS (בשיטת רינדור צד לקוח) לוקח פי 20 יותר מאמץ מאשר לסרוק עמודים מבוססי HTML ולכן יכול מאוד להיות שהזחלנים שלהם לא יסרקו את כל עמודי האתר או אף יותר גרוע – יבואו לבקר בתדירות נמוכה הרבה יותר!
לכן בראש ובראשונה – כאשר ניגשים לטפל באתר המבוסס JS הדבר החשוב ביותר לבדוק הוא האם קיימות בעיות רינדור או תקציב זחילה.
שימו לב, עצם העובדה שיכולה להיות בעיה אינה אומרת שאתרים מבוססי JS אינם מומלצים ל SEO, זאת ממש לא הכוונה. ישנם לא מעט דרכים לגרום לכך שהזחלנים כן יצליחו לרנדר את עמודי האתר כפי שצריך וגם לבוא לביקור בתדירות גבוהה – ע״י שינוי שיטת הרינדור מצד לקוח אל צד שרת.
מהו רינדור צד שרת? (SSR)
רינדור צד שרת או SSR היא הדרך המסורתית והמקובלת לעיבוד דפי אינטרנט בדפדפנים.
היא פועלת לפי השלבים הבאים:
- המשתמש שולח בקשה לשרת (לרוב באמצעות דפדפן)
- השרת קורא את הנתונים, מכין אותם ומתרגם אותם לשפת HTML בצד-שרת ושולח את הנתונים לדפדפן
- הדפדפן מוריד את הנתונים והופך אותם משורות קוד לתוכן ויזואלי ללקוח הקצה (הגולש).
- הדפדפן למעשה מוריד את ה- Javascript והופך את העמוד לעמוד אינטראקטיבי
"האחריות" של העברת ה-HTML המלא כרוכה בנטל על הזיכרון וכוח העיבוד של הרשת. לפיכך, ניתן להבין שרינדור בצד השרת מגדיל את זמן טעינת העמוד בהשוואה לזמן טעינת העמוד עבור אתר סטטי בו אין תוכן דינמי להצגה.
מהו רינדור בצד הלקוח (CSR)?
רינדור צד לקוח או CSR זו גישה שונה לאופן עיבוד דף האינטרנט. ב- CSR הנטל של קומפילציה ויצירת HTML עבורם – מועבר ישירות לדפדפן הלקוח במקום לשרת.
גישה זו מתאפשרת בזכות JavaScript וספריות כמו VueJS, ReactJS ו Angular. הדרך של רינדור דפי אינטרנט בצד הלקוח עובדת בדרך הבאה:
- המשתמש שולח בקשה לשרת (לרוב באמצעות דפדפן).
- הדפדפן מתחיל להוריד את ה- HTML ואז את ה- JS, בזמן הזה המשתמש רואה סמל טעינה.
- לאחר שהדפדפן מצליח לעלות את ה-JS, הוא מגיש בקשת API באמצעות AJAX כדי להביא את התוכן הדינמי ועובר עיבוד סופי.
- לאחר שהשרת מגיב – התוכן הסופי מועבר באמצעות עיבוד DOM בדפדפן הלקוח.
איך זה משפיע על קידום האתר?
כפי שאתם בטח יודעים – אתם או מקדם אתרים חייבים לבצע אופטימיזציה לאתר שלכם כדי לקבל דירוג גבוה. אך לפני שזה יוכל לעבוד, אתר האינטרנט שלכם אמור לשקף את המטא דאטה הנכונים עבור מנועי החיפוש. אחרי הכול, מנועי חיפוש כמו גוגל משתמשים בבוטים אוטומטיים שבין היתר סורקים גם את המטא דאטה של האתר שלכם.
כשמשתמשים ב-CSR התוכן באתר שלכם נוצר באופן אוטומטי באמצעות JS. המשמעות היא ששינוי המטא דאטה מדף אחד לעמוד אחר מסתמך על הביצועים של JS. זה דורש שימוש בתוספים כדי להגדיר את המטא דאטה עבור כל עמוד כך שהם יוצגו בצד של הלקוח.
ב-SSR העמודים מורכבים במלואם עם המטא דאטה הנכונים. לאחר קבלת הסקריפטים של הHTML הם נשלחים לממשק הקמה. שיטה זו מבטיחה שהמטא דאטה של הדף יישארו מדויקים בין אם סורקי מנועי החיפושים מאפשרים להשתמש בJS ובין אם לא.
בדרך כלל אתרי SSR הם יותר "גוגל פרנדלי" לעומת אתרי CSR
איזה הבדלים נוספים יש בניהם?
-
השפעה על המטמון
– מטמון זהו שמירת גרסה של עמוד אינטרנט כך שניתן יהיה לגשת אליהם מהר יותר החל מהביקור בשני והלאה. אתרי אינטרנט מיישמים את אסטרטגיית המטמון עבור סקריפטים לשימוש חוזר במחשב של המשתמש, כתוצאה מכך – תוכלו לראות שיפור בזמני הטעינה גם עבור הSSR ו-CSR. אך עדיין יש הבדל עיקרי אחד, אתרים מבוססי CSR יכולים לפעול גם ללא אינטרנט ולמעשה לאחר שהעמוד נטען – כבר אין צורך לשלוח בקשות לשרת. לעומת זאת, בSSR בקשות לשרת תמיד יישלחו, מה שיוצר מצב של זמני טעינה גבוהים יותר.
-
זמן טעינה ראשוני
– זמן טעינה ראשוני הוא הזמן הממוצע שלוקח למשתמש לטעון את האתר שלכם בפעם הראשונה. בזמן שימוש ב-CSR, הדפדפן טוען HTML, CSS ואת כל הסקריפטים הנדרשים. כתוצאה מכך, אתם יכולים לצפות שSSR יעלה את הדף מהר יותר.
-
זמן טעינה עוקב
– זמן הטעינה עוקב מתאר את הזמן שלוקח לנווט מעמוד אחד למשנהו. במצב זה, כל הסקריפטים התומכים נטענו מראש עבור CSR, מה שמתורגם לזמני טעינת עמודים קצרים יותר. מצד שני, SSR עוקב אחר אותו מחזור בקשה למשך זמן טעינה של העמוד הראשון. לכן אם נסתכל על שניהם, ה CSR מגיב מהר יותר לדפדוף וטעינת העמודים באתר שלכם.
