הסבר על הנתיב הקריטי

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

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

רינדור הדרגתי

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

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

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

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

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

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

נתיב העיבוד (הקריטי)

נתיב העיבוד כולל את השלבים הבאים:

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

רק אחרי שמשלימים את כל השלבים האלה, המשתמשים יראו את התוכן במסך.

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

אילו משאבים נמצאים בנתיב העיבוד הקריטי?

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

  • חלק מה-HTML.
  • CSS שחוסם עיבוד ברכיב <head>.
  • JavaScript חוסם עיבוד ברכיב <head>.

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

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

  • כל קוד ה-HTML.
  • גופנים.
  • תמונות.
  • JavaScript שלא חוסם את העיבוד מחוץ לאלמנט <head> (לדוגמה, רכיבי <script> שהוצבו בסוף ה-HTML).
  • CSS שאינו חוסם עיבוד מחוץ לאלמנט <head>, או CSS עם ערך media מאפיין שלא רלוונטי לאזור התצוגה הנוכחי.

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

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

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

משאבים שחוסמים עיבוד

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

כשדפדפן רואה CSS – לא משנה אם מדובר ב-CSS מובנה ברכיב <style> או במשאב שיש הפניה אליו באופן חיצוני שצוין על ידי אלמנט <link rel=stylesheet href="..."> – הדפדפן נמנע מרינדור תוכן נוסף עד שהוא מסיים להוריד ולעבד את ה-CSS הזה.

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

משאבים שחוסמים את העיבוד, כמו CSS, משמשים לחסימה של כל הרינדור של הדף כשהוא התגלה. כלומר, אם שירות CSS מסוים חוסם את העיבוד או לא תלוי בשאלה אם הדפדפן גילה אותו. חלק מהדפדפנים (Firefox בהתחלה, ועכשיו גם Chrome) חוסמים רק את העיבוד של תוכן שנמצא מתחת למשאב לחסימת העיבוד. כלומר, בנתיב הקריטי לחסימת עיבוד, אנחנו בדרך כלל מעוניינים במשאבים שחוסמים עיבוד ב-<head>, כי הם חוסמים ביעילות את העיבוד של כל הדף.

חידוש עדכני יותר הוא המאפיין blocking=render שנוסף ל-Chrome 105. כך מפתחים יכולים לסמן באופן מפורש אלמנט <link>, <script> או <style> כחוסם רינדור עד לעיבוד הרכיב, אבל עדיין מאפשר למנתח להמשיך לעבד את המסמך בינתיים.

משאבים שחוסמים את הניתוח

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

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

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

זיהוי משאבים חוסמים

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

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

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

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

צילום מסך של הביקורת של Lighthouse להסרת משאבים שחוסמים עיבוד. הביקורת מציגה את המשאבים שחוסמים את העיבוד ואת משך הזמן שהם חוסמים.

אופטימיזציה של נתיב העיבוד הקריטי

אופטימיזציה של נתיב העיבוד הקריטי כרוכה בקיצור הזמן לקבלת ה-HTML (המיוצג על ידי המדד 'Time to First Byte (TTFB)'), כפי שפירטנו במודול הקודם, וצמצום ההשפעה של משאבים שחוסמים עיבוד. אנחנו נחקור את העקרונות האלה במודולים הבאים.

נתיב עיבוד התוכן הקריטי

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

במקום זאת, תצוגה חלופית היא להתרכז בפרק הזמן עד להצגת המהירות שבה נטען רכיב התוכן הכי גדול (LCP) – או אפילו עד ל-First Contentful Paint (FCP) – כחלק מנתיב הרינדור של התוכן (או הנתיב של המפתח כמו שאחרים יקראו לו). במקרה כזה, יכול להיות שתצטרכו לכלול משאבים שלא חוסמים בהכרח את השימוש (כמו ההגדרה האופיינית לנתיב הרינדור הקריטי), אבל הם נדרשים כדי לעבד המרת תוכן (FCP).

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

זיהוי נתיב הרינדור הקיים בתוכן

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

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

באתרים מורכבים יותר, הכלי Lighthouse גם מדגיש שרשראות של בקשות קריטיות בביקורת נפרדת:

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

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

בוחנים את הידע

מה מתייחס נתיב העיבוד הקריטי?

הכמות המינימלית של משאבים שנדרשת לעיבוד מלא של הדף.
אפשר לנסות שוב.
כמות המשאבים המינימלית שדרושה לצורך עיבוד ראשוני של הדף.
נכון!

אילו משאבים מעורבים בנתיב העיבוד הקריטי?

חלק מה-HTML.
נכון!
CSS שחוסם עיבוד ברכיב <head>.
נכון!
JavaScript חוסם עיבוד ברכיב <head>.
נכון!

למה חסימת עיבוד היא חלק הכרחי בעיבוד הדף?

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

למה JavaScript חוסם את מנתח ה-HTML (בהנחה שהמאפיינים defer, async או module לא צוינו ברכיב <script>)?

ללא לפחות אחד מהמאפיינים האלה, <script> חוסם מנתחים וחוסם עיבוד.
נכון!
כל קוד JavaScript נחסם על ידי מנתח, ללא קשר למאפיינים האלה.
אפשר לנסות שוב.
יש להפעיל JavaScript סינכרוני כשהמנתח מגיע אליו מכיוון שהוא יכול לשנות את ה-DOM.
נכון!

השלב הבא: אופטימיזציה של טעינת המשאבים

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