דף זה תורגם על ידי Cloud Translation API.

הסתגלות למשתמשים באמצעות רמזים ללקוחות

Jeremy Wagner

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

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

משא ומתן על תוכן

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

אחת הדוגמאות למשא ומתן לגבי תוכן כוללת Accept כותרת הבקשה. מוסבר בו איזה סוג תוכן הדפדפן מבין, וגם השרת יכול להשתמש בו כדי לנהל משא ומתן על התגובה. בבקשות לתמונות, התוכן מהכותרת Accept ב-Chrome היא:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

כל הדפדפנים תומכים בפורמטים של תמונות כמו JPEG , PNG ו-GIF, אבל הסכימה קובעת במקרה כזה הדפדפן גם תומך ב-WebP APNG. על סמך המידע הזה אנחנו יכולים לנהל משא ומתן על סוגי התמונות הטובים ביותר לכל דפדפן:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

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

הצטרפות

שלא כמו הכותרת Accept, רמזים ללקוח לא מופיעים באורח קסם (עם חריג ל-Save-Data, שעליו נדון מאוחר יותר). לטובת שמירה על כותרות של בקשות לכל הפחות, תצטרכו לבחור לאילו רמזים של לקוחות תשתמשו רוצים לקבל על ידי שליחת הכותרת Accept-CH כשמשתמש מבקש לקבל resource:

Accept-CH: Viewport-Width, Downlink

הערך של Accept-CH הוא רשימה מופרדת בפסיקים של הרמזים המבוקשים שהאתר ישמשו לקביעת התוצאות של בקשת המשאב הבאה. כאשר הלקוח קורא את הכותרת הזו ונאמר לו "האתר הזה רוצה את Viewport-Width ו-Downlink רמזים ללקוח". אל תדאגו לגבי הרמזים הספציפיים עצמם. תכף נטפל בהן.

אפשר להגדיר את הכותרות האלה לבקשת הסכמה בכל שפה של קצה עורפי. לדוגמה, PHP ניתן להשתמש בפונקציה header. אפשר אפילו להגדיר את כותרות בקשת ההסכמה האלה באמצעות http-equiv מאפיין בתג <meta>:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

אזהרה: גרסאות קודמות של המפרט כללו את הכותרת Accept-CH-Lifetime שהוסרה, וגם האתרים צריכים להפסיק לשלוח אותה. אם השתמשתם באפשרות הזו כדי לאפשר רמזים יישמרו במהלך סשנים בדפדפן, עליכם לוודא שאתם שולחים את כותרות Accept-CH הנדרשות בתשובות הרלוונטיות.

כל הרמזים ללקוח!

הרמזים של הלקוח מתארים אחד משני גורמים: המכשיר שבו המשתמשים משתמשים, ובכן, השימוש, הרשת שבה הם משתמשים כדי לגשת לאתר שלכם. נעבור בקצרה על כל רמזים זמינים.

טיפים לגבי מכשירים

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

לפני שניכנס לרשימה הזו, כדאי ללמוד על כמה מונחים עיקריים כדי לתאר מסכים ורזולוציית מדיה:

גודל פנימי: המידות בפועל של משאב מדיה. לדוגמה, אם פותחים תמונה ב-Photoshop, המימדים שמוצגים בתיבת הדו-שיח של גודל התמונה לתאר את הגודל הפנימי שלו.

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

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

נניח שהגודל הפנימי של התמונה 1x במקרה הזה הוא 320x240, והחלק הגודל הפנימי של התמונה 2x הוא 640x480. אם תגי העיצוב האלה מנותחים על ידי לקוח מותקנות במכשיר עם יחס פיקסלים של 2 במסך של המכשיר (למשל, צג רטינה) המסך), נדרשת התמונה של 2x. הגודל הפנימי שתוקן דחיסות של התמונה 2x היא בגודל 320x240, כי הגודל של 640x480 חלקי 2 הוא 320x240.

גודל חיצוני: הגודל של משאב מדיה אחרי CSS ופריסה אחרת גורמים (כמו מאפיינים width ו-height) הוחלו עליו. קדימה נניח שיש לכם רכיב <img> שטוען תמונה עם תיקון דחיסות הגודל הפנימי של 320x240, אבל יש לו גם מאפייני width ו-height של CSS עם ערכים של 256px ו-192px, בהתאמה. במשפט הזה, הגודל החיצוני של אותו רכיב <img> הופך ל-256x192.

