העברת אפליקציות מהירות ופשוטות באמצעות חיסכון בנתונים

Dave Gash
Dave Gash
Ilya Grigorik
Ilya Grigorik

הבקשה של Save-Data רמז ללקוח כותרת שזמין בדפדפני Chrome , Opera ו-Yandex מאפשרים למפתחים לספק חוויית שימוש קלה יותר אפליקציות מהירות יותר למשתמשים שהצטרפו למצב חיסכון בנתונים בדפדפן שלהם.

הצורך בדפים קלים

נתונים סטטיסטיים של Weblight

כולם מסכימים שדפי אינטרנט מהירים וקלים יותר מספקים משתמש מרוצה יותר תאפשר הבנה ושימור טובים יותר של התוכן, וכן המרות והכנסות גבוהות יותר. Google מחקר הוכיח "...דפים שעברו אופטימיזציה נטענים פי ארבעה מהר יותר מהדף המקורי, ומשתמשים ב-80% פחות בייטים. בגלל שהדפים האלה נטענים כל כך מהר, ראינו גם עלייה של 50% בתנועה לדפים האלה."

ולמרות שמספר חיבורי 2G הוא בסוף דחייה, 2G עדיין הייתה הרשת הדומיננטית טכנולוגיה ב-2015. יותר ויותר רשתות 3G ו-4G זמינות עכשיו במהירות, אבל עלויות הבעלות ומגבלות הרשת המשויכות עדיין הוא גורם משמעותי עבור מאות מיליוני משתמשים.

אלו ארגומנטים חזקים לאופטימיזציה של דפים.

יש שיטות חלופיות לשיפור מהירות האתר ללא מפתחים ישירים מעורבות, כגון דפדפני proxy ושירותי המרת קידוד. למרות שכזה הם די פופולריים, ויש להם חסרונות משמעותיים — דחיסת תמונה וטקסט (ולפעמים בלתי מקובל), חוסר יכולת לעבד דפים מאובטחים (HTTPS), רק אופטימיזציה של דפים שביקרו בהם דרך תוצאת חיפוש, וכן עוד. מידת הפופולריות של שירותים אלו כשלעצמה היא סימן לכך שהאינטרנט מפתחים לא מתמודדים כראוי עם הביקוש הגבוה של המשתמשים למהירות ולמהירות נמוכה של Google Play ושל דפים. אבל השגת היעד הזה היא מורכבת ולפעמים נתיב קשה.

כותרת הבקשה Save-Data

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

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

תמיכה בדפדפנים

  • Chrome מגרסה 49 ואילך מפרסם את Save-Data כשהמשתמש מפעיל את 'חוסך הנתונים'. בנייד, או 'חוסך הנתונים'. בדפדפנים של מחשבים שולחניים.
  • Opera 35+ מפרסם את Save-Data כאשר המשתמש מפעיל "Opera Turbo" במחשב, או "Data savings" אפשרות בדפדפני Android.
  • Yandex 16.2+ מפרסם את Save-Data כאשר Turbo המצב הוא במחשב או בנייד דפדפנים.

מתבצע זיהוי של ההגדרה 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, וניתן ליישם כל פעולה של שמירת נתונים בתנאי הזה.


הכותרת Save-Data שמוצגת בכלים למפתחים ב-Chrome, עם התמונה
תוסף חוסך הנתונים (Data Saver).
הפעלת תוסף Data Saver ב-Chrome במחשב

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

טיפים ושיטות מומלצות להטמעה

  1. כשמשתמשים ב-Save-Data, צריך לספק כמה מכשירים עם ממשק משתמש שתומכים בכך ולאפשר למשתמשים כדי לעבור בקלות בין אפשרויות. מוצרים לדוגמה:
    • צריך להודיע למשתמשים על כך שיש תמיכה ב-Save-Data ולעודד אותם להשתמש בשירות.
    • המשתמשים יוכלו לזהות ולבחור את המצב באמצעות ההנחיות המתאימות וגם לחצני הפעלה/כיבוי או תיבות סימון.
    • כשבוחרים במצב חיסכון בנתונים, צריך להודיע ולספק דרך קלה וברורה להשבית אותו ולחזור לחוויה המלאה אם יש צורך.
  2. חשוב לזכור שאפליקציות קטנות הן לא אפליקציות פחות נמוכות. אבל הם לא להשמיט פונקציונליות או נתונים חשובים, הם פשוט מכירים יותר את העלויות הכרוכות בכך ואת חוויית המשתמש. לדוגמה:
    • אפליקציה של גלריית תמונות עשויה לספק תצוגות מקדימות ברזולוציה נמוכה יותר, או להשתמש בפחות מנגנון קרוסלה עמוסי קוד.
    • אפליקציית חיפוש עשויה להחזיר פחות תוצאות בכל פעם, וכך להגביל את מספר תוצאות עמוסות במדיה, או לצמצם את מספר יחסי התלות שנדרשים כדי לעבד הדף.
    • אתר שמתמקד בחדשות עשוי להציג פחות כתבות, להשמיט קטגוריות פחות פופולריות, או להציג תצוגות מקדימות קטנות יותר של מדיה.
  3. צריך לספק לוגיקת שרת כדי לבדוק את כותרת הבקשה של Save-Data ולשקול אם לספק תגובה חלופית וקלה יותר לדף כשהיא מופעלת – למשל, מפחיתים את מספר המשאבים וקשרי התלות הנדרשים, מיישמים שיטה אגרסיבית יותר דחיסת משאבים וכו'.
    • אם מוצגת תגובה חלופית שמבוססת על הכותרת Save-Data, זכרו להוסיף אותה לרשימה Vary – Vary: Save-Data כדי לציין המטמון ב-upstream, שצריך לשמור במטמון ולהציג את הגרסה הזו רק אם קיימת כותרת בקשה מסוג Save-Data. מידע נוסף זמין בשיטות המומלצות עבור אינטראקציה עם מטמון.
  4. אם משתמשים ב-Service Worker, האפליקציה יכולה לזהות מתי מתבצעת חיסכון בנתונים. האפשרות מופעלת על ידי בדיקת נוכחות הבקשה Save-Data הכותרת, או על ידי בדיקת הערך של navigator.connection.saveData לנכס. אם המדיניות מופעלת, צריך לבדוק אם אפשר לשכתב את הבקשה לאחזור פחות בייטים, או להשתמש בתגובה שכבר אוחזרה.
  5. מומלץ להוסיף את 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 Superglobal מערך באינדקסים החל מ-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) ותמונה נוספת בגודל כפול (2x) במסכים עם רזולוציה גבוהה (למשל 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
}

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

אפשר גם להרחיב את הקונספט הזה לנכסי 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 from Google גופנים באתר. 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.