כיום, מגוון היכולות של מכשירים שיכולים להתחבר לאינטרנט רחב יותר מאשר בעבר. אותה אפליקציית אינטרנט שמוצגת מחשב שולחני עשוי להופיע גם בטלפון, שעון או טאבלט שעוצמתם נמוכה, וזה יכול להיות מאתגר מאוד ליצור חוויות מרתקות שעובדות בצורה חלקה בכל מכשיר.
Device Memory API הוא ממשק אינטרנט חדש
תכונת פלטפורמה שמטרתה לעזור למפתחי אתרים להתמודד עם המכשיר המודרני
לרוחב. היא מוסיפה מאפיין לקריאה בלבד לאובייקט navigator,
navigator.deviceMemory, שמחזיר את נפח ה-RAM שיש במכשיר
ג'יגה-בייט, מעוגלים למטה אל החזקה הקרובה ביותר של שתיים. ה-API כולל גם
כותרת רמזים ללקוחות,
Device-Memory, שמדווח על אותו ערך.
Device Memory API מאפשר למפתחים לבצע שני דברים עיקריים:
- מקבלים החלטות לגבי זמן הריצה לגבי המשאבים שיש להציג, על סמך ההחזרות ערך הזיכרון של המכשיר (למשל, הצגת גרסה "מצומצמת" של אפליקציה למשתמשים מכשירים עם נפח זיכרון נמוך).
- מומלץ לדווח על הערך הזה לשירות ניתוח נתונים כדי להבין טוב יותר איך זיכרון המכשיר תואם להתנהגות משתמשים, להמרות או למדדים אחרים שחשובה לעסק שלך.
התאמה דינמית של התוכן לפי הזיכרון במכשיר
אם אתם מפעילים שרת אינטרנט משלכם ויש לכם אפשרות לשנות את הלוגיקה
מציגה משאבים, אפשר להגיב באופן מותנה לבקשות שמכילות את
Device-Memory כותרת רמזים ללקוחות
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
בשיטה הזו אפשר ליצור גרסה אחת או יותר של האפליקציה
ומגיבים לבקשות מהלקוח באופן מותנה בהתבסס על
מוגדר בכותרת Device-Memory. הגרסאות האלה לא צריכות לכלול
קוד שונה לחלוטין (מכיוון שקשה יותר לתחזק אותו). ברוב המקרים,
"lite" רק תכונות שעשויות להיות יקרות ולא קריטיות
לחוויית המשתמש.
שימוש בכותרת 'רמזים ללקוחות'
כדי להפעיל את הכותרת 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", והשרת שלכם יכול להגיב לבקשות כאלה בכל דרך
לראות התאמה.
לדוגמה, נתיב האקספרס הבא משרת
"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. במקרים כאלה, יכול להשתמש ב-API של JavaScript כדי לשלוח בקשות מותנות בקוד ה-JavaScript.
הלוגיקה הבאה דומה למסלול האקספרס שלמעלה, אבל היא דינמית קובע את כתובת ה-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 יש תכונה בשם מאפיינים מותאמים אישית), שאפשר להשתמש בה משמש למעקב אחרי זיכרון המכשיר מכשירים.
שימוש במאפיין זיכרון מותאם אישית במכשיר
השימוש במאפיינים מותאמים אישית ב-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 שמדווח על יכולות של מכשירים, או התנאים של הרשת.
מכיוון שסביבת המכשיר הולכת ומתרחבת, חשוב יותר מתמיד מפתחי אתרים לוקחים בחשבון את כל טווח המשתמשים כשהם מקבלים החלטות להשפיע על החוויה שלהם.