איור של גודל פנימי לעומת
גודל חיצוני. תיבה בגודל 320x240 פיקסלים מוצגת עם התווית INTRINSIC
גודל. בתוכה יש תיבה קטנה יותר בגודל 256x192 פיקסלים, שמייצגת
רכיב img של HTML שהוחל עליו CSS. התווית 'חיצונית'
גודל. בצד ימין מופיעה תיבה שמכילה CSS על הרכיב
משנה את הפריסה של רכיב ה-img כך שהגודל החיצוני שלו יהיה שונה
מהגודל הפנימי שלו. — **איור 1**. איור של מאפיין מהותי לעומת גודל חיצוני. הגודל החיצוני של התמונה מקבל אחרי שגורמי הפריסה הוחלו עליו. במקרה הזה, המערכת תחיל את כללי ה-CSS של `width: 256px;` ו-`height: 192px;` ממיר תמונה בגודל פנימי של 320x240 לגודל חיצוני של 256x192.

לאחר שיש לנו מונחים ספציפיים, ניכנס לרשימת הכלים הספציפיים לקבלת רמזים ללקוחות.

רוחב אזור התצוגה

Viewport-Width הוא רוחב אזור התצוגה של המשתמש בפיקסלים ב-CSS:

Viewport-Width: 320

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

DPR

DPR, קיצור של יחס הפיקסלים של המכשיר, מדווח על היחס בין הפיקסלים הפיזיים ל-CSS פיקסלים במסך המשתמש:

DPR: 2

הרמז הזה שימושי כאשר בוחרים מקורות של תמונות שמתאימים לתמונה של המסך דחיסות פיקסלים (כמו מתארי x עושים זאת בsrcset ).

רוחב

הרמז Width מופיע בבקשות למשאבי תמונות שהופעלו על ידי <img> או <source> תגים באמצעות sizes . sizes מציין לדפדפן מה יהיה הגודל החיצוני של המשאב. התכונה Width משתמשת בגודל החיצוני הזה כדי לבקש תמונה בגודל מובנה היא אופטימלית לפריסה הנוכחית.

לדוגמה, נניח שמשתמש מבקש דף עם מסך רחב של 320 פיקסלים של CSS עם DPR של 2. המכשיר טוען מסמך עם רכיב <img> שמכיל ערך המאפיין sizes של 85vw (כלומר, 85% מרוחב אזור התצוגה לכולם בגדלים שונים). אם הרמז Width הוגדר, הלקוח ישלח הרמז הזה Width לשרת עם הבקשה עבור ה-src של <img>:

Width: 544

במקרה זה, הלקוח רומז לשרת שמאפיין מהותי אופטימלי הרוחב של התמונה המבוקשת יהיה 85% מרוחב אזור התצוגה (272 פיקסלים) כפול ערך ה-DPR של המסך (2), שווה ל-544 פיקסלים.

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

התפלגות תוכן

נכון שכבר ידוע למסכים יש יחס פיקסלים של המכשיר, אבל גם למשאבים יש יחסי פיקסלים משלהם. בתרחישים לדוגמה הפשוטים ביותר לבחירת משאבים, פיקסל היחסים בין מכשירים ומשאבים יכולים להיות זהים. אבל! במקרים שבהם שני סוגי האירועים הכותרות DPR ו-Width מופעלות, הגודל החיצוני של משאב יכול כדי ליצור תרחישים שבהם יש הבדל בין שני הסוגים. כאן הרמז לContent-DPR מתחיל לשחק.

בשונה מרמזים אחרים של לקוח, Content-DPR אינה כותרת בקשה לשימוש על ידי אבל שרתי כותרות תגובה חייבים לשלוח בכל פעם DPR Width רמזים משמשים לבחירת משאב. הערך של Content-DPR צריך היא התוצאה של המשוואה הזו:

Content-DPR = [הגודל של משאב התמונה שנבחר] / ([Width] / [DPR])

כשנשלחת כותרת בקשה של Content-DPR, הדפדפן יידע איך להתאים את הגודל את התמונה הנתונה ליחס הפיקסלים של המכשיר ולפריסה. בלי זה, ייתכן שקנה המידה של התמונות לא יהיה נכון.

זיכרון המכשיר

חלק טכני מזיכרון המכשיר API, Device-Memory חושף סכום משוער של זיכרון יש במכשיר הנוכחי GiB:

Device-Memory: 2

הערה: ניתן להשתמש במידע הזה כדי ליצור טביעות אצבע של משתמשים, לכן הערך של Device-Memory הוא גס באופן מכוון. הערכים החוקיים הם 0.25, 0.5, 1, 2, 4 ו-8.

