ככל שאנחנו בונים אתרים שמסתמכים יותר על JavaScript, לפעמים אנחנו משלמים על מה שאנחנו שולחים בדרכים שלא תמיד אנחנו יכולים לראות בקלות. במאמר הזה נסביר למה אפשר להיעזר במשמעת מסוימת כדי שהאתר שלכם ייטען ויהיה אינטראקטיבי במהירות במכשירים ניידים. כשמעבירים פחות JavaScript, זמן ההעברה ברשת יכול להצטמצם, נדרש פחות זמן לפריסת הקוד ופחות זמן בניתוח והידור של ה-JavaScript.
רשת
כשרוב המפתחים חושבים על העלות של JavaScript, הם חושבים עליה במונחים של עלות ההורדה והביצוע. שליחת בייטים נוספים של JavaScript באמצעות הכבל לוקחת יותר זמן, ככל שהחיבור של המשתמש איטי יותר.
זו יכולה להיות בעיה, כי סוג החיבור האפקטיבי לרשת שהמשתמש לא יכול להיות הוא לא 3G, 4G או Wi-Fi. אפשר להתחבר לרשת Wi-Fi בבית קפה, אבל לנקודה לשיתוף אינטרנט ברשת סלולרית עם מהירויות של 2G.
אפשר לצמצם את עלות ההעברה ברשת של JavaScript באמצעות:
- שליחת הקוד שמשתמש צריך בלבד.
- הקטנה
- כדי הקטנת קוד ES5, משתמשים ב-UglifyJS.
- השתמשו ב-babel-minify או ב-uglify-es כדי להקטין את התצוגה של ES2015+.
- דחיסה
- הסרת קוד שלא נמצא בשימוש.
- זיהוי הזדמנויות לקוד שאפשר להסיר או לטעון אותו באופן מדורג בעזרת הכיסוי של קוד הפיתוח
- כדאי להשתמש ב-babel-preset-env וברשימת הדפדפנים כדי למנוע העברה של תכונות שכבר קיימות בדפדפנים מודרניים. מפתחים מתקדמים עשויים לגלות שניתוח קפדני של חבילות Webpack עוזר לזהות הזדמנויות לקצץ יחסי תלות לא נחוצים.
- להסרת קוד, ראו ניעור עצים, האופטימיזציות המתקדמות של ClosureCompiler ושל חיתוך יישומי פלאגין כמו lodash-babel-פלאגין ב-webpack או ContextReplacementPlugin בספריות כמו רגע.js.
- שמירת קוד במטמון לצמצום נסיעות ברשת.
- כדאי להשתמש בשמירת HTTP במטמון כדי לוודא שהתגובות נשמרות במטמון של הדפדפנים בצורה יעילה. לקבוע את משך החיים האופטימלי של סקריפטים (גיל מקסימלי) ולספק אסימוני אימות (ETag) כדי למנוע העברה של בייטים שלא השתנו.
- השמירה במטמון של Service Worker יכולה להפוך את רשת האפליקציות לעמידה יותר, ולהעניק לכם גישה נרחבת לתכונות כמו מטמון הקוד של V8.
- כדאי להשתמש בשמירה לטווח ארוך במטמון כדי להימנע מאחזור מחדש של משאבים שלא השתנו. אם אתם משתמשים ב-Webpack, קראו את המאמר גיבוב (hashing) של שמות קבצים.
ניתוח/הידור
אחרי ההורדה, אחת מהעלויות הכבדות ביותר של JavaScript היא הזמן שמנוע JS ינתח/ידר את הקוד הזה. ניתוח והידור בכלי הפיתוח ב-Chrome הם חלק מהזמן הצהוב של 'כתיבת סקריפטים' בחלונית הביצועים.
הכרטיסיות 'למטה למעלה' ו'עץ שיחות' מציגות תזמונים מדויקים של ניתוח/הידור:
אבל למה זה חשוב?
הוצאה ארוכה של ניתוח או הידור של קוד יכולה לעכב בצורה משמעותית את זמן האינטראקציה של המשתמש עם האתר. ככל שתשלחו יותר קוד JavaScript, כך האתר שלכם יהיה אינטראקטיבי יותר, כך שייקח יותר זמן לנתח ולהדר אותו.
בייט לבייט, העיבוד ב-JavaScript יקר יותר מבחינת הדפדפן מאשר תמונה בגודל דומה או גופן אינטרנט — Tom Dale
בהשוואה ל-JavaScript, העיבוד של תמונות בגודל זהה כרוך בהרבה עלויות (עדיין צריך לפענח אותן!), אבל בחומרה ממוצעת בנייד יש יותר סיכוי ש-JS ישפיע לרעה על האינטראקטיביות של הדף.
כשאנחנו מדברים על ניתוח והידור שהם איטיים, ההקשר חשוב – מדובר בטלפונים ניידים ממוצעים. למשתמשים ממוצעים יכולים להיות טלפונים עם מעבדים ומעבדי GPU איטיים, ללא מטמון L2/L3 ואולי אפילו מוגבלים בזיכרון.
יכולות הרשת ויכולות המכשיר לא תמיד תואמות. למשתמש עם חיבור סיבים מדהים לא בהכרח יש את המעבד (CPU) הטוב ביותר לניתוח ולהערכה של JavaScript שנשלח למכשיר שלו. זה נכון גם בכיוון ההפוך... חיבור רשת נורא, אבל מעבד (CPU) מהיר במיוחד. — כריסטופר בקסטר, LinkedIn
בהמשך ניתן לראות את העלות של ניתוח של כ-1MB של JavaScript מפוקח (פשוט) בחומרה נמוכה ומתקדם. זמני הניתוח או ההידור של הקוד בין הטלפונים המהירים ביותר בשוק לבין הטלפונים הממוצעים עולים פי 2 עד 5.
מה לגבי אתר בעולם האמיתי, כמו CNN.com?
ב-iPhone 8 המתקדם נדרשות כ-4 שניות כדי לנתח/להדר את ה-JS של CNN בהשוואה לכ-13 שניות בטלפון ממוצע (Moto G4). יכולה להיות לכך השפעה משמעותית על המהירות שבה משתמש יוכל לקיים אינטראקציה מלאה עם האתר.
הדבר מדגיש את חשיבות הבדיקה בחומרה ממוצעת (כמו Moto G4), ולא רק בטלפון שעשוי להימצא בכיס שלכם. ההקשר חשוב עם זאת: ביצוע אופטימיזציה בהתאם לתנאי המכשיר והרשת של המשתמשים.
האם אנחנו באמת שולחים יותר מדי JavaScript? ארר, כנראה :)
באמצעות ארכיון HTTP (כ-500,000 אתרים מובילים) לניתוח המצב של JavaScript בנייד, אנחנו יכולים לראות של-50% מהאתרים צורך יותר מ-14 שניות כדי להתחיל אינטראקטיבי. באתרים האלה אנחנו מקדישים עד 4 שניות לניתוח והידור של JS.
כדאי להביא בחשבון את הזמן שנדרש לאחזור ולעיבוד של JS ומשאבים אחרים, ולא מפתיע שמשתמשים יכולים להמתין זמן מה לפני שמרגישים שהדפים מוכנים לשימוש. אנחנו בהחלט יכולים להשתפר כאן.
הסרת JavaScript לא קריטי מהדפים יכולה לקצר את זמני ההעברה, ניתוח והידור של משאבי המעבד האינטנסיביים, והתקורה הפוטנציאלית של הזיכרון. זה גם עוזר להפוך את הדפים לאינטראקטיביים מהר יותר.
זמן ביצוע
לא מדובר רק בניתוח ובקומפילציה שעשויה להיות להם עלות. הפעלת JavaScript (הפעלת קוד לאחר ניתוח/הידור) היא אחת מהפעולות שצריכות להתרחש ב-thread הראשי. זמני ביצוע ארוכים עלולים גם לעכב את זמן האינטראקציה של משתמש עם האתר.
כשהסקריפט מופעל במשך יותר מ-50 אלפיות השנייה, הזמן עד לפעילות מלאה מתעכב בפרק הזמן כול שלוקח להוריד, להדר ולהפעיל את ה-JS — אלכס ראסל
כדי לפתור את הבעיה, JavaScript מפיק תועלת ממקטעים קטנים ונמנעים מנעילת ה-thread הראשי. נסו לבדוק אם אפשר להפחית את כמות העבודה שמתבצעת במהלך הביצוע.
עלויות אחרות
JavaScript יכול להשפיע על ביצועי הדף בדרכים אחרות:
- זיכרון. יכול להיות שדפים יופיעו במצב jank או בהשהיה לעיתים קרובות בגלל GC (אוסף אשפה). כאשר דפדפן דורש זיכרון, ביצוע ה-JS מושהה כך שדפדפן שאוסף אשפה לעיתים קרובות עלול להשהות את הביצוע בתדירות גבוהה יותר ממה שאנחנו עשויים לאהוב. כדאי להימנע מדליפות זיכרון ומהשהיות תכופות ב-GC כדי לשמור על דפים שאין בהם jank.
- בזמן ריצה, JavaScript עלול לחסום את ה-thread הראשי שגורם לדפים שלא מגיבים. פיצול עבודה לחלקים קטנים יותר (באמצעות
requestAnimationFrame()אוrequestIdleCallback()לתזמון) יכול לצמצם בעיות תגובה, וכך לשפר את Interaction to Next Paint (INP).
תבניות להפחתת העלות של הצגת JavaScript
כשמנסים להשאיר את זמני הניתוח וההידור והשידור של הרשת בשביל JavaScript איטיים, יש דפוסים שיכולים לעזור, כמו צ'ונקינג מבוסס-מסלול או PRPL.
PRPL (PRPL)
PRPL (דחיפה, עיבוד, מטמון מראש, טעינה מדורגת) הוא דפוס שמבצע אופטימיזציה לאינטראקטיביות באמצעות פיצול קוד ושמירה במטמון בצורה אגרסיבית:
בואו נראה את ההשפעה שיכולה להיות לכך.
אנחנו מנתחים את זמן הטעינה של אתרים פופולריים לנייד ואפליקציות אינטרנט מסוג Progressive Web App באמצעות נתונים סטטיסטיים של שיחות בזמן הריצה של V8. כפי שאפשר לראות, זמן הניתוח (מוצג בכתום) הוא חלק משמעותי מהמקום שבו רבים מהאתרים האלה מבלים את זמנם:
ב-Wego, אתר שמשתמש ב-PRPL, מצליח לשמר זמן ניתוח נמוך למסלולים, והמסלול הופך לאינטראקטיבי במהירות רבה. הרבה מהאתרים האחרים שלמעלה משתמשים בפיצול קוד ובתקציבים של ביצועים כדי לנסות להוזיל את העלויות של ה-JS.
אתחול מתקדם (PWA)
אתרים רבים מבצעים אופטימיזציה של חשיפת התוכן לא רק בגלל האינטראקטיביות. על מנת לקבל עיבוד ראשוני במהירות כאשר יש לכם חבילות JavaScript גדולות, לפעמים המפתחים משתמשים ברינדור בצד השרת, ולאחר מכן "משדרגים" אותו כדי לצרף גורמים מטפלים באירועים כשה-JavaScript בסופו של דבר מאוחזר.
חשוב להיזהר – יש לכך עלויות משלה. 1) בדרך כלל, שולחים תגובת HTML גדולה יותר, שיכולה לדחוף את האינטראקטיביות שלנו, 2) להשאיר את המשתמש בעמק מוזר, שבו חצי מהחוויה לא יכולה להיות אינטראקטיבית עד לסיום העיבוד ב-JavaScript.
שימוש ב-Progressive Bootstrapping עשוי להיות גישה טובה יותר. שולחים למטה דף עם פונקציונליות מינימלית (שמורכב רק מ-HTML/JS/CSS שנדרש למסלול הנוכחי). ככל שיותר משאבים יגיעו, האפליקציה תוכל להיטען בהדרגה ולקבל גישה לתכונות נוספות.
טעינת הקוד ביחס למה שמופיע בתצוגה היא הגביע הקדוש. PRPL ו-Progressive Bootstrapping הם דפוסים שיכולים לעזור להשיג זאת.
מסקנות
גודל השידור הוא קריטי לרשתות בסיסיות. זמן הניתוח חשוב למכשירים שקשורים למעבד (CPU). ושומרים על העניינים הנמוכים האלה.
הצוותים הצליחו אימוץ תקציבי ביצועים קפדניים כדי ששידור ה-JavaScript וזמני הניתוח/הידור שלהם נמוכים. קרא את "Can You Afford It?" של אלכס ראסל: התקציבים של הביצועים באינטרנט בעולם האמיתי" להנחיות בנושא תקציבים לנייד.
אם אתם בונים אתר שמטרגט מכשירים ניידים, כדאי שתפתחו את המיטב בחומרה מייצגת, הקפידו שזמני הניתוח וההידור של ה-JavaScript יהיו נמוכים והשתמשו בתקציב ביצועים כדי להבטיח שהצוות יוכל לעקוב אחרי עלויות ה-JavaScript שלהם.
מידע נוסף
- Chrome Dev Summit 2017 – שיטות מומלצות לטעינה מודרנית
- ביצועי ההפעלה של JavaScript
- פתרון משבר הביצועים באינטרנט - נולן לוסון
- האם אתם יכולים להרשות לעצמכם? תקציבי ביצועים בעולם האמיתי — אלכס ראסל
- הערכת מסגרות וספריות באינטרנט — קריסטופר בקסטר
- התוצאות של נסיון של Cloudflare לבצע דחיסה (שימו לב שה-Brotli הדינמי באיכות גבוהה עלול לעכב את העיבוד הראשוני של הדף, לכן חשוב לבדוק אותן בקפידה. עדיף לדחוס באופן סטטי.)
- עתיד ביצועים — סם סאקון