מגוון היכולות של מכשירים שיכולים להתחבר לאינטרנט רחב יותר היום מבעבר. ניתן גם להגיש את אותה אפליקציית אינטרנט למחשב נייח מתקדם בטלפון, בשעון או בטאבלט עם צריכת חשמל נמוכה, וזה יכול להיות מאתגר מאוד ליצור חוויות מרתקות שפועלות בצורה חלקה בכל מכשיר.
Device Memory API הוא פיצ'ר חדש של פלטפורמת אינטרנט שנועד לעזור למפתחי אינטרנט להתמודד עם סביבה מודרנית של מכשירים. היא מוסיפה מאפיין קריאה בלבד לאובייקט navigator, navigator.deviceMemory, שמחזירה את נפח ה-RAM שיש במכשיר בג'יגה-בייט, מעוגל למטה בחזקת 2. ה-API כולל גם כותרת לרמזים של הלקוח, Device-Memory, שמדווחת על אותו הערך.
Device Memory API מאפשר למפתחים לבצע שני דברים עיקריים:
- קבלת החלטות בזמן ריצה לגבי המשאבים שיש להציג על סמך ערך הזיכרון שהוחזר במכשיר (למשל, הצגת גרסה "קל" (Lite) של אפליקציה למשתמשים במכשירים עם זיכרון נמוך).
- תוכלו לדווח על הערך הזה לשירות ניתוח נתונים כדי להבין טוב יותר את הקשר בין זיכרון המכשיר להתנהגות המשתמשים, להמרות או למדדים אחרים שחשובים לעסק.
התאמת תוכן באופן דינמי על סמך זיכרון המכשיר
אם אתם מפעילים שרת אינטרנט משלכם ואתם יכולים לשנות את הלוגיקה שמשרתת את המשאבים, תוכלו להגיב באופן מותנה לבקשות שמכילות את Device-Memory כותרת Client Hints.
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
בשיטה הזו אפשר ליצור גרסה אחת או יותר של סקריפטים של האפליקציה ולהגיב לבקשות מהלקוח באופן מותנה, על סמך הערך שהוגדר בכותרת Device-Memory. הגרסאות האלה לא צריכות לכלול קוד שונה לחלוטין (כי קשה יותר לתחזק אותן). ברוב המקרים, הגרסה הבסיסית לא כוללת תכונות שעשויות להיות יקרות ושלא קריטיות לחוויית המשתמש.
שימוש בכותרת Client Hints
כדי להפעיל את הכותרת Device-Memory, צריך להוסיף את התג <meta> של 'רמזים ללקוחות' ל-<head> של המסמך:
<meta http-equiv="Accept-CH" content="Device-Memory">
לחלופין, אפשר לכלול את "זיכרון מכשיר" בכותרות התגובה Accept-CH של השרת:
HTTP/1.1 200 OK
Date: Thu Dec 07 2017 11:44:31 GMT
Content-Type: text/html
Accept-CH: Device-Memory, Downlink, Viewport-Width
הפעולה הזו מורה לדפדפן לשלוח את הכותרת Device-Memory עם כל הבקשות למשאבי משנה עבור הדף הנוכחי.
במילים אחרות, לאחר הטמעת אחת מהאפשרויות שלמעלה באתר שלך, אם משתמש מבקר במכשיר עם זיכרון RAM בנפח 0.5GB, כל הבקשות של תמונות, CSS ו-JavaScript מהדף הזה יכללו את הכותרת Device-Memory עם הערך "0.5", והשרת שלכם יכול להגיב לבקשות כאלה בכל דרך שתרצו.
לדוגמה, המסלול הבא עם Express מציג גרסת "lite" של סקריפט אם הכותרת Device-Memory מוגדרת והערך שלה נמוך מ-1, או שהוא מציג גרסה "מלאה" אם הדפדפן לא תומך בכותרת Device-Memory או שהערך הוא 1 ומעלה:
app.get('/static/js/:scriptId', (req, res) => {
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `scriptVersion` to "lite" if (and only if)
// `Device-Memory` isn't undefined and returns a number less than 1.
const scriptVersion = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Respond with the file based on `scriptVersion` above.
res.sendFile(`./path/to/${req.params.scriptId}.${scriptVersion}.js`);
});
שימוש ב-JavaScript API
במקרים מסוימים (כמו בשרת קבצים סטטי או ב-CDN) לא ניתן יהיה להגיב באופן מותנה לבקשות על סמך כותרת HTTP. במקרים כאלה תוכלו להשתמש ב-JavaScript API כדי לשלוח בקשות מותנות בקוד ה-JavaScript.
הלוגיקה הבאה דומה למסלול Express שלמעלה, אבל היא קובעת באופן דינמי את כתובת ה-URL של הסקריפט בלוגיקה של צד הלקוח:
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `componentVersion` to "lite" if (and only if)
// deviceMemory isn't undefined and returns a number less than 1.
const componentVersion = navigator.deviceMemory < 1 ? 'lite' : 'full';
const component = await import(`path/to/component.${componentVersion}.js`);
component.init();
הצגת גרסאות שונות של אותו רכיב בהתאם ליכולות המכשיר היא אמנם אסטרטגיה טובה, אבל לפעמים עדיף לא להציג רכיב בכלל.
במקרים רבים, רכיבים הם רק שיפורים. הן דורשות נגיעות נחמדות לחוויה, אבל הן לא נדרשות לפונקציונליות העיקרית של האפליקציה. במקרים כאלה, כדאי לא לטעון מלכתחילה רכיבים כאלה. אם רכיב שנועד לשפר את חוויית המשתמש גורם לאפליקציה לפעול באיטיות או בתגובה, הוא לא משיג את המטרה שלו.
כל החלטה שמקבלים משפיעה על חוויית המשתמש, חשוב מאוד למדוד את ההשפעה שלה. כמו כן, חשוב שתהיה לכם תמונה ברורה לגבי ביצועי האפליקציה היום.
אם תבינו את הקשר בין זיכרון המכשיר להתנהגות המשתמשים בגרסה הנוכחית של האפליקציה, תוכלו לקבל מידע טוב יותר לגבי הפעולה שצריך לבצע, ולהגדיר בסיס נתונים שבאמצעותו תוכלו למדוד את ההצלחה של שינויים עתידיים.
מעקב אחר זיכרון המכשיר בעזרת ניתוח נתונים
Device Memory API הוא חדש, ורוב ספקי הניתוח לא עוקבים אחריו כברירת מחדל. למרבה המזל, רוב הספקים של שירותי ניתוח נתונים מאפשרים לך לעקוב אחר נתונים מותאמים אישית (לדוגמה, ב-Google Analytics יש תכונה בשם Custom Dimensions) ובאמצעותה לעקוב אחר זיכרון המכשיר במכשירים של המשתמשים.
באמצעות מאפיין זיכרון מותאם אישית של המכשיר
השימוש במאפיינים מותאמים אישית ב-Google Analytics הוא תהליך דו-שלבי.
- מגדירים את המאפיין המותאם אישית ב-Google Analytics.
- מעדכנים את קוד המעקב כך שיהיה
setערך הזיכרון של המכשיר למאפיין המותאם אישית שיצרתם.
כשיוצרים את המאפיין המותאם אישית, צריך לתת לו את השם 'זיכרון מכשיר' ולבחור היקף של 'סשן', כי הערך לא ישתנה במהלך סשן הגלישה של המשתמש:
בשלב הבא, מעדכנים את קוד המעקב. הנה דוגמה לדרך שבה זה יכול להיראות. שימו לב שבדפדפנים שלא תומכים ב-Device Memory API, ערך המאפיין יהיה '(not set)'.
// Create the tracker from your tracking ID.
// Replace "UA-XXXXX-Y" with your Google Analytics tracking ID.
ga('create', 'UA-XXXXX-Y', 'auto');
// Set the device memory value as a custom dimension on the tracker.
// This will ensure it gets sent with all future data to Google Analytics.
// Note: replace "XX" with the index of the custom dimension you created
// in the Google Analytics admin.
ga('set', 'dimensionXX', navigator.deviceMemory || '(not set)');
// Do any other other custom setup you want...
// Send the initial pageview.
ga('send', 'pageview');
דיווח על נתוני זיכרון המכשיר
אחרי שמאפיין זיכרון המכשיר יהיה set באובייקט המעקב, כל הנתונים שתשלחו ל-Google Analytics יכללו את הערך הזה.
כך תוכלו להציג פירוט של כל מדד שתרצו (למשל, זמני טעינה של דף, שיעור השלמה של מטרות עסקיות וכו') לפי זיכרון המכשיר, כדי לראות אם יש קשרים.
מכיוון שזיכרון המכשיר הוא מאפיין מותאם אישית ולא מאפיין מובנה, הוא לא יופיע באף אחד מהדוחות הרגילים. כדי לגשת לנתונים האלה צריך ליצור דוח בהתאמה אישית. לדוגמה, התצורה של דוח בהתאמה אישית שמשווה את זמני הטעינה לפי זיכרון המכשיר, עשויה להיראות כך:
הדוח שנוצר עשוי להיראות כך:
לאחר איסוף נתוני זיכרון של המכשיר ויש לכם בסיס לאופן שבו משתמשים חווים את האפליקציה שלכם בכל הטווחים של ספק הזיכרון, תוכלו להתנסות בשימוש במשאבים שונים למשתמשים שונים (באמצעות הטכניקות שתוארו בקטע שלמעלה). לאחר מכן תוכלו להסתכל על התוצאות ולראות אם הן השתפרו.
סיכום
בפוסט הזה נסביר איך להשתמש ב-Device Memory API כדי להתאים את האפליקציה ליכולות של המכשירים של המשתמשים, ומוסבר איך למדוד את החוויה של המשתמשים האלה באפליקציה.
הפוסט הזה מתמקד ב-Device Memory API, אבל את רוב השיטות שמתוארות כאן אפשר ליישם בכל ממשק API שמדווח על יכולות המכשיר או על תנאי הרשת.
ככל שסביבת המכשירים הולכת ומתרחבת, חשוב יותר מתמיד שמפתחי אתרים יקחו בחשבון את כל מגוון המשתמשים כשהם מקבלים החלטות שמשפיעות על החוויה שלהם.