עיבוד בצד הלקוח לעומת עיבוד בצד השרת

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

ביצועים

עם עיבוד בצד השרת, בכל פעם שתרצה לראות דף אינטרנט חדש, עליך לצאת ולקבל אותו:

זה מקביל לך לנסוע לשוק העל בכל פעם שאתה רוצה לאכול.

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

לכל גישה יש את היתרונות והחסרונות שלה בכל הקשור לביצועים:

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

ליתר דיוק, עם עיבוד בצד הלקוח, הדף הראשוני ייראה כך:


  <ראש>

app.js יכלול את כל דפי ה- HTML ב- JavaScript כמחרוזות. משהו כזה:

דפי var = {
  '/': ' ... ',
  '/ foo': ' ... ',
  '/ bar': ' ... ',
};

לאחר מכן, כאשר העמוד נטען, המסגרת תסתכל בסרגל הכתובות, תקבל את המחרוזת בעמודים ['/'] ותכניס אותו ל

. כמו כן, כשאתה לוחץ על קישורים, המסגרת תיירט את האירוע, תכניס את המחרוזת החדשה (נניח, עמודים ['/ foo']) למכל, ותמנע מהדפדפן לנתק את בקשת HTTP כמו שקורה בדרך כלל.

קידום אתרים

נניח שסורק האינטרנט שלנו מתחיל לבקש בקשה ל- reddit.com:

var request = demand ('בקשה');
request.get ('reddit.com', פונקציה (שגיאה, תגובה, גוף) {
  // הגוף נראה כך:
  // 
  //  ... 
  // 
  //  ESPN 
  //  חדשות האקר 
  // ... תגיות אחרות  ...
});

לאחר מכן הסורק משתמש בדברים בגוף התגובה כדי ליצור בקשות חדשות:

var request = demand ('בקשה');
request.get ('reddit.com', פונקציה (שגיאה, תגובה, גוף) {
  // הגוף נראה כך:
  // 
  //  ... 
  // 
  //  ESPN 
  //  חדשות האקר 
  // ... תגיות אחרות  ...

  request.get ('espn.com', פונקציה () {...});
  request.get ('news.ycombinator.com', פונקציה () {...});
});

לאחר מכן הסורק ממשיך בתהליך על ידי שימוש בקישורים באתר espn.com ו- news.ycombinator.com כדי להמשיך לזחול.

להלן קוד רקורסיבי לשם כך:

var request = demand ('בקשה');

פונקצית crawlUrl (url) {
  request.get (url, פונקציה (שגיאה, תגובה, גוף) {
    var linkUrls = getLinkUrls (גוף);

    linkUrls.forEach (פונקציה (linkUrl) {
      crawlUrl (linkUrl);
    });
  });
}

crawlUrl ('reddit.com');

מה היה קורה אם גוף התגובה היה נראה כך:


  <ראש>

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

מעט יודע הסורק, Client Side Framework עומד למלא את

עם שלל תוכן מדהים.

זו הסיבה שעיבוד צד לקוח יכול להיות רע עבור קידום אתרים.

טרום הקדמה

בשנת 2009 גוגל הציגה דרך לעקוף זאת.

https://webmasters.googleblog.com/2009/10/proposal-for-making-ajax-crawlable.html

כאשר הסורק נתקל בכתובת www.example.com/page?query#!mystate, הוא היה ממיר אותו ל- www.example.com/page?query&_escaped_fragment_=mystate. בדרך זו, כאשר השרת שלך מקבל בקשה באמצעות _escaped_fragment_, הוא יודע שהבקשה באה מסורק ולא מאדם.

זכור - השרת רוצה שהסורק יראה

...

(עם התוכן בפנים), ולא

. ואז:

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

ולאפשר ל- JavaScript להכניס תוכן פנימה.

יש בעיה עם זאת: השרת לא יודע מה ייכנס ל

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

סורקים חכמים יותר

שש שנים לאחר מכן, גוגל הודיעה כי הסורק שלה מתיישר! כאשר Crawler 2.0, רואה תגיות , הוא בעצם מבקש בקשה, מריץ את הקוד ומתמרן את ה- DOM. ממש כמו דפדפן אינטרנט.

אז במקום רק לראות:

זה רואה:


  ...
  ...
  ...
  ...
  ...

אתה יכול להשתמש ב- Fetch כ- Google כדי לקבוע מה הסורק של Google רואה כאשר הוא מבקר בכתובת אתר מסוימת.

קטע רלוונטי מההודעה:

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

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

פחות סורקים חכמים

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

https://www.netmarketshare.com/search-engine-market-share.aspx?qprid=4&qpcustomd=0

מנועי החיפוש האחרים אינם טובים בטיפול ב- JavaScript. ראה SEO לעומת תגובה: סורקי אינטרנט הם חכמים יותר ממה שאתה חושב למידע נוסף.

הטוב שבשני העולמות

כדי להפיק את המיטב משני העולמות, באפשרותך לבצע את הפעולות הבאות:

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

שקול מה ההשלכות של זה:

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

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

זוויתית, תגובה ויימבר כולם עברו לגישה זו.

דיון

ראשית, כמה דברים שצריך לקחת בחשבון:

בערך 2% מהמשתמשים הושבתו JavaScript, ובמקרה זה העיבוד בצד הלקוח לא יעבוד כלל.
בערך 1/4 מחיפושים ברשת מתבצעים עם מנועים שאינם גוגל.
לא לכולם יש חיבור מהיר לאינטרנט.
לאנשים בטלפונים שלהם בדרך כלל אין חיבור מהיר לאינטרנט.
ממשק משתמש מהיר מדי יכול להיות מבלבל! נניח שהמשתמש לוחץ על קישור. האפליקציה לוקחת אותם לתצוגה חדשה. אולם התצוגה החדשה שונה רק בעדינות מהנוף הקודם. והשינוי התרחש באופן מיידי (מכיוון שאנשים מעובדים מצד הלקוח אוהבים להתפאר). ייתכן שהמשתמש לא יבחין בכך שתצוגה חדשה נטענת בפועל. או אולי המשתמש שם לב, אך מכיוון שהיה עדין יחסית, המשתמש היה צריך להפעיל מאמץ כלשהו כדי לגלות האם המעבר אכן קרה או לא. לפעמים נחמד לראות קצת ספינר טוען ולעבד מחדש את העמוד המלא. זה מונע מאיתנו צורך לפזול כדי לראות שינויים.
במידה מסוימת, הגיוני לתכנת לאן הולך להיות פאק הביצועים. המשתמשים שלך הולכים להיות שילוב של אנשים שחיים בשנת 2017, 2019, 2020 וכו '. לא הגיוני להעמיד פנים שכולם חיים בשנה 2017. כן, תוכל לעדכן את האפליקציה שלך בשנה הבאה פעם אחת השיפורים במהירות קורים ... אבל לוקח את הזמן לעשות זאת בהחלט אינו חופשי.
מטמון זה דבר. אז עם עיבוד בצד השרת, פעמים רבות המשתמש לא צריך ממש ללכת לשרת. ולפעמים הם רק צריכים ללכת לשרת בסמוך, ולא ל" הרשמי "שמעבר לאוקיינוס.
#perfmatters.

https://www.slideshare.net/phaithful/seo-and-js-new-challenges

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

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

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

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

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

classicfoxvalley.com