במדריך זה אצלול לפרטים ואסביר מה זה Server Side Rendering, מי צריך את זה, למה זה משהו שכל כך קריטי להכיר בתחום ה-SEO, הסכנות מבחינת SEO והפתרונות האפשריים.

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

קצת על JS Frameworks ואתרים מבוססים JavaScript

מבלי להיכנס לפרטים טכניים מדי, JS Frameworks הן אוסף ספריות JS מוכנות מראש (נקראות גם קומפוננטות) שמאפשר לבנות אפליקציות / אתרים / Single Page Applications.

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

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

למה יותר אתרים נבנים על תשתית JS?

הסיבות למעבר לבניית אתרים עם JS frameworks ברורות – זמני הפיתוח מתקצרים, חווית המשתמש משתפרת, זמני הטעינה משתפרים (תלוי בכשירות המפתח/ת) וזה סקלבילי. בתכלס? אלו אתרים שמספקים חוויות משתמש חלקה יותר, נקודה.

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

עם הזמן, האתרים מתרחבים, או שצריך להוסיף פונקציונאליות מסוימת. מה יבחר לעשות כל CTO שפוי? להמשיך להשתמש בקוד מיושן שהוא שונא או להשיק סאבדומיין חדש עם קוד מודרני שחוסך לו המון כאב ראש? זה למה JS frameworks.

בכל זאת, רציתי לוודא שזו לא רק תחושה או צירוף מקרים מצידי. כיוון שאנחנו אנשי SEO, בחנתי את הטרנדים ב-5 שנים האחרונות בגוגל ישראל באמצעות Google Trends.

ניתן לראות בבירור ש-React כבר שנים במגמת עלייה ותופסת נתח משמעותי מבחינת ביקושים בגוגל. גם הפופולריות של vue.js עלתה עם השנים והיא הגיעה למצב בו עקפה את אנגולר הדועכת.

טרנד ביקושים בגוגל לריאקט, אנגולר ו vue.js
טרנד ביקושים בגוגל לריאקט, אנגולר ו vue.js. מקור: Google Trends

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

שמרתם? יופי, בואו נמשיך.

הבעיה עם Javascript ו-SEO

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

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

רוצים דוגמה? קבלו. האתר של אינסטגרם בנוי בשלמותו על React, בואו נראה איך הוא מוצג עם תמיכה ב-JavaScript וללא תמיכה ב-JavaScript:

האם גוגל יודע לקרוא JavaScript?

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

כך נראה קוד המקור של אתר (שוב אינסטגרם) שפותח ב React. רואים תגיות HTML? גם אני לא.

קוד של אתר React ללא SSR
קוד של אתר React ללא SSR

במקרה של הדף הזה, הדפדפן שלי יצטרך להריץ JavaScript כדי שיוכל לרנדר ולבנות את הדף במלואו. אותו הדבר לגבי בוטים.

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

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

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

השפעה על תקציב זחילה, סריקה ואנדוקס

כמות המשאבים הנדרשת לרנדור של דף באתר מבוסס JavaScript עצומה בהשוואה לדף באתר עם HTML "מוכן". לפי ההצהרה של ג'ון מולר ב- Google Webmasters Conference שנערך בתל אביב לאחרונה, ביצוע Fetch לדף שבנוי על JavaScript לוקח בממוצע פי 20 יותר משאבים מדף רגיל.

הנה, צילמתי עקום אבל צילמתי:

שקף מהמצגת של ג'ון מולר. צילום: נתי אלימלך
שקף מהמצגת של ג'ון מולר. צילום: נתי אלימלך

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

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

איך גוגל זוחל וסורק דפים המצריכים רנדור
איך גוגל זוחל וסורק דפים המצריכים רנדור. מקור

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

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

למי זה באמת חשוב?

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

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

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

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

איך לבדוק אם יש לכם בעיה

העובדה שאתר פותח על תשתית JS לא בהכרח אומר שיש לו בעיה. פגשתי כמה CTOs שמאוד מודעים לנושא ולמרות שפיתחו אתר על JS, טיפלו גם באספקט של הנגשת ה-HTML בצורה יפה. עם כל זאת, better safe than sorry.

זה התהליך שלי לבדיקת רנדור JS באתר:

  1. שימוש בתוסף כמו wappalyzer שמראה לכם על מה בנוי האתר. זו אינדקציה מהירה ושטחית לפריימוורק בו משתמש באתר ובדרך כלל מזהה את כל הנפוצים. חשוב לזכור שעצם השימוש ב-JS לא בהכרח אומר שיש בעיה
  2. חסימת JS באתר – ניתן להוריד את Disable JavaScript, תוסף כרום שמאפשר לחסום JS בדפדפן. גשו לאתר המחשיד ובטלו את ה-JS. מה השתנה? ככלל, כל מה שנעלם לחלוטין, במיוחד תוכן, *כנראה* גם לא יראה בקוד המקור.
  3. בדיקה בקוד המקור – לחצו על ctrl+U ותגיעו לקוד המקור של הדף. חפשו בתוכו טקסט מתוך הכותרות ומתוך גוף התוכן. האם זה מופיע בתגיות הנכונות? האם התוכן שמוצג בדף מופיע בקוד?
  4. בדיקת Inspect URL בסרץ' קונסול תראה לכם אם גוגלבוט מצליח לרנדר את הדף. הוא אמור. אם לא – אולי יש בעיה מהותית יותר שמצריכה טיפול.

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

הפתרון – Server Side Rendering

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

כלומר, להגיש את ה-HTML המלא לבוטים ולחסוך מהם את עבודת הרנדור.

ב-SSR (או Server Side Rendering) השרת עושה את העבודה הכבדה ומגיש את ה-HTML הסופי, בעוד שב-CSR (או Client Side Rendering) הדפדפן הוא הסנג'ר. אנחנו רוצים SSR.

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

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

הפעלת SSR ב-React

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

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

קישור לשליחה לפיתוח: הדוקומנטציה המלאה באתר ReactJS.org.

הפעלת SSR ב-Angular

SSR זמין באנגולר 2 באמצעות שימוש בקומפוננטת Angular Universal.

React - renderToString
React – renderToString

קישור לשליחה לפיתוח: המדריך הרשמי והמלא ל Angular Universal.

הפעלת SSR ב-Vue.js

אפשר להפעיל SSR ב Vue באמצעות שימוש ב-3 ספריות:

  • vue & vue-server-renderer 2.3.0+
  • vue-router 2.5.0+
  • vue-loader 12.0.0+ & vue-style-loader 3.0.0+

קישור לשליחה לפיתוח: המדריך הרשמי של Vue.js

פתרונות נוספים

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

  • התקנה וקונפיגורציה של מודולים ברמת השרת, כמו Rendertron או Puppeteer
  • שימוש באחסון המגיש עותק סטטי לחלוטין לבוטים (יש כאלה)
  • שימוש בשירותים צד שלישי כמו prerender.io

נקודות לקחת איתכם

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

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

אם ישנן שאלות נוספות בנושא. מוזמנים להגיב ונדבר על זה.