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

פול קינלן

מלבד ג'ייק ארצ'יבלד לדאוג שמיומנויות המפתחים שלו ייפגעו, הוא טעה בטענה ששימוש חכם ב-Service Worker יכול לשפר משמעותית את ביצועי האתר או האפליקציה שלכם. מומלץ לצפות בסרטון כדי לקבל סקירה כללית.

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

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

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

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 של תזמון משאב ו-User Timing נוצרו ויושמו לפני שה-Service Worker היה קורבן בעיניים של מהנדסי תוכנה, והקוד שלמעלה לא יבין איך ה-Service Worker השפיע עליו.

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

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

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

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

הנקודה האחרונה חשובה. אחת הדרכים להסתכל על Service Worker היא כשרת 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 Schedule API, אך יש לעדכן אותם כך שיכללו ניתוח של הביצועים מהקשר של worker.

האם ה-API של תזמון הניווט יגיע ל-Service Workers

בשלב זה אין כוונה להוסיף את Navigation Timing API להקשר של קובץ השירות (service worker), כי אין ניווטים מסורתיים ב-Service Worker. הדבר המעניין הוא שמבחינת ה-Service Worker, כל ניווט בקבוצת הדפים המבוקרת של ה-Service Worker נראה כמו אחזור משאב. בזכות זאת, Service Worker מספק דרך מאוד משכנעת לרכז את רוב לוגיקת הביצועים באפליקציית האינטרנט.

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

אני מתעניין בדיון ובמפרט