אחרי כמה שניות, מחפשים קריאה לרשת אל firebaselogging.googleapis.com בכלים למפתחים בדפדפן. אם הקריאה הזו קיימת, סימן שהדפדפן שולח נתוני ביצועים ל-Firebase.
אם אתם מתחילים להשתמש ב-Performance Monitoring (iOS+ | Android | אינטרנט), הטיפים הבאים לפתרון בעיות יכולים לעזור לכם לפתור בעיות שקשורות לזיהוי ה-SDK על ידי Firebase או להצגת נתוני הביצועים הראשונים במסוף Firebase.
הוספתי את ה-SDK לאפליקציה, אבל במסוף עדיין כתוב שצריך להוסיף את ה-SDK
מערכת Firebase יכולה לזהות אם הוספתם בהצלחה את ה-SDK של Performance Monitoring לאפליקציה כשהיא מקבלת מידע על אירועים (כמו אינטראקציות עם האפליקציה) מהאפליקציה. בדרך כלל, בתוך 10 דקות מהפעלת האפליקציה, מרכז הבקרה של Performance במסוף Firebase מציג את ההודעה "SDK detected" (זוהה SDK). אחרי 30 דקות, הנתונים הראשוניים שעובדו יוצגו במרכז הבקרה.
אם עברו יותר מ-10 דקות מאז שהוספתם את הגרסה העדכנית של ה-SDK לאפליקציה, ועדיין לא רואים שינוי, בדקו את הודעות היומן כדי לוודא ש-Performance Monitoring מתעד אירועים. כדי לפתור בעיה שקשורה להודעה על עיכוב בזיהוי ה-SDK, נסו את השלבים המתאימים לפתרון בעיות שמתוארים בהמשך.
האפליקציה מתעדת אירועים: שלבים לפתרון בעיות
אם אתם עדיין מפתחים באופן מקומי, נסו ליצור עוד אירועים לאיסוף נתונים:
מציגים את אפליקציית האינטרנט בסביבה מקומית.
כדי ליצור אירועים, טוענים דפי משנה באתר, מבצעים אינטראקציות עם האפליקציה או מפעילים בקשות לאחזור מהרשת. חשוב להשאיר את הכרטיסייה בדפדפן פתוחה למשך 10 שניות לפחות אחרי טעינת הדף.
מזהה האפליקציה ב-Firebase (appId) באובייקט התצורה מתאים לאפליקציה. מזהה האפליקציה ב-Firebase מופיע בכרטיס Your apps בקטע settingsProject settings.
אם נראה שמשהו לא תקין באובייקט ההגדרות האישיות באפליקציה, נסו את הפעולות הבאות:
מוחקים את אובייקט ההגדרות האישיות שקיים כרגע באפליקציה.
כדי לקבל אובייקט הגדרות אישיות חדש ולהוסיף אותו לאפליקציית האינטרנט, פועלים לפי ההוראות האלה.
אם ערכת ה-SDK מתעדת אירועים ונראה שהכול מוגדר כמו שצריך, אבל עדיין לא מופיעה ההודעה על זיהוי ה-SDK או נתונים מעובדים (אחרי שעתיים), פנו לתמיכה של Firebase.
האפליקציה לא מתעדת אירועים:
שלבים לפתרון בעיות
מוודאים שערכת ה-SDK של Performance Monitoringהופעלה כמו שצריך באפליקציה.
חשוב לוודא ש-SDK של Performance Monitoringלא מושבת באמצעות הדגל הבא:
performance.instrumentationEnabled
חשוב לוודא שהשמירה במטמון הדפדפן מושבתת, אחרת יכול להיות שהדפדפן לא יזהה הגדרות חדשות של כלי מדידה.
סוגרים את הכרטיסייה של דף האינטרנט ופותחים אותה מחדש. בודקים שוב אם יש רישום ביומן.
אם הוספתם לאחרונה את ה-SDK של Performance Monitoring לאפליקציה, יכול להיות שתצטרכו להפעיל מחדש את האפליקציה כדי שה-SDK יתחיל לפעול.
אם הוספתם את ה-SDK בהצלחה ואתם משתמשים ב-Performance Monitoring באפליקציה, הטיפים הבאים לפתרון בעיות יכולים לעזור לכם לפתור בעיות כלליות שקשורות לתכונות ולכלים של Performance Monitoring.
מוודאים שהמשתמש יוצר אינטראקציה עם הדף תוך 5 שניות מהטעינה.
Performance Monitoring מתעד את ה-FID רק במהלך החלון הזה.
בלוח בקרה לביצועי הענן חסרים נתוני מעקב בהתאמה אישית
האם אתם רואים נתוני ביצועים של מעקבים שנאספו באופן אוטומטי אבל לא של מעקבים של קוד בהתאמה אישית? נסו את השלבים הבאים לפתרון בעיות:
בודקים את ההגדרה של מעקבי קוד בהתאמה אישית שנוצרו באמצעות Trace API, ובמיוחד את הדברים הבאים:
השמות של מעקבי קוד בהתאמה אישית ושל מדדים בהתאמה אישית חייבים לעמוד בדרישות הבאות: בלי רווחים לבנים בתחילת השם או בסופו, בלי קו תחתון (_) בתחילת השם, ואורך מקסימלי של 32 תווים.
צריך להפעיל ולהפסיק את כל המעקבים. כל מעקב שלא התחיל, לא הופסק או הופסק לפני שהתחיל לא יתועד ביומן.
שימו לב שאם אתם משתמשים בשיטה record(), אתם לא צריכים להתחיל או להפסיק את המעקב באופן מפורש.
הדגל הזה שולט באיסוף הנתונים של מעקבי קוד בהתאמה אישית בלבד (לא כל הנתונים).
בודקים את הודעות היומן כדי לוודא ש-Performance Monitoring מתעד את העקבות הצפויים של הקוד בהתאמה אישית.
אם Performance Monitoring מתעד אירועים, אבל לא מוצגים נתונים אחרי 24 שעות, פנו לתמיכה של Firebase.
לוח בקרה לביצועי הענן חסרים נתונים של בקשות לאחזור מהרשת
אם חסרים נתונים של בקשות לאחזור מהרשת, חשוב לדעת:
Performance Monitoring אוסף באופן אוטומטי מדדים של בקשות לאחזור מהרשת שמדווחות על ידי ה-API של הדפדפן. הדוחות האלה לא כוללים בקשות לאחזור מהרשת שנכשלו.
בהתאם להתנהגות של הקוד ושל ספריות הרשת שבהן הקוד משתמש, יכול להיות ש-Performance Monitoring ידווח רק על בקשות לאחזור מהרשת שהושלמו.
כלומר, יכול להיות שחיבורי HTTP/S שיישארו פתוחים לא ידווחו.
לאן נעלם הקטע "הבעיות המובילות" בכרטיס "ביצועים" בדף הבית של הפרויקט?
החלפנו את הבעיות המובילות בהתראות אחרונות, כהמשך להשקה האחרונה של ההתראות, שמודיעות לכם באופן אוטומטי כשמתרחשת חריגה מהספים שהגדרתם. הוצאנו משימוש את הבעיות והחלפנו אותן בהתראות.
בורר האפליקציות שבחלק העליון של הכרטיס "ביצועים" מסנן את ההתראות שמופיעות בקטע התראות אחרונות. מוצגות רק שלוש ההתראות האחרונות של האפליקציות שנבחרו.
ב-Performance Monitoring אפשר להגדיר התראות למדדים שחורגים מסף מסוים. כדי למנוע בלבול עם הספים האלה שניתנים להגדרה למדדי ביצועים, הסרנו את האפשרות להגדיר ספים לבעיות.
מה קרה למידע בקטעים "פרטים" ו"מדדים" במסוף Firebase?
החלפנו את הדפים "פרטים" ו"מדדים" בממשק משתמש (UI) חדש ומרוכז, כדי שיהיה לכם קל יותר לפתור בעיות. ממשק המשתמש החדש לפתרון בעיות מציע את אותה פונקציונליות בסיסית שהציעו Details ו-Metrics. למידע נוסף על פתרון בעיות, ראו הצגת נתונים נוספים של מעקב ספציפי.
למה מספר הדגימות שונה ממה שציפיתי?
Performance Monitoring אוסף נתוני ביצועים ממכשירי המשתמשים של האפליקציה. אם לאפליקציה יש הרבה משתמשים או אם היא מייצרת כמות גדולה של פעילות ביצועים, יכול להיות ש-Performance Monitoring יגביל את איסוף הנתונים לקבוצת משנה של מכשירים כדי לצמצם את מספר האירועים המעובדים. המגבלות האלה גבוהות מספיק כדי שגם אם יש פחות אירועים, ערכי המדדים עדיין ייצגו את חוויית השימוש באפליקציה של המשתמשים.
כדי לנהל את נפח הנתונים שאנחנו אוספים, ב-Performance Monitoring משתמשים באפשרויות הדגימה הבאות:
הגבלת קצב של יצירת בקשות במכשיר: כדי למנוע ממכשיר לשלוח פרצי יומני מעקב פתאומיים, אנחנו מגבילים את מספר יומני המעקב של הקוד ויומני המעקב של בקשות לאחזור מהרשת שנשלחים ממכשיר ל-300 אירועים בכל 10 דקות. הגישה הזו מגינה על המכשיר מפני מכשור בלולאה שיכול לשלוח כמויות גדולות של נתוני ביצועים, ומונעת ממכשיר אחד להטות את מדידות הביצועים.
דגימה דינמית: Performance Monitoring אוסף מספר מוגבל של יומני מעקב של קוד ויומני מעקב של בקשות לאחזור מהרשת לכל אפליקציה מדי יום, מכל משתמשי האפליקציה. תדירות דגימה דינמית נשלפת במכשירים (באמצעות Firebase Remote Config) כדי לקבוע אם מכשיר אקראי צריך לתעד ולשלוח נתוני מעקב. מכשיר שלא נבחר לדגימה לא שולח אירועים. תדירות הדגימה הדינמית היא ספציפית לאפליקציה, והיא משתנה כדי לוודא שהנפח הכולל של הנתונים שנאספים נשאר מתחת למגבלה.
בסשנים של משתמשים נשלחים נתונים מפורטים נוספים מהמכשיר של המשתמש, ולכן נדרשים יותר משאבים כדי לתעד ולשלוח את הנתונים. כדי לצמצם את ההשפעה של סשנים של משתמשים, יכול להיות ש-Performance Monitoring גם יגביל את מספר הסשנים.
הגבלת קצב של יצירת בקשות בצד השרת: כדי לוודא שהאפליקציות לא חורגות ממגבלת הדגימה, יכול להיות ש-Performance Monitoring ישתמש בדגימה בצד השרת כדי להשמיט חלק מהאירועים שהתקבלו מהמכשירים. למרות שההגבלה הזו לא משנה את היעילות של המדדים שלנו, היא יכולה לגרום לשינויים קלים בדפוסים, כולל:
מספר המעקבים יכול להיות שונה ממספר הפעמים שקטע קוד מסוים הופעל.
יכול להיות שלמעקבים שקשורים באופן הדוק בקוד יהיה מספר שונה של דגימות.
מה קרה לכרטיסייה בעיות במסוף?
החלפנו את הכרטיסייה Issues בכרטיסייה Alerts, שבה אתם מקבלים התראות באופן אוטומטי כשיש חריגה מהסף שהגדרתם. לא צריך יותר לבדוק ידנית את מסוף Firebase כדי לברר את הסטטוס של הסף. מידע נוסף על הגדרת התראות לגבי בעיות בביצועים
מה קרה לכרטיסיות במכשיר ורשת במסוף?
איך אפשר לראות את המעקבים שהיו בדפים האלה?
עיצבנו מחדש את הקטע Performance Monitoring במסוף Firebase, כך שבכרטיסייה Dashboard מוצגים המדדים העיקריים וכל המעקבים במקום אחד. במסגרת העיצוב מחדש, הסרנו את הדפים במכשיר ורשת.
טבלת המעקבים שבתחתית הכרטיסייה Dashboard מכילה את אותו המידע שמוצג בכרטיסיות On device ו-Network, אבל עם כמה תכונות נוספות, כולל היכולת למיין את המעקבים לפי אחוז השינוי במדד ספציפי. כדי להציג את כל המדדים והנתונים של מעקב ספציפי, לוחצים על שם המעקב בטבלת המעקבים.
אפשר לראות את המעקבים בכרטיסיות המשנה הבאות של טבלת המעקבים:
יומני מעקב של בקשות לאחזור מהרשת (גם מוכנים לשימוש וגם בהתאמה אישית) – כרטיסיית המשנה בקשות לאחזור מהרשת
מעקבים אחר קוד בהתאמה אישית – כרטיסיית המשנה מעקבים בהתאמה אישית
מעקבים אחר הפעלת האפליקציה, אפליקציה שפועלת בחזית, אפליקציה שפועלת ברקע – הכרטיסייה מעקבים בהתאמה אישית
מעקבי רינדור מסך – הכרטיסייה המשנית רינדור מסך
מעקבי טעינת דפים – הכרטיסייה המשנית טעינת דף
כדי לקבל פרטים על טבלת המעקבים ועל הצגת מדדים ונתונים, אפשר להיכנס לדף הסקירה הכללית במסוף (iOS+ | Android | אינטרנט).
למה מספר הפריימים האיטיים והקפואים שונה ממה שציפיתי?
החישוב של פריימים שקופאים ופריימים עם רינדור איטי מבוסס על ההנחה שקצב הרענון של המכשיר הוא 60Hz. אם קצב הרענון של המכשיר נמוך מ-60Hz, זמן הרינדור של כל פריים יהיה איטי יותר כי פחות פריימים מרונדרים בשנייה.
זמני רינדור איטיים יותר יכולים לגרום לדיווח על יותר פריימים איטיים או קפואים, כי יותר פריימים ירונדרו לאט יותר או יקפאו. עם זאת, אם קצב הרענון של המכשיר גבוה מ-60Hz, זמן הרינדור של כל פריים יהיה מהיר יותר.
כתוצאה מכך, יכול להיות שיהיו פחות דיווחים על פריימים איטיים או קפואים. זו מגבלה שקיימת כרגע ב-SDK של Performance Monitoring.
איך מוסיפים לאפליקציית האינטרנט את Performance Monitoring JS SDK הקטן יותר, עם מרחב השמות (SDK "עצמאי")?
אם Performance Monitoring הוא המוצר היחיד של Firebase באפליקציה, אפשר להשתמש ב-SDK העצמאי של Performance Monitoring (ובסקריפט הכותרת המומלץ שבהמשך) אם רוצים:
שימוש בספרייה עם מרחב שמות
הקטנת הגודל של חבילת ה-SDK
עיכוב ההפעלה של ה-SDK עד לאחר טעינת הדף
כדי לכלול את ה-SDK העצמאי של Performance Monitoring באפליקציה ולעכב את ההפעלה שלו עד אחרי שהדף נטען:
הסקריפט שלמעלה טוען באופן אסינכרוני את ה-SDK העצמאי, ואז מאתחל את Firebase אחרי שהאירוע onload של החלון מופעל. הטקטיקה הזו מפחיתה את ההשפעה שיכולה להיות ל-SDK על מדדי טעינת הדף, כי הדפדפן כבר דיווח על מדדי הטעינה שלו כשהפעלתם את ה-SDK.
מידע על ה-SDK העצמאי של Performance Monitoring ועל הסקריפט של הכותרת
ערכת ה-SDK העצמאית הזו מותאמת לגודל. אחרי דחיסה ב-Gzip, הגודל שלה הוא בערך 10KB. הוא כולל את כל הפונקציות של Firebase Performance Monitoring, וגם קבוצה מינימלית של פונקציות הליבה של Firebase SDK.
Firebase Performance Monitoring משתמש בממשקי ה-API של fetch ו-Promise, שלא זמינים בדפדפנים ישנים יותר. ה-polyfills של ממשקי ה-API האלה כלולים ב-SDK הרגיל של Firebase Performance Monitoring ל-JS, אבל הם לא כלולים ב-SDK העצמאי כדי להקטין את הגודל.
ערכת ה-SDK של Performance Monitoring מסתמכת, בין השאר, על Resource Timing API כדי לקבל מדדי טעינת דפים מהדפדפן.
קטע הקוד הבא מפרט את הסקריפט של הכותרת שכולל את האתחול של ה-SDK ואז מעכב אותו:
(function(sdkSource,firebaseConfigObject){functionload(f,c){//CreatesascripttagtoloadthestandaloneSDKvarsdkScript=document.createElement('script');//Setsittoanasyncscriptsothatitdoesn't interfere with page loadsdkScript.async=1;//SetsthesourceofthescriptsdkScript.src=f;//Insertsthescriptintotheheadofthepagevars=document.getElementsByTagName('script')[0];s.parentNode.insertBefore(sdkScript,s);}//Callstheloadmethodload(sdkSource);//InitializestheSDKonlywhentheonloadmethodiscalledwindow.addEventListener('load',function(){firebase.initializeApp(firebaseConfigObject).performance();});})(performance_standalone,firebaseConfig);
כאשר:
performance_standalone הוא 'https://www.gstatic.com/firebasejs/13.0.0/firebase-performance-standalone.js'
כמה תבניות של כתובות URL מותאמות אישית אפשר ליצור?
אפשר ליצור עד 400 תבניות של כתובות URL מותאמות אישית לכל אפליקציה, ועד 100 תבניות של כתובות URL מותאמות אישית לכל דומיין באפליקציה הזו.
עיבוד נתונים והצגה כמעט בזמן אמת
מה המשמעות של נתוני ביצועים "כמעט בזמן אמת"?
Firebase Performance Monitoring מעבד את נתוני הביצועים שנאספים כשהם מגיעים, וכתוצאה מכך הנתונים מוצגים כמעט בזמן אמת במסוף Firebase. הנתונים המעובדים מוצגים במסוף תוך כמה דקות מרגע האיסוף שלהם, ולכן המונח "כמעט בזמן אמת".
איך אפשר לקבל נתוני ביצועים כמעט בזמן אמת לאפליקציה?
כדי ליהנות מעיבוד נתונים כמעט בזמן אמת, אתם רק צריכים לוודא שהאפליקציה שלכם משתמשת בגרסת SDK של Performance Monitoring שתואמת לעיבוד נתונים בזמן אמת.
אלה גרסאות ה-SDK שתואמות לבדיקה בזמן אמת:
iOS – גרסה 7.3.0 ואילך
tvOS – גרסה 8.9.0 ואילך
Android – גרסה 19.0.10 ואילך (או Firebase Android BoM גרסה 26.1.0 ואילך)
אינטרנט – גרסה 7.14.0 ואילך
חשוב לזכור שתמיד מומלץ להשתמש בגרסה העדכנית של ה-SDK, אבל כל גרסה שמופיעה למעלה תאפשר ל-Performance Monitoring לעבד את הנתונים שלכם כמעט בזמן אמת.
אילו גרסאות של ה-SDK של Performance Monitoring נחשבות לתואמות לבידינג בזמן אמת?
אלה גרסאות ה-SDK שתואמות לעיבוד נתונים בזמן אמת:
iOS – גרסה 7.3.0 ואילך
tvOS – גרסה 8.9.0 ואילך
Android – גרסה 19.0.10 ואילך (או Firebase Android BoM גרסה 26.1.0 ואילך)
אינטרנט – גרסה 7.14.0 ואילך
חשוב לזכור שתמיד מומלץ להשתמש בגרסה העדכנית של ה-SDK, אבל כל גרסה שמופיעה למעלה תאפשר ל-Performance Monitoring לעבד את הנתונים שלכם כמעט בזמן אמת.
מה יקרה אם לא אעדכן את האפליקציה לגרסת SDK שתואמת לבידינג בזמן אמת?
אם האפליקציה לא משתמשת בגרסת SDK שתואמת לזמן אמת, עדיין אפשר לראות את כל נתוני הביצועים של האפליקציה במסוף Firebase. עם זאת, נתוני הביצועים יוצגו בעיכוב של כ-36 שעות מרגע האיסוף שלהם.
עדכנתי לגרסת SDK שתואמת לנתונים בזמן אמת, אבל חלק מהמשתמשים עדיין משתמשים בגרסאות ישנות של האפליקציה. האם אמשיך לראות את נתוני הביצועים שלהם במסוף Firebase?
כן! לא משנה באיזו גרסת SDK משתמש מופע של אפליקציה, יוצגו לכם נתוני ביצועים מכל המשתמשים.
עם זאת, אם אתם בוחנים נתונים מהזמן האחרון (מלפני פחות מ-36 שעות בערך), הנתונים שמוצגים הם ממשתמשים של מופעי אפליקציה שמשתמשים בגרסת SDK שתואמת לזמן אמת. לעומת זאת, הנתונים הלא עדכניים כוללים נתוני ביצועים מכל הגרסאות של האפליקציה.
למה נתוני הביצועים לא מוצגים בזמן אמת?
כדי לראות נתוני ביצועים בזמן אמת, צריך לוודא שהאפליקציה משתמשת בגרסת SDK של Performance Monitoring שתואמת לעיבוד נתונים בזמן אמת.
iOS – גרסה 7.3.0 ואילך
tvOS – גרסה 8.9.0 ואילך
Android – גרסה 19.0.10 ואילך (או Firebase Android BoM גרסה 26.1.0 ואילך)
אינטרנט – גרסה 7.14.0 ואילך
חשוב לזכור שתמיד מומלץ להשתמש בגרסה העדכנית של ה-SDK, אבל כל גרסה שמופיעה למעלה תאפשר ל-Performance Monitoring לעבד את הנתונים שלכם כמעט בזמן אמת.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2026-10-16 (שעון UTC)."],[],[]]