התהליך הראשי של הדפדפן הוא משאב יקר — כך מנצלים אותו בתבונה

רוב הדיון באופטימיזציית פרונטאנד סובב סביב בקשות רשת, גודל החבילה ומטמון. התהליך הראשי (main thread) כמעט לא עולה, כי במסכים רגילים הוא אינו מהווה בעיה. אבל במסכים עתירי אינטראקציה שום חיסכון ברשת לא יעזור אם התהליך שמריץ את הקוד חסום. הפוסט "The Browser's Main Thread Is Expensive" בבלוג kciter.so מוקדש בדיוק למשאב הזה.

תהליך אחד, שני תפקידים

התהליך הראשי מריץ JavaScript — הקוד שלכם, מטפלי אירועים, טיימרים ולוגיקה פנימית של פריימוורקים — ומצייר את המסך: חישוב סגנונות, פריסה וצביעה. כדי שהמסך ייראה חלק, יש להפיק פריים בקצב רענון התצוגה: כ-16.6 מילישניות במסך 60Hz, ותקציב מעשי של כ-10 מ"ש לאחר הפחתת עלות הדפדפן. JavaScript פועל במודל לולאת אירועים חד-תהליכית: בזמן שמשימה אחת רצה, שום דבר אחר לא קורה. פונקציה של 200 מ"ש מקפיאה את הצביעה, האנימציה והקלט. משימות מעל 50 מ"ש נחשבות למשימות ארוכות, ומדדים כמו INP ו-TBT מודדים בעצם כמה זמן התהליך הראשי היה חסום. הסיבה בדרך כלל אינה קוד איטי — די בכך שהקוד תופס את התהליך.

ארבע דרכים להוצאה נבונה

המאמר מקבץ את הטכניקות לארבע: פיצול, קיבוץ, תעדוף ודחייה. פיצול חותך עבודה ארוכה לחלקים ומשחרר את התהליך ביניהם — למשל אחרי כל 20 הודעות צ'אט, או בתקציב של 5 מ"ש לפריים. השחרור אינו מאיץ את העבודה; הוא יוצר את הרווחים שבהם הדפדפן מצליח לטפל בקלט ולצייר מחדש.

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

מחוץ לתהליך הראשי

חלק מהעבודה אפשר למסור כליל. אנימציה של transform ו-opacity נשארת בתהליך המשלב (compositor) וחלקה גם כשהמחשב עסוק, בעוד אנימציה של top או width מחייבת פריסה בכל פריים; טכניקת FLIP הופכת שינוי פריסה אמיתי לאנימציית transform. Web worker יכול לבצע חישוב כבד כמו פענוח נתונים או עיבוד תמונות, אך אין לו גישה ל-DOM והוא מחליף נתונים בהעתקה — אלא אם מעבירים בעלות על חוצץ, כמעט ללא עלות.

לא לבצע את העבודה כלל

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