מדידת ביצועים ב-Service Worker

Paul Kinlan

נוסף על כך שג'ייק ארקדיל (Jake Archibald) מודאג מכך שיכולות הפיתוח שלו הולכות ונעלמות, הוא הראה בצורה משכנעת ששימוש חכם ב-service worker יכול לשפר באופן משמעותי את הביצועים של האתר או האפליקציה. מומלץ לצפות בסרטון כדי לקבל סקירה כללית.

אם אתם רוצים לשפר את זמן הטעינה של הדף כמו שהוצע על ידי ג'ייק, אתם צריכים להבין איך שירותי העבודה משפיעים על הבקשות של הדף.

Resource Timing ו-User Timing API הם רכיבים קריטיים בתשתית של RUM (מעקב אחר משתמשים אמיתיים) באתרים רבים, כי הם מאפשרים לכם להבין באופן מקיף איך כל המשתמשים רואים את הביצועים של האתר (תרחיש לדוגמה נוסף הוא זיהוי הזרקת תוכן). בקיצור, הנתונים האלה מאפשרים לכם להבין כמעט כל היבט של כל בקשה מהאתר שלכם, אלא אם יש לכם שירות עובד או עובד אינטרנט.

הנה דוגמה מהירה לאופן שבו אפשר להשתמש בו כדי לקבל רשימה של כל הבקשות שנשלחו לדומיין שאינו הדומיין הנוכחי.

var getThirdPartyRequests = function() {
    var thirdPartyRequests = [];
    var requests = window.performance.getEntriesByType("resource");
    
    var currentHost = window.location.host

    for(var requestIdx = 0; requestIdx < requests.length; requestIdx++) {
    var request = requests[requestIdx];
    var url = new URL(request.name);
    var host = url.host;

    if(host != currentHost) {
        thirdPartyRequests.push(request);
    }
    }
    
    return thirdPartyRequests;
};

ממשקי ה-API של Resource Timing ו-User Timing נוצרו והוטמעו לפני ש-Service Worker היה בראש של מהנדסים, והקוד שלמעלה לא יוכל להבין איך Service Worker השפיע עליו.

קבוצה של שינויים שבוצעו לאחרונה ב-Chrome 45 (גרסת בטא ביולי 2015) תעזור לכם, כי היא מאפשרת לכל סוגי העובדים (Web ו-service worker) לגשת לממשקי ה-API של Resource Timing ו-User Timing, וכך לעקוב אחרי ביצועי הרשת של כל המשתמשים.

גישה למדדי הביצועים מ-Service Worker

השינוי הגדול ביותר הוא הוספת האובייקט performance להקשר של Workers‏ (Web ו-ServiceWorkers), שיאפשר לכם עכשיו להבין את זמני הביצועים של כל הבקשות שמוגשות בהקשר של ה-worker, וגם להגדיר סמנים משלכם למדידת ביצוע ה-JS. אם אתם יכולים לראות רק מה שקורה בהקשר של החלון הנוכחי, אתם עלולים לפספס מידע קריטי לגבי תזמון מ:

  • בקשות fetch() שנשלחות באירוע oninstall של ה-service worker
  • מעכשיו אפשר לעקוב אחרי בקשות fetch() שנשלחות כששומרים נתונים במטמון באירוע onpush, כדי להבין את הביצועים שהמשתמשים רואים.
  • לבסוף, בקשות fetch() שנשלחות ונחסמות על ידי הטיפול של onfetch.

הנקודה האחרונה חשובה. אפשר לחשוב על קובץ שירות כשרתי proxy שנמצא בין ממשק המשתמש באינטרנט לבין הרשת. האובייקט performance ב-window רואה רק את התזמונים והמידע לגבי החלק של הבקשה שהוא מפעיל. אין לו ידע על ה-service worker שנמצא בין הלקוח לרשת, ולכן הוא לא יכול להבין את ההשפעה של ה-service worker.

איך אפשר להשתמש בזה?

ל-service worker טיפוסי שתומך בעבודה אופליין קודם יהיה שלב התקנה שבו הוא יוריד וישמור את כל הנכסים לשימוש מאוחר יותר.

דוגמה לשימוש אפשרי בנתונים האלה היא להקליט את נתוני התזמון של שלב ההתקנה ולתעד אותם ביומן, כדי שתוכלו לקבל החלטות מבוססות לגבי שיפור הביצועים של ההתקנה על סמך נתוני שימוש אמיתיים של משתמשים.

self.addEventListener("install", function() {
    var urls = [
    '/',
    '/images/chrome-touch-icon-192x192.png',
    '/images/ic_add_24px.svg',
    '/images/side-nav-bg@2x.jpg',
    '/images/superfail.svg',
    '/scripts/voicememo-core.js',
    '/styles/voicememo-core.css',
    '/third_party/Recorderjs/recorder.js',
    '/third_party/Recorderjs/recorderWorker.js',
    '/third_party/Recorderjs/wavepcm.js',
    '/third_party/moment.min.js',
    '/favicon.ico',
    '/manifest.json'
    ];

    urls = urls.map(function(url) {
    return new Request(url, {credentials: 'include'});
    });

    event.waitUntil(
    caches
        .open(CACHE_NAME + '-v' + CACHE_VERSION)
        .then(function(cache) {
        // Fetch all the URL's and store in the cache
        return cache.addAll(urls);
        })
        .then(function () {
        // Analyze all the requests
        var requests = self.performance.getEntriesByType("resource");
        
        // Loop across all the requests and save the timing data.
        return;
        })
    );
});

כיום, אתרים רבים משתמשים ב-RUM כדי להבין איך רוב המשתמשים חווים את האתר שלהם. כלים כמו Google Analytics כבר מדווחים על נתוני מהירות האתר באמצעות Navigation Timing API, אבל הם יצטרכו להתעדכן כך שיכללו ניתוח ביצועים מההקשר של Worker.

האם Navigation Timing API יגיע ל-Service Workers

בשלב הזה אין תוכניות להוסיף את Navigation Timing API להקשר של קובץ השירות, כי אין ניווטים מסורתיים בקובץ שירות. העניין המעניין הוא שלקובץ השירות, כל ניווט בקבוצת הדפים שבשליטתו נראה כמו אחזור משאב. זהו יתרון עצום של קובצי השירות, שמאפשרים למרכז את רוב הלוגיקה של ביצועי האפליקציה באינטרנט.

אפשר לראות מה השתנה?

אני רוצה לקרוא את הדיון ולקבל מידע על המפרטים