תרחיש לדוגמה אפשרי לרמז זה הוא הפחתת כמות ה-JavaScript נשלחת לדפדפנים במכשירים בעלי זיכרון מוגבל, מכיוון ש-JavaScript הוא בדרך כלל, דפדפנים מסוג תוכן עתיר משאבים . לחלופין, אפשר לשלוח תמונות DPR נמוכות יותר כי הן משתמשות בפחות זיכרון כדי לפענח את הקוד.

טיפים לגבי הרשת

ה-Network Information API מספק עוד קטגוריה של רמזים ללקוח שמתארים את ביצועי הרשת של המשתמש חיבור כזה. לדעתי, אלה הרמזים הכי שימושיים. אנחנו מאפשרים להם יכולים להתאים אישית את החוויות למשתמשים באמצעות שינוי האופן שבו אנחנו מספקים ואת המשאבים שלהם ללקוחות בחיבורים איטיים.

RTT

הרמז RTT מספק את זמן הנסיעה המשוער, באלפיות שנייה, מופעל בשכבת האפליקציות. הרמז RTT, בשונה משכבת התעבורה RTT, כולל זמן העיבוד של השרת.

RTT: 125

הערה: כדי למנוע יצירה של טביעת אצבע דיגיטלית (fingerprinting), הערך של RTT יעוגל ל-25 אלפיות השנייה הקרובה ביותר.

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

קישור למטה

זמן האחזור חשוב בביצועי הטעינה, אבל רוחב הפס משפיע, גם. הרמז Downlink, שמבוטא במגה-ביט לשנייה (Mbps), חושף מהירות משוערת במורד הזרם של החיבור של המשתמש:

Downlink: 2.5

הערה: הערך של Downlink מעוגל למכפלה הקרובה ביותר של 25KB לשנייה. שוב, יצירה של טביעת אצבע דיגיטלית.

בשילוב עם RTT, Downlink יכול להועיל לשינוי אופן הפעולה של התוכן למשתמשים על סמך איכות החיבור לרשת.

שעון אקוודור

הרמז ECT הוא קיצור של Effective Connection Type. הערך שלו הוא אחד רשימה מוגדרת של סוגי חיבורים, שכל אחד מהם מתאר חיבור בטווחים שצוינו גם RTT וגם Downlink .

הכותרת הזו לא מסבירה מהו סוג החיבור בפועל – לדוגמה, הוא לא מדווח אם השער שלך הוא מגדל תקשורת או גישה ל-Wi-Fi לנקודה. במקום זאת, היא מנתחת את זמן האחזור ורוחב הפס של החיבור הנוכחי קובע את פרופיל הרשת שהוא הכי דומה לו. לדוגמה, אם תחבר דרך Wi-Fi לרשת איטית, השדה ECT עשוי להכיל את הערך 2g, שהוא המשוער הקרוב ביותר לחיבור האפקטיבי:

ECT: 2g

הערכים החוקיים עבור ECT הם 4g, 3g, 2g ו-slow-2g. הרמז הזה יכול להיות כנקודת התחלה להערכת איכות החיבור, שופרו בעזרת הרמזים של RTT ו-Downlink.

שמירת נתונים

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

הערה: מבין כל הרמזים של לקוחות, Save-Data הוא היחיד שלא ניתן להביע הסכמה לשימוש בו באמצעות Accept-CH. רק המשתמש יכול לקבוע אם הרמז הזה יישלח על ידי החלפת המצב של התכונה 'חוסך הנתונים' של Chrome במכשירי Android.

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

Save-Data: on

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

מחברים את כל המידע

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

תמונות רספונסיביות

כל התרחישים לדוגמה הפשוטים ביותר לשימוש בתמונות רספונסיביות יכולות להיות מורכבות יותר. מה אם יש מספר טיפולים וגם וריאנטים של אותן תמונות במסכים שונים גדלים וגם בפורמטים שונים? תגי העיצוב האלה נהיים מאוד מסובכים מאוד במהירות. קל לטעות, קל לשכוח או להבין לא נכון (כמו sizes).

<picture> ו-srcset הם ללא ספק כלים מדהימים, אבל הם יכולים להיות נדרש זמן רב בפיתוח ובתחזוקה של תרחישים מורכבים לדוגמה. אנחנו יכולים לבצע אוטומציה של תגי עיצוב, אבל הפעולה הזו היא גם קשה, כי האפשרויות של <picture> ו-srcset מורכבות מספיק כדי לאפשר אוטומציה לבצע באופן שישמור על הגמישות שהם מספקים.

אפשר לפשט את התהליך הזה בעזרת רמזים ללקוח. ניהול משא ומתן על תשובות לתמונות עם הלקוח רמזים יכולים להיראות כך:

