במדריך זה אצלול לפרטים ואסביר מה זה רינדור צד שרת / Server Side Rendering, מי צריך את זה, למה זה משהו שכל כך קריטי להכיר בתחום ה-SEO, הסכנות מבחינת SEO והפתרונות האפשריים.
אם תקראו את המדריך עד הסוף, תהיה לכם הבנה מספיק טובה כדי לדעת לזהות אם יש בעיה, למנוע החלטות הרסניות, להעביר הנחיות לצוות הפיתוח ולבסוף תדעו איך לבדוק שהכל תקין ועובד.
קצת על JS Frameworks ואתרים מבוססים JavaScript
מבלי להיכנס לפרטים טכניים מדי, JS Frameworks הן אוסף ספריות JS מוכנות מראש שמאפשר לבנות אפליקציות / אתרים / Single Page Applications. הפריימוורקים המוכרים יותר, אנגולר (Angular) וריאקט (React), מתוחזקים על ידי גוגל ופייסבוק בהתאמה, לאחר שפותחו או נרכשו לצרכים פנימיים של התאגידים. בין האתרים הרבים שבנויים על אחד מהפריימוורקים הללו תמצאו גם ענקיות כמו פייסבוק, טוויטר, אינסטגרם ונטפליקס שכולן בנויות על React. כלומר, לא מדובר איזו תופעה זניחה שאפשר להתעלם ממנה.
למה יותר ויותר אתרים נבנים על תשתית JS?
קל. הסיבות למעבר לבניית אתרים עם JS frameworks ברורות – זמני הפיתוח מתקצרים, חווית המשתמש משתפרת, זמני הטעינה משתפרים (תלוי בכשירות המפתח/ת) וזה סקלבילי. בתכלס? אלו אתרים שמספקים חוויות משתמש חלקה יותר, נקודה.
אנחנו רואים את זה יותר כשמדובר באתרים גדולים מאוד, בעיקר במקרים בהם משדרגים אתר קיים, חלקים ממנו או אפילו משיקים פרויקטים נקודתיים/הרחבות. למה בעיקר אתרים גדולים מאוד? כי מדובר באתרים שקיימים מאז קום מדינת האינטרנט ובד"כ בנויים עם קוד מיושן מאוד, סוג של פלסטר על פלסטר, ושחצי ממנו לא מובן לאלו שעדיין עובדים בחברה.
עם הזמן, האתרים מתרחבים, או שצריך להוסיף פונקציונאליות מסוימת. מה יבחר לעשות כל CTO שפוי? להמשיך להשתמש בקוד מיושן שהוא שונא או להשיק סאבדומיין חדש עם קוד מודרני שחוסך לו המון כאב ראש? זה למה JS frameworks.
סביר להניח שעם הזמן תתקלו ביותר אתרים שבנויים על פריימוורק ג'אווה סקריפט כזה או אחר. אני ממליץ להכיר את היסודות כבר עכשיו ולשמור את המאמר הזה ליום הבלתי נמנע בו תצטרכו לקדם אתר כזה.
שמרתם? יופי, בואו נמשיך.
ההבדל העיקרי: רנדור בצד שרת לעומת רנדור בצד לקוח
ההבדל המהותי ביותר בין אתרים שלא מבוססים על JS לעומת אתרים שכן הוא שאתרים שלא מבוססים על JS מגישים לדפדפן את ה-HTML הסופי (רנדור בצד שרת = Server Side Rendering). לעומתם, אתרים שבנויים על JS מעבירים את עבודת בניית ה-HTML לדפדפן של המשתמש (רנדור בצד לקוח = Client Side Rendering). ברנדור צד לקוח, הדפדפן צריך להוריד, לפרסר ולהריץ את ה-JS על מנת לקבל DOM סופי ואת כל התוכן כפי שמי שייצר את האתר התכוון.
דמיינו שהזמנתם אורחים לארוחת ערב אצלכם. כשהאורחים מגיעים, אתם מציעים להם מקום להתיישב כמו מארחים סבירים. כשהאורחים שלכם באים להתיישב, הם רואים ערימת חלקים של כסאות ולידם חוברת הוראות הרכבה לכסאות. יש לאורחים שלכם את כל מה שנדרש על מנת לשבת, אבל הם צריכים להרכיב את הכסא לפני שיוכלו להתיישב עליו. זה רנדור צד לקוח - מעייף, לוקח יותר מדי זמן ומעיק.
במילים אחרות - כשאנחנו סומכים על הדפדפן של היוזר להריץ JS כדי לבנות את ה-HTML (רנדור צד לקוח), אנחנו בעצם דורשים מהדפדפן לקחת את חלק הארי של העבודה על עצמו ולהשתמש במשמעותית יותר משאבים מקומיים (זכרון, CPU) כדי לראות את מה שהוא רוצה לראות.
מן הסתם, רק דפדפן שיכול להריץ JS יכול לרנדר דפים כאלו ולראות את ה-HTML הסופי. במקרים כאלו, אם ניגש לאתר מבוסס JS עם דפדפן שלא מריץ JS, לא נראה את התוכן שתלוי בהרצת JS כדי להופיע.
כך נראה קוד המקור של אתר (אינסטגרם) שפותח ב React. רואים תגיות HTML? גם אני לא.
איך גוגל מתמודד עם JS?
עד עכשיו דיברנו על דפדפנים. במטוטא, עשו חפש והחלף מ"דפדפן" ל"בוט". כל מה שתקף לגבי דפדפנים מודרניים תקף גם לגבי הבוטים של מנועי החיפוש, או כל ייצור אחר שסורק את האתר – אם הם לא יריצו JS, הם לא יראו את התוכן או את חלקו שתלוי בהרצת JS.
במקרה של הדף הזה, הדפדפן שלי יצטרך להריץ JavaScript כדי שיוכל לרנדר ולבנות את הדף במלואו. אותו הדבר לגבי בוטים. חשוב להבין שמרבית הבוטים של מנועי החיפוש הגדולים *יודעים* להריץ JS, הם אפילו יודעים לעשות את זה מצוין. למעשה, כל בוט שמבוסס על Chromium יכול תיאורטית לרנדר את הדף בשלמותו.
בגוגל משתמשים בשירות WRS (Web Rendering Service) על מנת לרנדר דפים - ובעצם כל דף מועבר דרך השירות הזה והסריקה מתבצעת ב-2 פעימות. קודם גוגל מקבל את ה-Source HTML, ולאחר שהדף מועבר דרך שירות ה-WSR, מקבלים את ה-Rendered HTML, שהוא הכי חשוב בעצם:
מתי שימוש ב-JS כן יכול להיות בעייתי (לפעמים, אולי)?
כפי שציינתי, גוגל אכן מריץ JS כדי לרנדר את הדף, ולקבל את ה-HTML הסופי שמעניין אותו (Rendered HTML), אבל כדאי לקחת כמה דברים בחשבון:
זה יקר ועשוי להאט סריקה
כמות המשאבים הנדרשת לרנדור של דף באתר מבוסס JavaScript עצומה בהשוואה לדף באתר עם HTML "מוכן". לפי ההצהרה של ג'ון מולר ב- Google Webmasters Conference שנערך בתל אביב טרום תקופת הקורונה, ביצוע Fetch לדף שבנוי על JavaScript לוקח בממוצע פי 20 יותר משאבים מדף רגיל.
גוגל הם כמובן חברה למטרות רווח, הם רוצים לחסוך במשאבים היכן שאפשר. לסרוק, לנתח ולאנדקס את כל האינטרנט הפתוח הידוע לאדם דורשים המון משאבים. עסק יקר. אז עכשיו לכו תוסיפו לרשימה הזו גם לרנדר את הכל.
בחיים כמו בחיין, כשמשהו עולה למישהו יותר, משתדלים לעשות אותו כמה שפחות. כלומר, אם הרצת JS ורנדור כל דף באינטרנט עולה לגוגל יותר משאבים (=כסף), סביר להניח שזה משהו שהם לא רוצים או יכולים לעשות בתדירות גבוהה מדי. ואכן, בגוגל מאשרים שהתור לשירות הרנדור שלהם (Web Rendering Service = WSR) נפרד וכנראה איטי יותר מהתור הרגיל.
האם קצב סריקה פוטנציאלית נמוך יותר הוא בעיה? לא בהכרח. אתר שמתעדכן בתדירות נמוכה ומפרסם פוסט פעם בחודש או שבועיים כנראה לא יפגע מכך. ככל שישנם באתר יותר דפים (תכנים/מוצרים) שמתעדכנים או שנוספים בתדירות גבוהה, כך החשיבות של הנושא גדולה יותר.
למה זה פחות חשוב באתרים ממש קטנים? תקציבי סריקה פחות משנים באתרים בסדרי גודל כאלה, וגם בואו, האנושות לא תקרוס אם הפוסט שלכם יתאנדקס באיחור קל. לאתרים גדולים שמייצרים המון תוכן או מעדכנים תוכן בתדירות גבוהה כמו אתרי חדשות או אתרי איקומרס גדולים, אולי תהיה בעיה בהקשר הזה. גם אז - לא תמיד בטוח.
כשמדובר באתרים בינוניים וגדולים שמתעדכנים כל הזמן, זה סיפור שונה. כן אני מדבר עליכם אתרי חדשות, ספורט, אתרי מסחר ואתרי תוכן גדולים. אתרים כאלו כל הזמן מייצרים תוכן חדש ומשנים תוכן קיים. עבורם אתרים כאלה חשוב מאוד שגוגל יבוא לגלות ולאנדקס דפים חדשים ושינויים בדפים קיימים בתדירות ובמהירות המקסימלית.
מה שיכול להשתבש בדרך כלל משתבש
כאמור, אתרים מבוססי JS מסתמכים על כך שגוגל ושות' יצליחו להריץ את הקוד כמו שצריך. אבל, מה קורה אם גוגלבוט לא מצליח לרנדר את התוכן או חלקים ממנו בגלל בעיה? זה יכול להיות בגלל חוסר יעילות בקוד, שגיאות, חוסר תמיכה או בגלל שמשאבים נחוצים לרנדור התוכן לא זמינים לגוגל. זוהי עוד חוליה בשרשרת ועוד נקודת כשל פוטנציאלית.
איך לבדוק אם יש בעיה באתר שבנוי על JS
כפי שכבר ציינתי, העובדה שאתר פותח על פריימוורק JS לא בהכרח אומר שיש לו בעיה. פגשתי כמה CTOs שמאוד מודעים לנושא ואף על פי שפיתחו אתר על JS, טיפלו גם באספקט של הנגשת ה-HTML בצורה יפה. עם כל זאת, better safe than sorry.
זהו התהליך שלי לבדיקת רנדור JS באתר:
ראשית, ממליץ להתשמשבתוסף כמו wappalyzer שמראה לכם על מה בנוי האתר. זו אינדקציה מהירה ושטחית לפריימוורק בו משתמש באתר ובדרך כלל מזהה את כל הנפוצים. חשוב לזכור שעצם השימוש ב-JS לא בהכרח אומר שיש בעיה.
בטלו JS בדפדפן – ניתן להוריד את Disable JavaScript, תוסף כרום שמאפשר לחסום JS בדפדפן. גשו לאתר המחשיד ובטלו את ה-JS. מה השתנה? ככלל, כל מה שנעלם לחלוטין, במיוחד תוכן, *כנראה* גם לא יראה בקוד המקור (Response HTML) עבור בוטים שלא מריצים JS.
בדיקה בקוד המקור – לחצו על ctrl+U ותגיעו לקוד המקור של הדף. חפשו בתוכו טקסט מתוך הכותרות ומתוך גוף התוכן. האם זה מופיע בתגיות הנכונות? האם התוכן שמוצג בדף מופיע בקוד? חשוב להשוות: תוכן, תמונות, קישורים פנימיים, תגיות מטא, קנוניקל וכו'). לא הכל חייב להיות אחד לאחד, אלא בעיקר התוכן והתגיות.
בדיקת Inspect URL בסרץ' קונסול תראה לכם את ה-HTML שגוגל רואה אחרי הרצת JS (מה שנקרא Rendered HTML) - אם זה שם, אז גוגלבוט ראה את זה והכל טוב.
אל תסתפקו בלבדוק רק את דף הבית, אתם עשויים לפספס דפים אחרים בהם כן יש בעיה. זכרו שבאתרים גדולים לא כל חלקי האתר פותחו במקביל או אפילו באותה השפה.
ובכל זאת, הדרך הכי בטוחה להתמודד עם JS
אמרנו שגוגל בוט כן יודע לרנדר אתרים מבוססי JS והוא אכן עושה זאת, אבל גם אמרנו שישנן כל מיני נקודות כשל פוטנציאליות ובדרך, וגם שישנם בוטים שלא מריצים JS ושבהכרח יתקלו בקשיים. אם קראתם עד כה, שאפו. אני מקווה שזה אומר שאתם כבר יודעים לאן אנחנו מכוונים - אם רוצים להיות בטוחים, אנחנו צריכים להגיש את ה-HTML הסופי לגוגלבוט ולאחרים מבלי להסתמך על יכולות או רצונות הרנדור שלהם.
ריענון קצר:
ב-SSR (או Server Side Rendering) השרת עושה את העבודה הכבדה ומגיש את ה-HTML הסופי, בעוד שב-CSR (או Client Side Rendering) הדפדפן הוא הסנג'ר. אנחנו רוצים SSR.
האם אני מגיש את ה-HTML הסופי רק לבוטים או גם למשתמשים אמיתיים? האם משתמשים בשירות Pre Render צד שלישי או באמת הולכים על רנדור מלא בצד השרת? כל אלו פחות משנים בשלב זה. לכל אחת מהדרכים יש יתרונות וחסרונות, בעיקר בכל הנוגע לתקורה. העיקרון אותו עיקרון – אנחנו רוצים שהבוטים של מנועי החיפוש יוכלו לראות את התוכן שלנו בקלות וביעילות מקסימלית.
אתם לא צריכים להבין בפיתוח כדי לעשות את זה בעצמכם, רק מספיק טוב כדי לדעת להנחות את מי שכן אמור להבין בזה, להגדיר את התוצאה הרצויה ולבסוף לבחון את התוצאה הסופית.
הפעלת SSR ב-React
החדשות הטובות הן שלריאקט יש תמיכה מובנית ב-SRR, שהשתפרה פלאות מאז יציאתה של גרסה 16.
ניתן להפעיל SSR בריאקט על ידי שימוש באובייקט מסוג ReactDOMServer. לא נכנס לכל הפרטים במאמר הזה, אבל חשוב לדעת שבגדול יש 2 דרכים לעשות SSR – רנדור מלא או שילוב ריהדרציה בה רוב הHTML כן מרונדר בצד השרת אבל חלק מהאלמנטים עדיין דינאמיים.
קישור לשליחה לפיתוח: הדוקומנטציה המלאה באתר ReactJS.org
הפעלת SSR ב-Angular
רנדור צד שרת זמין באנגולר 2 באמצעות שימוש בקומפוננטת Angular Universal
קישור לשליחה לפיתוח: המדריך הרשמי והמלא ל Angular Universal.
הפעלת SSR ב-View.js
קישור לשליחה לפיתוח: המדריך הרשמי של Vue.js
פתרונות נוספים
במידה והאתר המדובר בנוי על ספריות או גרסה שלא מגיעה עם תמיכה ב-SSR, ישנם כמה פתרונות אפשריים לבעיה, אך חלקם עשויים להיות מאוד יקרים בסקייל וחלקם לא בדיוק נחשבים SSR:
התקנה וקונפיגורציה של מודולים ברמת השרת, כמו Rendertron או Puppeteer
שימוש בפתרון המגיש עותק סטטי לחלוטין לבוטים (יש כאלה) = Static Site Generation (SSG)
שימוש בשירותים צד שלישי כמו prerender.io
נקודות לקחת איתכם
זה היה ארוך, אני יודע. מה שחשוב לקחת אתכם מהמאמר הזה:
להיות מודעים לגידול באתרים כאלו
לדעת לבדוק אם יש לכם בעיה
לדעת להסביר למה זו בעיה שמצריכה השקעה ואם זה אכן משהו שמשתלם להשקיע בו
לדעת להגדיר את התוצאה הרצויה
לדעת להכווין את הפיתוח בכיוון הנכון
יאללה, בהצלחה.