עיבוד בצד הלקוח של HTML ואינטראקטיביות

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

Jeremy Wagner

ניתוח ורינדור של HTML הם דברים שהדפדפנים עושים בצורה טובה מאוד כברירת מחדל לאתרים שמשתמשים בלוגיקה המובנית של הדפדפן לניווט – לפעמים נקראים 'טעינות דפים מסורתיות' או 'ניווטים קשיחים'. אתרים כאלה נקראים לפעמים אפליקציות בכמה דפים (MPA).

עם זאת, מפתחים יכולים לעקוף את הגדרות ברירת המחדל של הדפדפן בהתאם לצרכים של האפליקציה שלהם. זה בהחלט המצב באתרים שמשתמשים בתבנית של אפליקציית דף יחיד (SPA), שבה חלקים גדולים של ה-HTML/DOM נוצרים באופן דינמי אצל הלקוח באמצעות JavaScript. עיבוד בצד הלקוח הוא השם של דפוס העיצוב הזה, והוא יכול להשפיע על מהירות התגובה לאינטראקציה באתר (INP) אם העבודה הכרוכה בו היא מוגזמת.

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

איך הדפדפן מבצע עיבוד של HTML שסופק על ידי השרת

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

1. הדפדפן שולח בקשת ניווט לכתובת ה-URL שצוינה.
2. השרת מגיב עם HTML בקטעים.

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

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

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

איך הדפדפן מבצע עיבוד של HTML שמסופק על ידי JavaScript

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

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

יש כמה דרכים נפוצות ליצירת HTML או להוספה ל-DOM באמצעות JavaScript:

1. המאפיין innerHTML מאפשר להגדיר את התוכן ברכיב קיים באמצעות מחרוזת שהדפדפן מנתח ל-DOM.
2. השיטה document.createElement מאפשרת ליצור רכיבים חדשים להוספה ל-DOM בלי להשתמש בניתוח HTML בדפדפן.
3. השיטה document.write מאפשרת לכתוב HTML במסמך (והדפדפן מנתח אותו, בדיוק כמו בגישה מס' 1). עם זאת, מסיבות שונות, לא מומלץ להשתמש ב-document.write.

ליצירת HTML/DOM באמצעות JavaScript בצד הלקוח יכולות להיות השלכות משמעותיות:

• בניגוד ל-HTML שמשודר על ידי השרת בתגובה לבקשת ניווט, משימות JavaScript בצד הלקוח לא מחולקות באופן אוטומטי למקטעים, מה שעלול לגרום למשימות ארוכות שיחסמו את הליבה הראשית. כלומר, אם יוצרים יותר מדי HTML/DOM בכל פעם בצד הלקוח, יכול להיות שה-INP של הדף יושפע לרעה.
• אם קובץ HTML נוצר בלקוח במהלך ההפעלה, המשאבים שמפנים אליו לא יימצאו על ידי סורק הטעינה מראש של הדפדפן. לכך תהיה בהחלט השפעה שלילית על המהירות שבה נטען רכיב התוכן הכי גדול (LCP) בדף. זו לא בעיית ביצועים בסביבת זמן הריצה (אלא בעיה של עיכוב ברשת באחזור משאבים חשובים), אבל לא כדאי להימנע מהאופטימיזציה הבסיסית הזו של ביצועי הדפדפן כדי שה-LCP של האתר לא יושפע.

מה אפשר לעשות לגבי ההשפעה של רינדור בצד הלקוח על הביצועים

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

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

לספק כמה שיותר HTML מהשרת

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

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

• ב-React, כדאי להשתמש ב-Server DOM API כדי להפיק קוד HTML בשרת. עם זאת, חשוב לזכור: בשיטה המסורתית של רינדור בצד השרת נעשה שימוש בגישה סינכרונית, שעלולה להוביל לזמן ארוך יותר לקבלת הבאיט הראשון (TTFB), וגם לגרום לזמן ארוך יותר במדדים הבאים, כמו הצגת תוכן ראשוני (FCP) ו-LCP. במידת האפשר, מומלץ להשתמש בממשקי ה-API לסטרימינג של Node.js או של סביבות זמן ריצה אחרות של JavaScript, כדי שהשרת יוכל להתחיל את הסטרימינג של HTML לדפדפן בהקדם האפשרי. Next.js – מסגרת מבוססת-React – מספקת שיטות מומלצות רבות כברירת מחדל. בנוסף לעיבוד אוטומטי של HTML בשרת, הוא יכול גם ליצור HTML באופן סטטי לדפים שלא משתנים בהתאם להקשר של המשתמש (כמו אימות).
• ב-Vue מתבצע גם עיבוד מצד הלקוח כברירת מחדל. עם זאת, בדומה ל-React, גם Vue יכול ליצור גרסת רינדור של רכיב ה-HTML בשרת. מומלץ לנצל את ממשקי ה-API האלה בצד השרת כשהדבר אפשרי, או לשקול הפשטה ברמה גבוהה יותר לפרויקט Vue כדי להקל על הטמעת השיטות המומלצות.
• מערכת Svelte מעבדת HTML בשרת כברירת מחדל. עם זאת, אם לקוד הרכיב שלכם דרושה גישה למרחבי שמות ייחודיים לדפדפן (window, לדוגמה), יכול להיות שלא תוכלו לעבד את ה-HTML של הרכיב הזה בשרת. כשהדבר אפשרי, כדאי לבחון גישות חלופיות כדי שלא תגרמו לעיבוד מיותר בצד הלקוח. SvelteKit – שדומה ל-Svelte כמו ש-Next.js דומה ל-React – מוטמעות בו כמה שיותר שיטות מומלצות בפרויקטים של Svelte, כדי שתוכלו להימנע ממלכודות פוטנציאליות בפרויקטים שבהם נעשה שימוש ב-Svelte בלבד.

הגבלת מספר צומתי ה-DOM שנוצרים בלקוח

כאשר DOM גדולים, כמות העיבוד הנדרשת כדי להציג אותם נוטה לגדול. בין שהאתר שלכם הוא SPA מלא ובין שהוא מזריץ צמתים חדשים ל-DOM קיים כתוצאה מאינטראקציה ב-MPA, מומלץ לשמור על ה-DOMs האלה קטנים ככל האפשר. כך תוכלו להפחית את העבודה שנדרשת במהלך העיבוד בצד הלקוח כדי להציג את ה-HTML הזה, וכך להקטין את הערך של INP באתר.

שימוש בארכיטקטורה של קובץ שירות בסטרימינג

זוהי טכניקה מתקדמת, שעשויה שלא לפעול בקלות בכל תרחיש לדוגמה, אבל היא יכולה להפוך את ה-MPA לאתר שנראה כאילו הוא נטען באופן מיידי כשמשתמשים מנווטים מדף אחד לדף הבא. אפשר להשתמש בקובץ שירות כדי לשמור במטמון מראש את החלקים הסטטיים של האתר ב-CacheStorage, תוך שימוש ב-ReadableStream API כדי לאחזר מהשרת את שאר ה-HTML של הדף.

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

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

סיכום

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

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

אם תצליחו לצמצם את העיבוד בצד הלקוח באתר שלכם למינימום האפשרי, תוכלו לשפר לא רק את מדד INP של האתר, אלא גם מדדים אחרים כמו LCP,‏ TBT ואולי אפילו TTFB במקרים מסוימים.

התמונה הראשית (Hero) מ-Unsplash, מאת Maik Jonietz.