אם רלוונטי לתהליך העבודה שלך, קודם צריך לבחור טיפול באמצעות תמונה (כלומר, תמונות עם גרפיקה) על ידי בדיקת הרמז Viewport-Width.
בוחרים רזולוציית תמונה על ידי בדיקת הרמז Width והרמז DPR. בחירה של מקור שמתאים לגודל הפריסה ולצפיפות המסך של התמונה (כמו לאופן הפעולה של התיאורים x ו-w ב-srcset).
צריך לבחור את פורמט הקובץ הכי אופטימלי שנתמך בדפדפן (בערך Accept ברוב הדפדפנים).

כאשר הלקוח הפיקטיבי של חברת העץ שלי היה חששי, פיתחתי ת הזהב תרחיש לבחירת תמונות רספונסיביות ב-PHP שמשתמש ברמזים של לקוחות. המשמעות היא במקום לשלוח את תגי העיצוב האלה לכל המשתמשים:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

הצלחתי להוריד את זה לערכים הבאים בהתבסס על התמיכה של כל דפדפן בנפרד:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

בדוגמה הזו, כתובת ה-URL /image היא סקריפט PHP ואחריו פרמטרים נכתב מחדש על ידי mod_rewrite. הוא לוקח שם קובץ של תמונה ופרמטרים נוספים כדי לעזור לסקריפט בקצה עורפי לבחור את התמונה הכי טובה בתנאים הנתונים.

הבנתי "אבל לא מדובר בהטמעה מחדש של <picture> ושל srcset Back-end?” היא השאלה הראשונה שלכם.

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

בעזרת הטיפים ללקוח אפשר להתחיל עם רזולוציה גבוהה, תמונה שאחריה ניתן לשנות את הגודל שלה באופן דינמי כדי שתהיה אופטימלית לכל שילוב של המסך והפריסה. בשונה מ-srcset, שם צריך למנות רשימה של אפשרויות לתמונות שהדפדפן יוכל לבחור מהן. להיות גמיש יותר. srcset מאלץ אותך להציע לדפדפנים קבוצה גסה של וריאציות - למשל, 256w, 512w, 768w ו-1024w - רמזים ללקוחות פתרון מבוסס יכול לשרת את כל הרוחב, ללא ערימה ענקית של סימונים.

כמובן שאתם לא צריכים לכתוב בעצמכם לוגיקה לבחירת תמונה. ענן משתמשת ברמזים ללקוח כדי ליצור תגובות לתמונות כשמשתמשים ב-w_auto פרמטר, גילינו שמשתמשים חציוניים הורידו 42% בייטים פחות כשהם השתמשו בדפדפנים תמיכה ברמזים של לקוחות.

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

עזרה למשתמשים ברשתות איטיות

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

כאשר מדובר באתר של Sconnie Timber, אנחנו נוקטים צעדים כדי להפחית את העומס הרשתות איטיות, והכותרות Save-Data, ECT, RTT ו-Downlink הן שבקוד העורפי שלנו. כך אנחנו יוצרים איכות רשת שבו נוכל להשתמש כדי לקבוע אם עלינו להתערב כדי לשפר את חוויית המשתמש חוויה אישית. ציון הרשת הזה הוא בין 0 ל-1, ו-0 הוא הגרוע ביותר באיכות רשת אפשרית, ו-1 היא הטובה ביותר.

קודם כול אנחנו בודקים אם Save-Data קיים. אם כן, הציון מוגדר כ- 0, כי אנחנו יוצאים מנקודת הנחה שהמשתמש רוצה שנעשה את מה שנדרש כדי יהיה קל ומהיר יותר.

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

השוואה בין אתרים שלא משתמשים בהם בלקוח
טיפים להתאמה לחיבור איטי לרשת (משמאל) ולאותו אתר
(ימין). — **איור 2**. דף 'מי אנחנו' עבור בעלי מקצוע לאתר העסקי שלו. חוויית הבסיס כוללת גופנים באינטרנט ו-JavaScript, כדי ליצור מודעות קרוסלה או אקורדיון, וגם תמונות תוכן. כל הדברים האלה אפשר להשמיט כשתנאי הרשת איטיים מדי וטוענים אותם במהירות.

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

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

מפל של WebPagetest של Sconnie
אתר עץ טוען את כל המשאבים על חיבור רשת איטי. — **איור 3**. אתר שטוען הרבה תמונות באתר, סקריפטים וגופנים שהחיבור שלהם איטי.

ועכשיו Waterfall של אותו אתר באותו חיבור איטי, מלבד הזמן, האתר משתמש ברמזים ללקוח כדי להסיר משאבים שאינם קריטיים בדף:

