ביצועי זמן ריצה הם הביצועים של הדף שלך בזמן שהוא פועל, בניגוד לביצועים שלו. במדריך הזה מוסבר איך להשתמש בחלונית הביצועים של כלי הפיתוח ל-Chrome כדי לנתח את ביצועי זמן הריצה. מבחינת מודל RAIL, המיומנויות שתלמד במדריך הזה שימושיות לניתוח שלבי התגובה, האנימציה והחוסר פעילות בדף.
אני רוצה לנסות
במדריך הזה פותחים את כלי הפיתוח בדף פעיל ומשתמשים בחלונית הביצועים כדי למצוא צוואר בקבוק בביצועים בדף.
- פותחים את Google Chrome במצב פרטי. המצב הפרטי מבטיח ש-Chrome יפעל במצב נקי. לדוגמה, אם מותקנים אצלכם הרבה תוספים, התוספים האלה עלולים ליצור רעש במדידות הביצועים.
צריך לטעון את הדף הבא בחלון הפרטי. זו ההדגמה שבחרת לעבור לפרופיל. בדף רואים מקבץ של ריבועים כחולים קטנים שנעים למעלה ולמטה.
https://googlechrome.github.io/devtools-samples/jank/
לוחצים על Command+Option+I (Mac) או על Control+Shift+I (Windows, Linux) כדי לפתוח את כלי הפיתוח.
איור 1. ההדגמה בצד שמאל וכלי הפיתוח בצד ימין
הדמיה של מעבד (CPU) נייד
בניידים יש פחות צריכת מעבד (CPU) ממחשבים שולחניים ומחשבים ניידים. בכל פעם שיוצרים פרופיל לדף, אפשר להשתמש בתכונה 'ויסות נתונים (CPU)' כדי לדמות את ביצועי הדף במכשירים ניידים.
- בכלי הפיתוח, לוחצים על הכרטיסייה ביצועים.
- מוודאים שתיבת הסימון צילומי מסך מופעלת.
- לוחצים על Capture Settings (הגדרות הצילום) . כלי הפיתוח חושף הגדרות שקשורות לאופן שבו הוא מתעד את מדדי הביצועים.
בשביל CPU, בוחרים באפשרות איטית פי 2. כלי הפיתוח מווסתים את המעבד (CPU), כך שהוא איטי פי 2 מהרגיל.
איור 2. ויסות נתונים של המעבד (CPU), מודגש בכחול
הגדרת ההדגמה
קשה ליצור הדגמה של ביצועים בסביבת זמן ריצה שמתאימה באופן עקבי לכל הקוראים באתר. בקטע הזה תוכלו להתאים אישית את ההדגמה כדי לוודא שהחוויה שלכם תואמת יחסית לצילומי המסך ולתיאורים במדריך הזה, בלי קשר להגדרה הספציפית שלכם.
- ממשיכים ללחוץ על הוספה 10 עד שהריבועים הכחולים זזים לאט יותר באופן משמעותי מבעבר. במחשב מתקדם, התהליך עשוי להימשך כ-20 קליקים.
לוחצים על אופטימיזציה. הריבועים הכחולים אמורים לנוע מהר יותר ובצורה חלקה יותר.
לוחצים על ביטול האופטימיזציה. הריבועים הכחולים זזים לאט יותר ועוד בזריזות.
תיעוד של ביצועי זמן ריצה
כשמריצים את הגרסה שעברה אופטימיזציה של הדף, הריבועים הכחולים זזים מהר יותר. למה זה קורה? שתי הגרסאות אמורות להעביר כל ריבוע באותה כמות של שטח באותו פרק זמן. מומלץ לצלם את הנתונים בחלונית הביצועים כדי ללמוד איך לזהות את צוואר בקבוק בביצועים בגרסה שלא עברה אופטימיזציה.
בכלי הפיתוח, לוחצים על Record . כלי הפיתוח מתעדים את מדדי הביצועים בזמן שהדף פועל.
איור 3: יצירת פרופילים לדף
ממתינים כמה שניות.
לוחצים על הפסקה. כלי הפיתוח מפסיקים לתעד, מעבדים את הנתונים ומציגים את התוצאות בחלונית 'ביצועים'.
איור 4: תוצאות הפרופיל
וואו, זו כמות עצומה של נתונים. אל דאגה, הכול ייראה יותר הגיוני בקרוב.
ניתוח התוצאות
אחרי שיוצרים תיעוד של ביצועי הדף, אפשר למדוד את הביצועים שלו ולאתר את הגורמים לכך.
ניתוח פריימים לשנייה
המדד העיקרי למדידת ביצועים של אנימציה הוא פריימים לשנייה (FPS). המשתמשים מרוצים כשהאנימציה פועלת בקצב של 60FPS.
מעיינים בתרשים ה-FPS. אם מופיע פס אדום מעל FPS, זה אומר שקצב הפריימים ירד כל כך נמוך עד שהוא כנראה פגע בחוויית המשתמש. באופן כללי, ככל שהפס הירוק גבוה יותר, כך ה-FPS גבוה יותר.
איור 5: תרשים ה-FPS, בקווים כחולים
מתחת לתרשים FPS יופיע התרשים CPU. הצבעים בתרשים CPU תואמים לצבעים בכרטיסייה Summary (סיכום) בחלק התחתון של חלונית הביצועים. זה שהתרשים CPU מלא בצבע, סימן שהמעבד (CPU) נגמר במהלך ההקלטה. כשרואים שהמעבד (CPU) מתמלא לפרקי זמן ארוכים, זהו סימן למצוא דרכים להספיק פחות עבודה.
איור 6: תרשים המעבד (CPU) והכרטיסייה 'סיכום', מסומנים בכחול
מעבירים את העכבר מעל התרשימים FPS, CPU או NET. כלי הפיתוח מציג צילום מסך של הדף בנקודת זמן מסוימת. מזיזים את העכבר שמאלה וימינה כדי להפעיל מחדש את ההקלטה. הוא נקרא 'ניקוי', והוא שימושי לניתוח ידני של ההתקדמות של אנימציות.
איור 7: הצגת צילום מסך של הדף סביב סימן 2,000 אלפיות השנייה של ההקלטה
בקטע מסגרות, מעבירים את העכבר מעל אחד הריבועים הירוקים. בכלי הפיתוח מוצגים ה-FPS של המסגרת הספציפית. כל פריים צפוי להיות הרבה פחות מיעד של 60 FPS.
איור 8: העברת העכבר מעל מסגרת
כמובן שבעזרת ההדגמה הזו אפשר לראות שהביצועים של הדף לא טובים. אבל בתרחישים אמיתיים זה לא כל כך ברור, לכן כדאי להיעזר בכל הכלים האלה לביצוע מדידות.
בונוס: פתיחת מד ה-FPS
כלי שימושי נוסף הוא מד ה-FPS, שמספק הערכות בזמן אמת ל-FPS בזמן שהדף פועל.
- לוחצים על Command+Shift+P (Mac) או על Control+Shift+P (Windows, Linux) כדי לפתוח את תפריט הפקודות.
- מתחילים להקליד
Rendering
בתפריט הפקודות ובוחרים באפשרות הצגת עיבוד. בכרטיסייה רינדור מפעילים את התכונה FPS Meter. בפינה השמאלית העליונה של אזור התצוגה מופיעה שכבת-על חדשה.
איור 9: מד FPS
משביתים את מד FPS ומקישים על Escape כדי לסגור את הכרטיסייה רינדור. לא תשתמשו בו במדריך הזה.
איתור צוואר הבקבוק
עכשיו, אחרי שבדקתם ווידאתם שהאנימציה לא משיגה ביצועים טובים, עליכם לענות על השאלה הבאה: למה?
שימו לב לכרטיסיית הסיכום. כאשר לא נבחרו אירועים, כרטיסייה זו מציגה פירוט של הפעילות. הדף הקדיש את רוב הזמן לעיבוד. מכיוון שביצועים הם האמנות של פחות עבודה, המטרה שלכם היא להפחית את משך הזמן הנדרש לביצוע רינדור.
איור 10: הכרטיסייה 'סיכום', מסומנת בכחול
מרחיבים את הקטע ראשי. בכלי הפיתוח מופיע תרשים להבות של הפעילות ב-thread הראשי לאורך זמן. ציר ה-X מייצג את ההקלטה לאורך זמן. כל עמודה מייצגת אירוע. ככל שהעמודה תהיה רחבה יותר, פירוש הדבר הוא שהאירוע נמשך זמן רב יותר. ציר ה-Y מייצג את מקבץ השיחות. כאשר רואים אירועים מקובצים זה על גבי זה, המשמעות היא שהאירועים העליונים גרמו לאירועים הנמוכים יותר.
איור 11: הקטע הראשי, מסומן בכחול
יש הרבה נתונים בהקלטה. כדי להגדיל את התצוגה של אירוע יחיד מסוג Animation Frame Fired, לוחצים, מחזיקים וגוררים את העכבר מעל Overview, הקטע שכולל את התרשימים FPS , CPU ו-NET. החלק Main והכרטיסייה Summary מציגים מידע רק עבור החלק הנבחר של התיעוד.
איור 12: התקרבות לאירוע יחיד שמופעלת בו אנימציה של פריים אנימציה
רושמים או זוכרים את המשולש האדום בפינה השמאלית העליונה של האירוע Animation Frame Fired. בכל פעם שמופיע משולש אדום, זוהי אזהרה שייתכן שיש בעיה שקשורה לאירוע הזה.
לוחצים על האירוע אנימציה הופעלה מסגרת. בכרטיסייה Summary מוצג מידע על האירוע הזה. מעיינים בקישור לחשיפה. לחיצה שגורמת לכלי הפיתוח להדגיש את האירוע שהפעיל את האירוע Animation Frame Fired. חשוב גם לשים לב לקישור app.js:94. לחיצה שמעבירה אתכם לשורה הרלוונטית בקוד המקור.
איור 13: מידע נוסף על האירוע Animation Frame Fired
מתחת לאירוע app.update יש כמה אירועים סגולים. אם הן היו רחבות יותר, נראה שלכל אחת מהן יש משולש אדום. לחצו על אחד מאירועי Layout סגולים. כלי הפיתוח מספקים מידע נוסף על האירוע בכרטיסייה סיכום. אכן, יש אזהרה לגבי זרימות מחדש מאולצות (מילה נוספת עבור פריסה).
בכרטיסייה סיכום, לוחצים על הקישור app.js:70 בקטע הפריסה מאולצת. כלי הפיתוח מעביר אתכם לשורת הקוד שמאלצת את הפריסה.
איור 13: שורת הקוד שגרמה לפריסה הכפויה
סוף סוף! היה הרבה לקחת בחשבון, אבל עכשיו יש לכם בסיס איתן בתהליך העבודה הבסיסי לניתוח ביצועים בסביבת זמן ריצה. כל הכבוד.
בונוס: ניתוח הגרסה שעברה אופטימיזציה
בעזרת תהליכי העבודה והכלים שלמדתם עכשיו, לוחצים על Optimize בהדגמה כדי להפעיל את הקוד שעבר אופטימיזציה, לתעד את הביצועים שוב ולנתח את התוצאות. מקצב הפריימים המשופר ועד הפחתת האירועים בתרשים הלהבות של החלק הראשי, אפשר לראות שהגרסה המשופרת של האפליקציה מניבה הרבה פחות עבודה וביצועים טובים יותר.
השלבים הבאים
הבסיס להבנת הביצועים הוא מודל ה-RAIL. המודל הזה מלמד את מדדי הביצועים החשובים ביותר למשתמשים. מידע נוסף מופיע בקטע מדידת הביצועים באמצעות מודל ה-RAIL.
כדי להתרגל לחלונית הביצועים, התרגול הוא מושלם. נסו ליצור פרופילים משלכם
ונתחו את התוצאות. אם יש לכם שאלות לגבי התוצאות, פתחו שאלה בנושא Stack Overflow שמתויגת עם google-chrome-devtools
. אם אפשר, הוסיפו צילומי מסך או קישורים לדפים שניתן לשחזר.
כדי למומחה בביצועים של סביבת זמן ריצה, צריך ללמוד איך הדפדפן מתרגם HTML, CSS ו-JS לפיקסלים על המסך. מומלץ להתחיל במאמר סקירה כללית על ביצועי הרינדור. המאמר האנטומיה של מסגרת כולל פירוט מעמיק יותר.
לבסוף, יש דרכים רבות לשפר את הביצועים בזמן הריצה. המדריך הזה התמקד בצוואר בקבוק מסוים באנימציה, כדי לספק לכם סיור ממוקד בחלונית הביצועים, אבל זהו רק צוואר בקבוק אחד מתוך רבים. בשאר הסדרה של ביצועי הרינדור יש הרבה טיפים טובים לשיפור היבטים שונים של ביצועי סביבת זמן ריצה, למשל: