ב-Chrome 102 תופיע חלונית ניסיונית חדשה, Performance Insights, בכלי הפיתוח. בפוסט הזה נסביר למה אנחנו עובדים על חלונית חדשה, וגם נתאר את האתגרים הטכניים שעמדו בפנינו ואת ההחלטות שקיבלנו במהלך העבודה.
למה כדאי ליצור עוד לוח?
(אם עדיין לא ראיתם, פרסמנו סרטון שמסביר למה אנחנו יוצרים את החלונית 'תובנות לגבי ביצועים' ואיך אפשר לקבל בעזרתה תובנות מעשיות לגבי ביצועי האתר).
חלונית הביצועים הקיימת היא מקור מידע מצוין אם רוצים לראות את כל הנתונים של האתר במקום אחד, אבל הרגשנו שהיא עמוסה מדי. אם אתם לא מומחים לביצועים, קשה לדעת בדיוק מה לחפש ואילו חלקים בהקלטה רלוונטיים.
ב-Insights Panel עדיין אפשר לראות ציר זמן של ה-trace ולבדוק את הנתונים, אבל אפשר גם לקבל רשימה שימושית של מה ש-DevTools מחשיב כ'תובנות' עיקריות שכדאי לבדוק. התובנות יזהו בעיות כמו בקשות שחוסמות את העיבוד, שינויים בפריסה ומשימות ארוכות, ובעיות נוספות שיכולות להשפיע לרעה על ביצועי טעינת הדפים באתר, ובמיוחד על הציונים של מדדי הליבה של חוויית האינטרנט (CWV) באתר. בנוסף לסימון הבעיות, הכלי 'תובנות לגבי ביצועים' יספק לכם הצעות פרקטיות לשיפור הציונים של מדדי ה-CWV, וקישורים למקורות מידע ולמסמכים נוספים.
החלונית הזו היא ניסיונית ונשמח לקבל מכם משוב. אם נתקלתם בבאגים או שיש לכם בקשות להוספת תכונות שלדעתכם יעזרו לכם לשפר את ביצועי האתר, אתם מוזמנים לעדכן אותנו.
איך פיתחנו את התובנות לגבי הביצועים
בדומה לשאר כלי DevTools, בנינו את Performance Insights ב-TypeScript והשתמשנו ברכיבי אינטרנט, שמבוססים על lit-html, כדי לבנות את ממשק המשתמש. ההבדל בין Performance Insights לבין כלי אחר הוא שממשק המשתמש הראשי הוא רכיב HTML canvas, וציר הזמן מצויר על האזור הזה. חלק גדול מהמורכבות נובע מניהול הקנבס הזה: לא רק ציור הפרטים הנכונים במקום הנכון, אלא גם ניהול אירועי העכבר (לדוגמה: איפה המשתמש לחץ על הקנבס? האם הם לחצו על אירוע שציירנו?) ולוודא שאנחנו מעבדים מחדש את בד הציור בצורה יעילה.
כמה טראקים בלוח ציור אחד
באתר מסוים, יש כמה 'מסלולים' שאנחנו רוצים להציג, וכל אחד מהם מייצג קטגוריה שונה של נתונים. לדוגמה, בחלונית התובנות יוצגו כברירת מחדל שלושה נתונים:
אנחנו גם נמשיך להוסיף תכונות לחלונית, ולכן אנחנו מצפים שיתווספו עוד טראקים.
המחשבה הראשונית שלנו הייתה שכל אחד מהטרקים האלה יעבד את ה-<canvas> שלו, כך שהתצוגה הראשית תהפוך למספר רכיבי canvas שמוערמים אנכית. הגישה הזו הייתה מפשטת את העיבוד ברמת הטראק, כי כל טראק היה יכול לעבור עיבוד בנפרד ולא הייתה סכנה שעיבוד של טראק יתבצע מחוץ לגבולות שלו. אבל לגישה הזו יש שתי בעיות עיקריות:
עלות העיבוד (או העיבוד מחדש) של רכיבי canvas גבוהה. שימוש בכמה רכיבי canvas יקר יותר משימוש ברכיב canvas אחד, גם אם הוא גדול יותר.
הצגת שכבות-על שמופיעות בכמה רצועות (לדוגמה, קווים אנכיים לסימון אירועים כמו זמן FCP) הופכת למורכבת: אנחנו צריכים להציג אותן בכמה קנבסים ולוודא שהן מוצגות יחד ומיושרות בצורה נכונה.
השימוש ב-canvas אחד לכל ממשק המשתמש דרש מאיתנו להבין איך לוודא שכל טראק יעבור רינדור בקואורדינטות הנכונות ולא יחרוג לטראק אחר. לדוגמה, אם גובה של רצועה מסוימת הוא 100px, אנחנו לא יכולים לאפשר הצגה של רכיב בגובה 120px שחורג מהרצועה ופולש לרצועה שמתחתיה. כדי לפתור את הבעיה, אפשר להשתמש ב-clip. לפני שאנחנו מעבדים כל טראק, אנחנו מציירים מלבן שמייצג את חלון הטראק הגלוי. כך מובטח שכל הנתיבים שיימשכו מחוץ לגבולות האלה ייחתכו על ידי אזור הציור.
canvasContext.beginPath();
canvasContext.rect(
trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();
בנוסף, לא רצינו שכל רכיב של טראק יצטרך לדעת את המיקום שלו בציר האנכי: כל רכיב של טראק צריך לבצע רינדור כאילו הוא מרונדר במיקום (0, 0), ויש לנו רכיב ברמה גבוהה יותר (שנקרא TrackManager) שמנהל את המיקום הכולל של הטראק. אפשר לעשות את זה באמצעות translate, שמתרגם את אזור הציור לפי מיקום נתון (x, y). לדוגמה:
canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide
למרות שrect הגדרת הקוד 0, 0 היא המיקום, התרגום הכולל שמוחל יגרום לריבוע להיות מוצג במיקום 0, 10. כך אנחנו יכולים לעבוד על בסיס טראק כאילו אנחנו מבצעים רינדור ב-(0, 0), ולגרום למנהל הטראקים לתרגם בזמן הרינדור של כל טראק כדי לוודא שכל טראק מרונדר בצורה נכונה מתחת לטראק הקודם.
אזורי עריכה מחוץ למסך לרצועות ולרגעים מרכזיים
הרינדור של Canvas יקר יחסית, ואנחנו רוצים לוודא שהחלונית 'תובנות' תישאר חלקה ותגיב במהירות בזמן העבודה איתה. לפעמים אי אפשר להימנע מרינדור מחדש של כל אזור העריכה. לדוגמה, אם משנים את רמת הזום, צריך להתחיל מחדש ולרנדר הכול. העיבוד מחדש של Canvas הוא יקר במיוחד כי אי אפשר לעבד מחדש רק חלק קטן ממנו, צריך למחוק את כל ה-Canvas ולצייר מחדש. זה שונה מרינדור מחדש של DOM, שבו כלים יכולים לחשב את העבודה המינימלית הנדרשת ולא להסיר הכול ולהתחיל מחדש.
אחת הבעיות הוויזואליות שנתקלנו בהן הייתה סימון. כשמעבירים את העכבר מעל מדדים בחלונית, הם מודגשים בציר הזמן. באופן דומה, אם מעבירים את העכבר מעל תובנה לגבי אירוע מסוים, מסגרת כחולה מצוירת סביב האירוע הזה.
התכונה הזו הוטמעה לראשונה על ידי זיהוי תנועת עכבר מעל אלמנט שמפעיל הדגשה, ולאחר מכן ציור ההדגשה ישירות על אזור הציור הראשי. הבעיה שלנו מתרחשת כשאנחנו צריכים להסיר את ההדגשה: האפשרות היחידה היא לצייר מחדש את הכול. אי אפשר לצייר מחדש רק את האזור שבו היה הסימון (ללא שינויים ארכיטקטוניים גדולים), אבל לצייר מחדש את כל האזור רק כדי להסיר גבול כחול סביב פריט אחד נראה לנו מוגזם. בנוסף, אם העברתם את העכבר במהירות מעל פריטים שונים כדי להפעיל כמה הדגשות ברצף מהיר, הייתה השהיה ויזואלית.
כדי לפתור את הבעיה הזו, חילקנו את ממשק המשתמש לשני אזורי ציור מחוץ למסך: אזור הציור 'הראשי', שבו מתבצע רינדור של הרצועות, ואזור הציור 'הקטעים המובלטים', שבו מצוירים הקטעים המובלטים. לאחר מכן אנחנו מעתיקים את הקנבסים האלה לקנבס אחד שמוצג למשתמש במסך. אפשר להשתמש בשיטה drawImage בהקשר של canvas, שיכול לקבל canvas אחר כמקור.
המשמעות היא שהסרת הדגשה לא גורמת לציור מחדש של אזור העריכה הראשי: במקום זאת, אנחנו יכולים לנקות את אזור העריכה שמוצג במסך, ואז להעתיק את אזור העריכה הראשי לאזור העריכה שמוצג. העתקה של אזור ציור היא פעולה זולה, אבל הציור עצמו הוא יקר. לכן, אם מעבירים את ההדגשות לאזור ציור נפרד, נמנעים מהעלות הזו כשמפעילים ומכבים את ההדגשות.
ניתוח מקיף של נתוני מעקב שנבדקו
אחד היתרונות של בניית תכונה חדשה מאפס הוא שאפשר לחשוב על הבחירות הטכניות שנעשו בעבר ולבצע שיפורים. אחד הדברים שרצינו לשפר היה פיצול הקוד לשני חלקים נפרדים כמעט לחלוטין:
מנתחים את קובץ המעקב ומחלצים את הנתונים הנדרשים. עיבוד של קבוצת טראקים.
ההפרדה בין הניתוח (חלק 1) לבין העבודה על ממשק המשתמש (חלק 2) אפשרה לנו לבנות מערכת ניתוח מוצקה. כל מעקב מועבר דרך סדרה של Handlers שאחראים על היבטים שונים: LayoutShiftHandler מחשב את כל המידע שדרוש לנו לגבי שינויים בפריסה, ו-NetworkRequestsHandler מטפל באופן בלעדי בשליפת בקשות רשת. היתרון הנוסף של שלב הניתוח המפורש הזה, שבו יש לנו מטפלים שונים שאחראים לחלקים שונים של המעקב, הוא שניתן להתמקד בבעיה אחת בכל פעם, כי ניתוח המעקב יכול להיות מסובך מאוד.
בנוסף, הצלחנו לבדוק באופן מקיף את ניתוח העקבות שלנו על ידי הקלטות בכלי הפיתוח, שמירה שלהן וטעינה שלהן כחלק מחבילת הבדיקה שלנו. זה מצוין כי אנחנו יכולים לבדוק עם עקבות אמיתיות, ולא ליצור כמויות עצומות של נתוני עקבות מזויפים שעלולים להתיישן.
בדיקת צילומי מסך לממשק משתמש של קנבס
בנושא הבדיקות, אנחנו בדרך כלל בודקים את רכיבי ה-frontend על ידי עיבוד שלהם בדפדפן ומוודאים שהם פועלים כמצופה. אנחנו יכולים לשלוח אירועי קליק כדי להפעיל עדכונים, ולוודא שרכיבי ה-DOM שהרכיבים יוצרים תקינים. הגישה הזו עובדת טוב בשבילנו, אבל היא לא מתאימה כשמדובר ברינדור לקנבס. אין דרך לבדוק קנבס ולקבוע מה מצויר בו. לכן, הגישה הרגילה שלנו של עיבוד ואז שליחת שאילתה לא מתאימה.
כדי שנוכל לבדוק את הכיסוי, עברנו לבדיקות של צילומי מסך. כל בדיקה מפעילה קנבס, מעבדת את הטראק שאנחנו רוצים לבדוק ואז מצלמת מסך של רכיב הקנבס. צילום המסך הזה נשמר בבסיס הקוד שלנו, ובריצות בדיקה עתידיות יבוצע השוואה בין צילום המסך השמור לבין צילום המסך שנוצר. אם צילומי המסך שונים, הבדיקה תיכשל. אנחנו גם מספקים דגל להפעלת הבדיקה ולאילוץ עדכון של צילום המסך, במקרים שבהם שינינו בכוונה את העיבוד הגרפי וצריך לעדכן את הבדיקה.
בדיקות צילומי מסך הן לא מושלמות וקצת גסות. אפשר לבדוק רק שהרכיב כולו מוצג כמו שצריך, ולא טענות ספציפיות יותר. בהתחלה השתמשנו בהן יותר מדי כדי לוודא שכל רכיב (HTML או canvas) מוצג בצורה נכונה. הדבר הזה האט את חבילת הבדיקות שלנו באופן משמעותי, והוביל לבעיות שבהן שינויים קטנים בממשק המשתמש (כמו שינויי צבע עדינים או הוספת שוליים בין פריטים) גרמו לכך שצילומי מסך רבים נכשלו ונדרש עדכון שלהם. היום אנחנו משתמשים בצילומי מסך רק לרכיבים שמבוססים על בד ציור, והאיזון הזה עובד בשבילנו טוב מאוד.
סיכום
הייתה לנו חוויה מהנה ומלמדת מאוד בצוות במהלך בניית החלונית החדשה 'תובנות לגבי הביצועים'. למדנו הרבה על קובצי מעקב, על עבודה עם בד ציור ועוד. אנחנו מקווים שתיהנו מהשימוש בחלונית החדשה, ונשמח לקבל מכם משוב.
מידע נוסף על חלונית התובנות לגבי הביצועים זמין במאמר תובנות לגבי הביצועים: קבלת תובנות מעשיות לגבי הביצועים של האתר.
הורדת ערוצי התצוגה המקדימה
מומלץ להשתמש ב-Chrome Canary, Dev או Beta כדפדפן ברירת המחדל לפיתוח. ערוצי התצוגה המקדימה האלה מאפשרים לכם לגשת לתכונות העדכניות ביותר של DevTools, לבדוק ממשקי API מתקדמים של פלטפורמות אינטרנט ולמצוא בעיות באתר לפני שהמשתמשים שלכם ייתקלו בהן.
יצירת קשר עם הצוות של כלי הפיתוח ל-Chrome
אתם יכולים להשתמש באפשרויות הבאות כדי לדון בתכונות החדשות, בעדכונים או בכל דבר אחר שקשור לכלי הפיתוח.
- אתם מוזמנים לשלוח לנו משוב ובקשות להוספת תכונות בכתובת crbug.com.
- אפשר לדווח על בעיה בכלי פיתוח באמצעות הסמל אפשרויות נוספות > עזרה > דיווח על בעיה בכלי פיתוח בכלי הפיתוח.
- שולחים ציוץ אל @ChromeDevTools.
- אפשר להשאיר תגובות בסרטונים What's new in DevTools YouTube videos או DevTools Tips YouTube videos.