מפל של WebPagetest של Sconnie
אתר עץ המשתמש ברמזים של לקוח כדי להחליט לא לטעון משאבים לא קריטיים
חיבור איטי לרשת. — **איור 4**. אותו אתר באותו חיבור, רק המשאבים מסוג 'נחמדים' מוחרגים, לטובת בטעינה.

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

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

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

כאן, "4g" מייצג את החיבור לרשת באיכות הגבוהה ביותר כמו הכותרת ECT שמתארת. אם אנחנו מאתחלים את $ect לערך "4g", דפדפנים שלא תומכים בלקוח הרמזים לא יושפעו. הצטרפות ל-FTW!

שימו לב לקבצים השמורים!

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

Vary: DPR, Width

עם זאת, יש אזהרה גדולה בנושא הזה: אף פעם לא כדאי Vary לשמור במטמון תגובות בכותרת שמשתנה לעיתים קרובות (כמו Cookie), כי וכתוצאה מכך, המשאבים הופכים ללא ניתנים לשמירה במטמון. לאור מה שקרה, כדאי להימנע Vary בכותרות של טיפים ללקוח כמו RTT או Downlink, כי אלה שעלולים להשתנות בתדירות גבוהה. אם רוצים לשנות תגובות בכותרות האלה, לכן כדאי להקליד רק את הכותרת ECT, צמצום החמצות של מטמון.

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

טיפים ללקוחות ב-Service Worker

משא ומתן על תוכן כבר לא מיועד רק לשרתים! כי קובצי שירות (service worker) פועלים שרתי proxy בין לקוחות לשרתים, יש לכם שליטה על האופן שבו משאבים מועברים באמצעות JavaScript. זה כולל רמזים ללקוחות. בקובץ השירות (service worker) האירוע fetch, אפשר להשתמש באובייקט event request.headers.get כדי לקרוא כותרות בקשות של משאב, למשל:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

אזהרה: מכיוון שלא כל הדפדפנים תומכים ברמזים של לקוח, צריך לבדוק אילו ערכים מוחזרים ב-event.request.headers.get. גישה חלופית אפשרית היא להקליט שווי ערך של JS, כמו window.devicePixelRatio או window.innerWidth ל-IndexedDB, שניתן לגשת אליו בהיקף של Service Worker.

אפשר לקרוא באופן הזה כל כותרת של רמז ללקוח שמביעים הסכמה לשימוש בה. למרות שזאת לא הדרך היחידה לקבל חלק מהמידע הזה. רמזים ספציפיים לרשת אפשר לקרוא במאפייני JavaScript המקבילים הבאים באובייקט navigator:

יישומי פלאגין של Imagemin לסוגי קבצים.
רמז ללקוח	שווה ערך ל-JS
'ECT'	`navigator.connection.effectiveType`
RTT	`navigator.connection.rtt`
'שמירת נתונים'	`navigator.connection.saveData`
'קישור למטה'	`navigator.connection.downlink`
'זיכרון המכשיר'	`navigator.deviceMemory`

מכיוון שממשקי ה-API האלה לא זמינים בכל מקום שבו צריך לבדוק את התכונות, in אופרטור:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

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

סיכום

בעזרת רמזים ללקוחות, יש לנו את הכוח להפוך את החוויות למהירות עבור משתמשים ובצורה הדרגתית. אנחנו יכולים להציג מדיה על סמך המכשיר של המשתמש כך שקל יותר להציג תמונות רספונסיביות מאשר להסתמך על ב-<picture> וב-srcset, במיוחד בתרחישים מורכבים. זה מאפשר לנו כדי לצמצם לא רק את הזמן והמאמצים בצד הפיתוח, אלא גם לבצע אופטימיזציה באופן שמטרגט למסכים של משתמשים, במיוחד תמונות, יותר מכפי ש- ו-srcset יכולים.

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

אמנם רמזים ללקוח זמינים רק ב-Chrome — ומבוססים על Chromium דפדפנים — אפשר להשתמש בהם בצורה שלא גורמת למלכוד בדפדפנים שלא תומכים בהם. כדאי להשתמש ברמזים של לקוחות כדי ליצור חוויות שמעודדות את קבלת האחר וניתנת להתאמה, והן מודעות לכל מכשיר של משתמש ביכולות וברשתות שאליהן הם מתחברים. אני מקווה שספקי דפדפנים אחרים יראה את הערך שלהם ויראה כוונה ליישם אותם.

משאבים

תודה לאיליה גריגוריק, אריק פורטיס, ג'ף פוזניק, יואב Weiss ו-Estelle Weyl בשביל משוב ועריכות חשובות על המאמר הזה.