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

הבקשה (The Request)

מרגע שסיימנו לכתוב את כתובת הדף המבוקש (ה-URL) או שלחצנו על קישור, שולח הדפדפן בקשה אל שרת האינטרנט. הבקשה מעובדת על ידי השרת והמנועים שעומדים מאחוריו (PHP, ASP.NET, Java, Python ואחרים) עד אשר הושלמה מלאכת בניית דף ה-HTML אותו ביקשנו. בשלב זה לא נתעכב על מאחורי הקלעים של שרת ה-Web כיון שברובם המוחלט של האתרים, צוואר הבקבוק אינו נמצא בשלב זה.

מה שחשוב לנו לדעת הוא שמרגע שהשרת התחיל לשלוח אלינו חזרה את הדף, עם קבלת הבית (Byte) הראשון מתחיל השלב שבו הדפדפן נכנס לפעולה. אם ברצונכם להבין מה הזמן שלוקח לשרת להגיב לבקשה הראשית ולייצר את הדף, תוכלו להסתכל על ה-waterfall chart (מדריך מהיר להבנת התרשים פורסם כאן) ולחפש את הקריאה הראשונה לדף. ה-Time To First Byte, או בקיצור TTFB של הבקשה הוא זמן השרת.

דף חדש נולד – The Response

מרגע קבלת הבית הראשון של התשובה מהשרת, מתחיל הדפדפן להעביר את הטקסט שהגיע ל-HTML Parser. בתהליך שנקרא טוקניזציה (tokenization), ה-Parser מייצר token-ים עבור כל תחילת תג, סוף תג וכל תו ביניהם. למשל, אם מתקבל הטקסט <b>hello</b>, מייצר תהליך זה שבעה Token-ים:

start-tag { name: b }
character { data: h }
character { data: e }
character { data: l }
character { data: l }
character { data: o }
end-tag { name: b }

אחרי שכל Token נוצר, הוא מועבר לפי סדר הגעה לרכיב אשר בונה את עץ ה-DOM. רכיב זה מייצר את ה"ענפים" המתאימים בעץ שייצג לנו את דף ה-HTML אותו קיבלנו מהשרת. ברגע שבו ענף פונה למשאב חיצוני כמו תמונה, סקריפט או קובץ CSS, מתחיל תהליך של הבאת אותו משאב. הדפדפן עצמו בנוי לבצע מספר פעילויות מסוג זה  במקביל על מנת לקצר את הזמן הדרוש להשלמת שלב זה. רמת המקביליות נעה בין 4 ל-8 פעולות מול כתובת שרת בודדת ומשתנה מדפדפן לדפדפן. כל תהליך ה-Parsing יעיל תמיד למעט הטיפול בדבר אחד: סקריפטים.

סקריפטים

כאשר מגיע ה-Parser לתג סיום סקריפט הוא חייב להריצו לפני שיוכל להמשיך ב-parsing עצמו. זה נכון לכל המקרים למעט סקריפטים שצויינו במפורש ככאלו שייטענו או יופעלו מאוחר יותר באמצעות תגיות Defer או Async. לפני שסקריפט יכול לרוץ, חייבים להתקיים שני תנאים:

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

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

למה לעצור את ניתוח הדף ?

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

למה לחכות להגדרות העיצוב ?

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

האם ההמתנה פוגעת בביצועים ?

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

איך מתמודדים ?

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

סיימנו, מה עכשיו ?

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

בשורה התחתונה

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