תאריך פרסום: 4 באפריל 2025
כדי לפתור בעיות בביצועים בעולם האמיתי, צריך לגשר על הפער בין סביבת הפיתוח לבין חוויות הביצועים השונות של המשתמשים. בפוסט הזה נציג תכונות חדשות ב-Chrome DevTools שיעזרו לכם לבסס יותר מההחלטות שלכם בנושא ניפוי באגים בביצועים על נתונים אמיתיים, במקום על ניחושים.
כיול הציפיות
החל מגרסה 134 של Chrome, כלי הפיתוח כוללים כיול של ויסות המעבד (CPU) – כלי חדש שמבטל את אי-הוודאות בבחירת רמת ויסות המעבד המתאימה. מריצים את תהליך הכיול פעם אחת, ו-DevTools יפיק עבורכם הגדרות קבועות מראש של ויסות נתונים למכשירים ניידים ברמה נמוכה ובינונית, ספציפיות למכונה שלכם לפיתוח.
אי-התאמה נפוצה בעבודה על ביצועי האתר היא שמפתחים בדרך כלל יוצרים אתרים במחשבים מהירים, בעוד שרבים מהמשתמשים משתמשים במכשירים ניידים פחות מתקדמים. יכול להיות שיהיה קשה לאתר בעיית ביצועים אם היא מתרחשת רק במכשיר עם מעבד איטי בהרבה.
הסטנדרט המוביל הוא ניפוי באגים מרחוק במכשיר נייד אמיתי, אבל כבר כמעט עשור ש-Chrome תומך גם בהאטת מעבד כדי לאפשר מחזורי חזרה מהירים וקלים במהלך הפיתוח.
אבל באיזו רמה של הגבלת מעבד כדאי לבחור? 4x? 20x? איך יודעים איזה פרופיל מתאים ביותר לסוג המכשירים שאתם יודעים שמבקרים באתר? איך המהירות של המכונה שלכם משפיעה על ההחלטה הזו, בין שאתם משתמשים בתחנת עבודה מתקדמת ובין שאתם משתמשים ב-Chromebook בן 8 שנים בדרכים?
תהליך הכיול של ויסות הנתונים
כשהחלונית Performance (ביצועים) נפתחת, בתפריט הנפתח של הגדרות הסביבה מופיעה אפשרות להגדרת רמת הצמצום של המעבד. אם לא ביצעתם את תהליך ההתאמה הקודמת, יופיעו שתי אפשרויות מושבתות בקטע 'הגדרות מוגדרות מראש שהותאמו' בתפריט הנפתח, ואפשרות התאמה… בתחתית המסך.
הבחירה באפשרות הזו תעביר אתכם להגדרות הקבועות מראש של ויסות נתונים (throttle) של מעבד (CPU) בקטע הגדרות (אפשר גם לעבור לשם ישירות).
- לוחצים על הלחצן כיול.
- לוחצים על המשך כשמוצגת אזהרה על כך שהמערכת תעבור זמנית מהדף הנוכחי.
- תתבצע בדיקת ביצועים מהירה כדי למדוד את המהירות של המכונה הנוכחית, והכיול יושלם.
אפשרויות הצמצום יופיעו עכשיו עם ההגדרות המוגדרות מראש שמותאמות למכשירים ברמה נמוכה ובינונית.
שני ההגדרות המוגדרות מראש האלה אמורות להספיק לרוב תרחישי השימוש בפיתוח, ובדרך כלל מומלץ להשתמש בהגדרה המוגדרת מראש 'רמה בינונית' כי היא תואמת למכשיר נייד 'טיפוסי' שמוצג באינטרנט. אם אתם יודעים שלמשתמשים רבים יש מכשירים איטיים יותר, או שבעיות בביצועים מתרחשות בדרך כלל רק אצל המשתמשים האלה, האפשרות 'רמה נמוכה' צריכה להיות איטית מספיק כדי לכלול גם את החלק הארוך של המכשירים ברמה נמוכה.
לבסוף, אם לדעתכם משהו השתבש בתהליך ההתאמה או שהמכונה המקומית השתנתה בצורה כלשהי, תמיד תוכלו לבצע התאמה מחדש באמצעות התפריט הנפתח של הבקרה על קצב העברת הנתונים או בהגדרות. הפעולה הזו תפעיל מחדש את בדיקת הביצועים ותעדכן את ההגדרות המוגדרות מראש.
איך פועל ויסות נתונים במעבד (CPU) ב-DevTools
אם תהיתם איך עובדת הבקרה על קצב העבודה של המעבד (CPU) ב-DevTools, הרעיון הוא פשוט יחסית. כשמפעילים הגבלת קצב העברת נתונים בכרטיסייה, Chrome מפעיל שרשור נפרד של הגבלת קצב העברת נתונים שמפריע ומשהה את השרשור הראשי של הכרטיסייה לפרקי זמן קצרים ותכופים. המטרה היא להשעות את ה-thread הראשי למשך זמן מספיק כדי שהמשך הזמן של כל משימה נתונה יגדל לפי גורם הוויסות.
לדוגמה, אם תבחרו בהגבלת CPU פי 4, השרשור הראשי יושעה כ-75% מהזמן, וכתוצאה מכך השלמת כל פעולה בשרשור הראשי תימשך פי 4 יותר זמן.
היתרון של הגישה הזו הוא שהיא שקופה בעיקר לשאר חלקי Chrome. אין צורך בקוד מיוחד כדי להאט את JavaScript, את הפריסה או כל אחד מהסוגים הרבים האחרים של עבודה שהדפדפן צריך לבצע. כל העבודה בשרשור הראשי נמשכת יותר זמן כי השרשור עצמו רשאי לפעול רק בחלק מהזמן.
כשצמצום המהירות של המעבד פועל כמו מכשיר נייד אמיתי
כתוצאה מכך, ויסות המעבד (CPU) מאפשר לבצע סימולציה טובה של סוגים רבים של משימות במכשירים ניידים שמתבססות על המעבד. לדוגמה, אם אינטראקציה מפעילה JavaScript ופריסה, סביר להניח שהיא תוביל לביצועים דומים לאלה שהיו מתקבלים במכשיר נייד.
נניח שמשימה מופעלת בלחיצה על לחצן, שפועלת JavaScript כדי להוסיף רכיבים חדשים ל-DOM, וכתוצאה מכך הדפדפן צריך להריץ חישובים של סגנון ופריסה כדי למקם את התוכן החדש:
כשמשתמשים בהגדרה המוגדרת מראש של צמצום הביצועים של המעבד 'נייד ברמה בינונית' (3.7x במכונה הזו לפיתוח), האינטראקציה נראית דומה מאוד, אבל משך הזמן גדל באופן משמעותי והמשימה הופכת למשימה ארוכה:
בדיקה של אותה אינטראקציה במכשיר אמיתי ברמה הבינונית באמצעות ניפוי באגים מרחוק מניבה תוצאה דומה להפליא, גם בצורתה וגם במשך הזמן של המעקב אחר האינטראקציה. מכיוון שהמשימה הזו קשורה בעיקר ל-CPU בשרשור הראשי (הפעלת קוד ה-JavaScript של הדף וקוד העיצוב והפריסה של Chrome), הוויסות המכוונן יוצר מחדש בצורה מדויקת את הביצועים האמיתיים בנייד:
מתי כדאי לבדוק את הקוד במכשיר נייד אמיתי
אמנם מדובר בשיטה שימושית מאוד, אבל אי אפשר לדמות באמצעותה את כל ההיבטים של חומרה בנייד. בטלפון, מהירות הדיסק איטית יותר, רוחב הפס של הזיכרון מוגבל יותר ויכול להיות שיצטברו הגבלות תרמו-דינמיות בכל שלב כדי לצמצם את מהירות הביצוע.
מגבלה נפוצה של ויסות נתונים (throttle) היא עבודה שמתבצעת בעיקר על ידי המעבד הגרפי. יש הבדלים ארכיטקטוניים בין מעבדי GPU בניידים לבין מעבדי GPU במחשבים, ו-Chrome מפעיל פעולות של מעבדי GPU בתהליך נפרד מה-thread הראשי של הדף. כתוצאה מכך, צמצום הקצב של מעבד DevTools לא משפיע על תהליך ה-GPU (וזה טוב, כי זה ישפיע על תגובת DevTools עצמו ועל שאר הדפדפן).
ציור, קומפוזיציה וסגנון עם הרבה אפקטים הם בעיות ביצועים נפוצות שעשויות להיראות בסדר במכונה לפיתוח, אבל איטיות באופן בלתי צפוי בנייד. בנוסף, יכול להיות שיהיה קשה להבין שיש בעיה בכלל כשמנסים לשחזר אותה במכונה לפיתוח.
נניח אותה אינטראקציה כמו קודם (לחיצה והוספה של רכיבים רבים ל-DOM), רק שהפעם הרכיבים החדשים מעוצבים עם מספר גדול מדי של מסנני טשטוש וצללי קופסה שמכבידים על המעבד הגרפי.
הצורה והמשך של האינטראקציה בהתחלה דומים, אבל בסוף יש ציור ארוך חדש של חוט ראשי עבור האפקטים שנוספו:
בטלפון אמיתי ברמה בינונית, החלק של האינטראקציה בשרשור הראשי נראה דומה מאוד לחלק המבוסס על סימולציה, כולל הצביעה הנוספת, אבל לאחר מכן נראה שתהליך GPU מטורף מבצע כמות עצומה של עבודה לפני שתוצאת האינטראקציה יכולה להופיע במסך:
העבודה של ה-GPU מאריכה את האינטראקציה ב-300 אלפיות השנייה נוספות, והיא עבודה שבקושי קיימת ב-GPU של המחשב הנייד, גם כשהצמצום של המעבד (בשרשור הראשי) מופעל.
יש גם כמה מקרים אחרים שבהם יש חסרונות משמעותיים להדמיה, כמו טעינת דפים עם יחסי תלות עמוקים, שבהם יש אינטראקציה בין צמצום סיבולת הרשת המדומה, תקשורת בין תהליכים וגישה למטמון הדיסק ולמטמון הזיכרון.
תמיד חשוב לבדוק את האתר במכשירים ניידים אמיתיים בשלב מסוים. אם אתם לא מצליחים ליצור מחדש במעבדה במחשב הנייח בעיה שנתוני השדה מראים שהיא משפיעה על משתמשים בנייד, כדאי מאוד לנסות ניפוי באגים מרחוק במכשיר אמיתי כדי לראות אם יש הבדל שאתם לא רואים.
שיפורים נוספים בניפוי באגים מבוסס-נתונים
לאחרונה הוספנו כמה תכונות חדשות שיעזרו לכם להסתמך על המשתמשים האמיתיים שלכם כשאתם מגדירים את ניפוי הבאגים ומקבלים החלטות.
אם הפעלתם את נתוני השדה, בחלונית ביצועים יוצגו הצעות לגבי הגבלת קצב התעבורה על סמך המשתמשים ב-75% העליונים, כפי שנמדדו בדוח חוויית המשתמש ב-Chrome (CrUX). בתצוגת המדדים בזמן אמת תופיע התראה אם המדדים שנמדדו באופן מקומי שונים מנתוני השדה. הנושא הזה נדון בפירוט בפוסט קודם על הוספת נתונים של מדדי הליבה לבדיקת חוויית המשתמש באתר (Core Web Vitals) מהעולם האמיתי ל-DevTools.
אחת מהתוספות החדשות היא שתובנות בחלונית הביצועים בסרגל הצד יוצגו עכשיו גם אם המדדים שנמדדים בניתוח לא תואמים למה שהמשתמשים חווים בעולם האמיתי.
הפעלת נתוני השדה תאפשר גם להשתמש במדדי הליבה לבדיקת חוויית המשתמש באתר (Core Web Vitals) לפי הרבעון ה-75 כדי לקבוע את הסדר שבו התובנות יוצגו בסרגל הצד. לדוגמה, אם בדרך כלל למשתמשים שלכם יש מהירות גבוהה של הצגת חלק התוכן הכי גדול (LCP) אבל מהירות תגובה נמוכה לאינטראקציה באתר (INP), תובנות שיעזרו לכם לשפר את ה-INP יהיו בדרך כלל בחלק העליון של הרשימה.
ולבסוף, אם אי פעם עברתם בין מספר מעקבים או טעינת מעקבים מהדיסק, יכול להיות שיהיה קשה לזכור בדיוק אילו הגדרות של הדמיה לנייד ושל הגבלת קצב התעבורה השתמשתם בכל מעקב. בתפריט הנפתח לבחירת המעקב, בחלק העליון של החלונית ביצועים, מוצגים עכשיו פרטי ההדמיה של כל מעקב.
עצירה, כיול והאזנה
בסופו של דבר, אנחנו צריכים לבסס את ההחלטות שלנו לניפוי באגים על נתונים מהעולם האמיתי: מתחילים בנתוני שטח מניתוח נתונים ומדוחות של משתמשים כדי למצוא בעיות, ואז יוצרים מחדש את חוויות המשתמשים האלה במעבדה לצורך אבחון. התוספות החדשות האלה ל-DevTools אמורות לעזור לכם לבצע את התהליך הזה בקלות רבה יותר.
אימות של ויסות המעבד והתראות על הבדלים בין נתונים שנאספו בשטח לנתונים שנאספו במעבדה עוזרים לצמצם את אי-הוודאות לגבי הדרך הנכונה, ומאפשרים לקבל הערכה עקבית יותר של הביצועים בעולם האמיתי. DevTools מאפשר לכם להתמקד בפתרון בעיות הביצועים בפועל שמשפיעות על המשתמשים, במקום להשקיע זמן בניחושים לגבי ההגדרות ולהדגיש אי-התאמות פוטנציאליות.
יש לכם רעיונות לשיפורים נוספים או הצעות לתכונות חדשות? חשוב לנו לקבל משוב.