כותרת הבקשה לרמז ללקוח Save-Data
שזמינה בדפדפנים Chrome, Opera ו-Yandex, מאפשרת למפתחים לספק אפליקציות קלות ומהירות יותר למשתמשים שמצטרפים למצב חיסכון בנתונים בדפדפן.
הצורך בדפים קלים
כולם מסכימים שדפי אינטרנט מהירים וקלים יותר מספקים חוויית משתמש מספקת יותר, הבנה ושימור טובים יותר של התוכן, ומניבים המרות והכנסות גבוהות יותר. מחקרים של Google הראו ש"...דפים שעברו אופטימיזציה נטענים פי ארבעה יותר מהר מהדף המקורי, והם צורכים פחות בייטים ב-80%. מכיוון שהדפים האלה נטענים כל כך מהר, ראינו גם עלייה של 50% בתנועה לדפים האלה".
ולמרות שמספר החיבורים לרשת 2G ירד בסופו של דבר, בשנת 2015, 2G עדיין הייתה טכנולוגיית הרשת הדומיננטית. חדירה של רשתות 3G ו-4G גוברת וזמינותן גדלות במהירות, אבל עלויות הבעלות ומגבלות הרשת שמשויכות אליהן עדיין משפיעים על מאות מיליוני משתמשים.
אלו ארגומנטים חזקים לאופטימיזציה של דפים.
יש שיטות חלופיות לשיפור מהירות האתר ללא מעורבות ישירה של המפתח, כמו דפדפני proxy ושירותי המרת קידוד. למרות ששירותים כאלה הם די פופולריים, יש להם חסרונות משמעותיים: דחיסת תמונה וטקסט פשוטה (ולפעמים לא מקובלת), חוסר יכולת לעבד דפים מאובטחים (HTTPS), רק אופטימיזציה של דפים שנכנסים אליהם דרך תוצאת חיפוש ועוד. מידת הפופולריות של השירותים האלה כשלעצמה היא סימן לכך שמפתחי אתרים לא מתמודדים כראוי עם הביקוש הגבוה של המשתמשים לאפליקציות ולדפים מהירים וקלים. אבל הדרך להגיע למטרה הזו היא מורכבת ולפעמים קשה.
כותרת הבקשה Save-Data
שיטה אחת פשוטה למדי היא לתת לדפדפן לעזור, באמצעות כותרת הבקשה Save-Data
. על ידי זיהוי הכותרת הזו, דף אינטרנט יכול להתאים אישית ולספק חוויית משתמש אופטימלית למשתמשים שמוגבלים בעלות ובביצועים.
בדפדפנים נתמכים (בהמשך) משתמשים יכולים להפעיל *מצב חיסכון בנתונים שמעניק לדפדפן הרשאה להחיל קבוצת אופטימיזציות כדי לצמצם את כמות הנתונים שדרושה לעיבוד הדף. כשהמאפיין הזה חשוף או מפרסם, הדפדפן עשוי לבקש תמונות ברזולוציה נמוכה יותר, לדחות טעינה של משאבים מסוימים או לנתב בקשות דרך שירות שמחיל אופטימיזציות אחרות ספציפיות לתוכן, כמו דחיסת משאבי תמונה וטקסט.
תמיכת דפדפן
- דפדפן Chrome 49 ואילך מפרסם
Save-Data
כשהמשתמש מפעיל את האפשרות 'חוסך הנתונים' בנייד, או את התוסף 'חוסך הנתונים' בדפדפנים במחשב. - Opera 35+ מפרסם את
Save-Data
כשהמשתמש מפעיל את מצב Opera Tuurbo במחשב, או את האפשרות Data savings בדפדפני Android. - Yandex 16.2+ מפרסם את
Save-Data
כשמצב טורבו מופעל במחשב או בדפדפנים לנייד.
מתבצע זיהוי של ההגדרה Save-Data
כדי לקבוע מתי לספק למשתמשים את החוויה 'קלה', האפליקציה יכולה לחפש את כותרת הבקשה של הרמז ללקוח Save-Data
. כותרת הבקשה הזו מציינת את ההעדפה של הלקוח לשימוש מופחת בנתונים בגלל עלויות העברה גבוהות, מהירויות חיבור איטיות או סיבות אחרות.
כשהמשתמש מפעיל את מצב שמירת הנתונים בדפדפן, הדפדפן מצרף את כותרת הבקשה Save-Data
לכל הבקשות היוצאות (גם HTTP וגם HTTPS).
נכון לעכשיו, הדפדפן מפרסם רק אסימון *on- אחד בכותרת
(Save-Data: on
), אך ייתכן שנרחיב את הגישה הזו בעתיד כדי לציין העדפות משתמש אחרות.
בנוסף, ניתן לזהות אם Save-Data
מופעל ב-JavaScript:
if ('connection' in navigator) {
if (navigator.connection.saveData === true) {
// Implement data saving operations here.
}
}
חשוב מאוד לבדוק את הנוכחות של האובייקט connection
באובייקט navigator
, כי הוא מייצג את Network Information API, שמוטמע רק בדפדפני האינטרנט Chrome, Chrome ל-Android ו-Samsung. אחר כך צריך רק לבדוק אם navigator.connection.saveData
שווה ל-true
, ואפשר לבצע פעולות של שמירת נתונים בתנאי הזה.
אם האפליקציה משתמשת ב-Service Worker, אתם יכולים לבדוק את כותרות הבקשות ולהחיל לוגיקה רלוונטית כדי לשפר את חוויית השימוש.
לחלופין, השרת יכול לחפש את ההעדפות שפורסמו בכותרת הבקשה Save-Data
, ולהחזיר תשובה חלופית – תגי עיצוב שונים, תמונות קטנות יותר, סרטונים קטנים יותר וכן הלאה.
טיפים ושיטות מומלצות להטמעה
- כשמשתמשים ב-
Save-Data
, צריך לספק מכשירים מסוימים עם ממשק המשתמש שתומכים בו, ולאפשר למשתמשים לעבור בין חוויות משתמש בקלות. לדוגמה:- צריך להודיע למשתמשים על כך שיש תמיכה ב-
Save-Data
ולעודד אותם להשתמש בשירות. - המשתמשים יכולים לזהות ולבחור את המצב באמצעות הנחיות מתאימות ולחצני הפעלה/השבתה אינטואיטיביים או תיבות סימון.
- כשבוחרים במצב חיסכון בנתונים, צריך להודיע ולספק דרך פשוטה וברורה להשבית אותה ולחזור לחוויה המלאה אם תרצו.
- צריך להודיע למשתמשים על כך שיש תמיכה ב-
- חשוב לזכור שאפליקציות קטנות הן לא אפליקציות פחות נמוכות. הם לא משמיטים פונקציונליות או נתונים חשובים, הם פשוט מבינים יותר את העלויות הכרוכות בכך ואת חוויית המשתמש. לדוגמה:
- באפליקציה של גלריית תמונות, יכול להיות שיוצגו תצוגות מקדימות ברזולוציה נמוכה יותר או להשתמש במנגנון קרוסלה עם פחות קוד מלא.
- אפליקציית חיפוש עשויה להחזיר פחות תוצאות בכל פעם, להגביל את מספר התוצאות העמוסות במדיה או לצמצם את מספר יחסי התלות שנדרשים לעיבוד הדף.
- אתר שמתמקד בחדשות עשוי להציג פחות כתבות, להשמיט קטגוריות פחות פופולריות, או להציג תצוגות מקדימות קטנות יותר של מדיה.
- כדאי לספק לוגיקה של השרת כדי לבדוק את כותרת הבקשה
Save-Data
ולשקול לספק תגובת דף חלופית, קלה יותר כשהיא מופעלת – למשל, מצמצמים את מספר המשאבים ויחסי התלות הנדרשים, מחילים דחיסת משאבים אגרסיבית יותר וכו'.- אם מציגים תגובה חלופית שמבוססת על הכותרת
Save-Data
, חשוב לזכור להוסיף אותה לרשימה Vary –Vary: Save-Data
– כדי ליידע את המטמון של ה-upstream שצריך לשמור את הגרסה הזו במטמון ולהציג את הגרסה הזו רק אם קיימת כותרת הבקשהSave-Data
. למידע נוסף, עיינו בשיטות המומלצות לאינטראקציה עם מטמון.
- אם מציגים תגובה חלופית שמבוססת על הכותרת
- אם משתמשים ב-service worker, האפליקציה יכולה לזהות מתי האפשרות לחיסכון בנתונים מופעלת על ידי בדיקת הנוכחות של כותרת הבקשה
Save-Data
או על ידי בדיקת הערך של המאפייןnavigator.connection.saveData
. אם המדיניות מופעלת, כדאי לשקול אם אפשר לשכתב את הבקשה כדי לאחזר פחות בייטים, או להשתמש בתגובה שכבר נשלפה. - מומלץ להרחיב את
Save-Data
באמצעות אותות אחרים, כמו מידע על סוג החיבור והטכנולוגיה של המשתמש (ראו NetInfo API). לדוגמה, יכול להיות שתרצו לספק את חוויית השימוש הקלה לכל משתמש בחיבור 2G, גם אם התכונהSave-Data
לא מופעלת. לעומת זאת, גם אם המשתמש נמצא בחיבור 4G "מהיר", זה לא אומר שהוא לא מעוניין לשמור נתונים, למשל בזמן נדידה. בנוסף, תוכלו להרחיב את הנוכחות שלSave-Data
בעזרת הרמז ללקוחDevice-Memory
כדי להסתגל עוד יותר למשתמשים במכשירים עם זיכרון מוגבל. זיכרון המכשיר של המשתמש מפורסם גם ברמז הלקוחnavigator.deviceMemory
.
מתכונים
מה שאפשר להשיג דרך Save-Data
מוגבל רק למה שאפשר להמציא. כדי לתת לכם מושג לגבי האפשרויות השונות, בואו נעבור על כמה תרחישים לדוגמה. אתם עשויים להמציא תרחישים לדוגמה משלכם תוך כדי הקריאה, אז אתם מוזמנים להתנסות ולראות מה אפשר לעשות.
מתבצע חיפוש של Save-Data
בקוד בצד השרת
המצב Save-Data
הוא מצב שאפשר לזהות ב-JavaScript דרך המאפיין navigator.connection.saveData
, אבל לפעמים עדיף לזהות אותו בצד השרת. במקרים מסוימים, הפעלת JavaScript עשויה להיכשל. בנוסף, זיהוי בצד השרת הוא הדרך היחידה לשנות תגי עיצוב לפני שהם נשלחים ללקוח, שמעורב בכמה מהתרחישים השימושיים ביותר של Save-Data
.
התחביר הספציפי לזיהוי הכותרת Save-Data
בקוד בצד השרת תלוי בשפה שבה משתמשים, אבל הרעיון הבסיסי צריך להיות זהה לכל קצה עורפי של אפליקציה. לדוגמה, ב-PHP, כותרות הבקשות מאוחסנות במערך על-עולמי $_SERVER
באינדקסים שמתחילים ב-HTTP_
. כלומר, אפשר לזהות את הכותרת Save-Data
על ידי בדיקת הקיום והערך של המשתנה $_SERVER["HTTP_SAVE_DATA"]
, באופן הבא:
// false by default.
$saveData = false;
// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
// `Save-Data` detected!
$saveData = true;
}
אם מפעילים את הבדיקה הזו לפני שתגי עיצוב כלשהם נשלחים ללקוח, המשתנה $saveData
יכיל את המצב Save-Data
ויהיה זמין בכל מקום לשימוש בדף. נבחן את המנגנון הזה כדי להראות איך נוכל להשתמש בו כדי להגביל את כמות הנתונים שאנחנו שולחים למשתמש.
הצגת תמונות ברזולוציה נמוכה במסכים עם רזולוציה גבוהה
אחד התרחישים הנפוצים לשימוש בתמונות באינטרנט הוא הצגת תמונות בקבוצות של שתיים:
תמונה אחת למסכים "סטנדרטיים" (1x) ותמונה נוספת גדולה פי שניים (פי 2) במסכים עם רזולוציה גבוהה (למשל תצוגת Retina). הסוג הזה של מסכים ברזולוציה גבוהה לא מוגבל בהכרח למכשירים מתקדמים, ולכן הוא נפוץ יותר ויותר. במקרים שבהם עדיף להשתמש באפליקציה קלה יותר, עדיף לשלוח תמונות ברזולוציה נמוכה יותר (1x) למסכים האלה, במקום וריאנטים גדולים יותר (2x). כדי לעשות זאת כשהכותרת Save-Data
מופיעה, אנחנו פשוט משנים את תגי העיצוב שאנחנו שולחים ללקוח:
if ($saveData === true) {
// Send a low-resolution version of the image for clients specifying `Save-Data`.
?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
// Send the usual assets for everyone else.
?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}
התרחיש לדוגמה הזה הוא דוגמה מושלמת למעט המאמץ שנדרש כדי לתת מענה למישהו שמבקש מכם באופן ספציפי לשלוח לו פחות נתונים. אם לא רוצים לשנות את תגי העיצוב בקצה העורפי, אפשר גם להשיג את אותה התוצאה באמצעות מודול לשכתוב כתובות URL כמו mod_rewrite
של Apache. יש דוגמאות איך לעשות זאת עם הגדרות אישיות מעטות יחסית.
אפשר גם להרחיב את הקונספט הזה לנכסי background-image
של CSS על ידי הוספת מחלקה לרכיב <html>
:
<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">
מכאן תוכלו לטרגט את המחלקה save-data
ברכיב <html>
ב-CSS כדי לשנות את האופן שבו התמונות נשלחות. תוכלו לשלוח תמונות רקע ברזולוציה נמוכה למסכים עם רזולוציה גבוהה כפי שמוצג בדוגמה ל-HTML שלמעלה, או להשמיט לחלוטין משאבים מסוימים.
השמטת תמונות לא חיוניות
חלק מתוכן התמונות באינטרנט פשוט אינו חיוני. תמונות כאלה יכולות לעשות שימוש גם בתוכן חוץ, אבל אולי הן לא מבוקשות על ידי אנשים שמנסים לדחוס את כל מה שאפשר מתוכניות נתונים של חיוב לפי שימוש בנתונים. במקרה שזה המקרה הפשוט ביותר של Save-Data
, אנחנו יכולים להשתמש בקוד הזיהוי של PHP מקודמים יותר ולהשמיט לחלוטין את תגי העיצוב של תמונות לא חיוניות:
<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
// Only send this image if `Save-Data` hasn't been detected.
?><img src="meme.jpg" alt="One does not simply consume data."><?php
}
לטכניקה הזו יכולה להיות השפעה מובהקת, כפי שאפשר לראות באיור הבא:
כמובן, השמטת תמונות היא לא האפשרות היחידה. אפשר גם לבצע פעולות ב-Save-Data
כדי לוותר על שליחת משאבים לא קריטיים אחרים, כמו גופנים מסוגים מסוימים.
השמטת גופן אינטרנט לא חיוני
למרות שגופני אינטרנט בדרך כלל לא מהווים כמעט חלק מהמטען הכולל של דף נתון, כמו תמונות נפוצות, הם עדיין פופולריים למדי. גם הם לא צורכים כמות לא משמעותית של נתונים. בנוסף, הדרך שבה דפדפנים מאחזרים ומעבדים גופנים מורכבת יותר ממה שחשבתם, באמצעות מושגים כמו FOIT, FOUT והיוריסטיקה בדפדפן שהופכת את העיבוד לפעולה מורכבת.
יכול להיות שהסיבה לכך היא שתרצו להשמיט גופנים לא חיוניים של משתמשים, שמעוניינים בחוויות משתמש נקיות יותר. Save-Data
הופך את התהליך הזה לפשוט מאוד.
לדוגמה, נניח שכללתם את Fira
Sans מתוך Google
Fonts באתר. Fira Sans הוא גופן מצוין לעותק בגוף
אבל אולי הוא לא כל כך חיוני למשתמשים שמנסים לשמור נתונים. הוספת מחלקה של save-data
לרכיב <html>
כשהכותרת Save-Data
מוצגת, מאפשרת לנו לכתוב סגנונות שמפעילים בהתחלה את הגופן הלא חיוני, אבל לאחר מכן מבטלים את ההסכמה לכך כשהכותרת Save-Data
קיימת:
/* Opt into web fonts by default. */
p,
li {
font-family: 'Fira Sans', 'Arial', sans-serif;
}
/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
font-family: 'Arial', sans-serif;
}
בגישה הזו אפשר להשאיר את קטע הקוד <link>
מ-Google Fonts במקומו, כי הדפדפן טוען באופן ספקולטיבי משאבי CSS (כולל גופנים באינטרנט) על ידי החלת סגנונות על ה-DOM ואז בדיקה אם רכיבי HTML כלשהם מפעילים אחד מהמשאבים בגיליון הסגנונות. אם מישהו יקרה לו באמצעות Save-Data
, Fira Sans לא ייטען אף פעם כי ה-DOM המסוגנן לא מפעיל אותו אף פעם. במקום זאת, ValueTrack יבוא לידי ביטוי. היא לא טובה כמו Fira Sans, אבל היא יכולה להיות עדיפה למשתמשים שמנסים להרחיב את חבילות הגלישה שלהם.
סיכום
בכותרת Save-Data
אין הרבה ניואנסים – היא מופעלת או מושבתת, והאפליקציה נושאת בנטל לספק חוויות מתאימות בהתאם להגדרה שלה, ללא קשר לסיבה.
לדוגמה, יכול להיות שחלק מהמשתמשים לא יאפשרו את מצב חיסכון בנתונים אם הם חושדים שיאבדו תוכן או פונקציות של האפליקציה, גם במצב של קישוריות לא טובה. לעומת זאת, יש משתמשים שעשויים לאפשר זאת, כמובן, כדי לשמור על דפים קטנים ופשוטים ככל האפשר, גם במצב קישוריות טוב. עדיף שהאפליקציה תניח שהמשתמש רוצה את החוויה המלאה והבלתי מוגבלת, עד שתהיה לכם אינדיקציה ברורה אחרת באמצעות פעולת משתמש מפורשת.
בעלי אתרים ומפתחי אתרים יכולים לקחת אחריות על ניהול התוכן שלנו כדי לשפר את חוויית המשתמש של משתמשים שמוגבלים בעלויות ובנתונים.
לפרטים נוספים על Save-Data
ועל דוגמאות מעשיות מצוינות, ראו עזרה למשתמשים Save Data
.