פיתוח אתרים שנטענים מהר בכל מקום יכול להיות משימה מורכבת. היכולות הרבות של המכשירים – ואיכות הרשתות שהם מתחברים אליהן – יכולות להפוך את המשימה למורכבת מאוד. אנחנו יכולים לנצל את התכונות של הדפדפן כדי לשפר את ביצועי הטעינה, אבל איך נדע מה היכולות של המכשיר של המשתמש או מה האיכות של חיבור הרשת שלו? הפתרון הוא רמזים ללקוח.
רמזים של לקוח הם קבוצה של כותרות בקשות HTTP שאפשר להפעיל, והן מספקות לנו תובנות לגבי ההיבטים האלה של מכשיר המשתמש והרשת שהוא מחובר אליה. על ידי גישה למידע הזה בצד השרת, אנחנו יכולים לשנות את האופן שבו אנחנו מספקים תוכן בהתאם לתנאים של המכשיר או הרשת. כך נוכל ליצור חוויית משתמש כוללת יותר.
הכול קשור למשא ומתן על תוכן
רמזים ללקוח הם שיטה נוספת של משא ומתן על תוכן, כלומר שינוי תגובות לתוכן על סמך כותרות של בקשות בדפדפן.
דוגמה אחת למשא ומתן על תוכן כוללת את כותרת הבקשה Accept. הוא מתאר אילו סוגים של תוכן הדפדפן מבין, והשרת יכול להשתמש במידע הזה כדי לנהל משא ומתן על התשובה. בבקשות לתמונות, התוכן של הכותרת Accept ב-Chrome הוא:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
כל הדפדפנים תומכים בפורמטים של תמונות כמו JPEG, PNG ו-GIF, אבל במקרה הזה, השדה Accept מציין שהדפדפן גם תומך ב-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 כשמשתמש מבקש משאב:
Accept-CH: Viewport-Width, Downlink
הערך של Accept-CH הוא רשימה מופרדת בפסיקים של רמזים מבוקשים שהאתר ישתמש בהם כדי לקבוע את התוצאות של בקשת משאב בהמשך. כשלקוח קורא את הכותרת הזו, הוא מקבל את ההודעה 'האתר הזה רוצה את רמזי הלקוח Viewport-Width ו-Downlink'. אין צורך להתייחס לרמזים הספציפיים עצמם.
נחזור אליהם עוד מעט.
אפשר להגדיר את כותרות ההסכמה האלה בכל שפת קצה עורפי. לדוגמה, אפשר להשתמש בפונקציה header של PHP.
אפשר אפילו להגדיר את כותרות ההסכמה האלה באמצעות המאפיין http-equiv
בתג <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
כל הרמזים על הלקוח (Client Hints)!
רמזים בצד הלקוח מתארים אחד משני דברים: המכשיר שבו המשתמשים משתמשים, והרשת שבה הם משתמשים כדי לגשת לאתר שלכם. בואו נסקור בקצרה את כל הרמזים שזמינים.
טיפים לגבי מכשירים
חלק מהרמזים ללקוח מתארים מאפיינים של המכשיר של המשתמש, בדרך כלל מאפייני המסך. חלק מהם יכולים לעזור לכם לבחור את מקור המדיה האופטימלי למסך של משתמש מסוים, אבל לא כולם מתמקדים במדיה.
לפני שנעבור לרשימה, כדאי להכיר כמה מונחים חשובים שמשמשים לתיאור של מסכים ורזולוציית מדיה:
גודל של פונקציות פנימיות (intrinsics): הממדים בפועל של משאב מדיה. לדוגמה, אם פותחים תמונה ב-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 פיקסלים במכשיר לכל פיקסל במסך (למשל, מסך Retina), והתמונה 2x מבוקשת. הגודל המקורי של התמונה אחרי תיקון הצפיפות 2x הוא 320x240, כי 640x480 חלקי 2 זה 320x240.
גודל חיצוני: הגודל של משאב מדיה אחרי ש-CSS וגורמים אחרים של פריסת הדף (כמו מאפייני width ו-height) הוחלו עליו. נניח שיש לכם רכיב <img> שמעלה תמונה עם גודל טבעי של 320x240 אחרי תיקון הצפיפות, אבל יש לו גם מאפייני CSS width ו-height עם ערכים של 256px ו-192px בהתאמה. בדוגמה הזו, הגודל החיצוני של הרכיב <img> הוא 256x192.
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 פיקסלים לוגיים עם DPR של 2. המכשיר טוען מסמך עם רכיב <img> שמכיל ערך מאפיין sizes שהוא 85vw (כלומר, 85% מרוחב אזור התצוגה בכל גדלי המסך). אם הלקוח הביע הסכמה לשימוש ברמז Width, הוא ישלח את הרמז הזה Width לשרת עם הבקשה לקבלת src של <img>:
Width: 544
במקרה הזה, הלקוח רומז לשרת שהרוחב האופטימלי של התמונה המבוקשת יהיה 85% מרוחב אזור התצוגה (272 פיקסלים) כפול DPR המסך (2), כלומר 544 פיקסלים.
ההינט הזה יעיל במיוחד כי הוא לא רק מתחשב ברוחב המסך אחרי תיקון הצפיפות, אלא גם משווה את נתון המידע החשוב הזה לגודל החיצוני של התמונה בפריסה. כך השרתים יכולים לנהל משא ומתן על תשובות של תמונות שיהיו אופטימליות גם למסך וגם לפריסה.
Content-DPR
כבר ידוע לכם שלמסכים יש יחס פיקסלים של המכשיר, אבל גם למשאבים יש יחסי פיקסלים משלהם. בתרחישי השימוש הפשוטים ביותר לבחירת משאבים, יחסי הפיקסלים בין המכשירים למשאבים יכולים להיות זהים. אבל! במקרים שבהם נעשה שימוש גם בכותרת DPR וגם בכותרת Width, הגודל החיצוני של משאב יכול ליצור תרחישים שבהם יש הבדל בין שני הערכים. כאן נכנס לתמונה הרמז Content-DPR.
בשונה מרמזים אחרים מצד הלקוח, Content-DPR היא לא כותרת בקשה לשימוש השרתים, אלא כותרת תגובה שהשרתים חייבים לשלוח בכל פעם שמשתמשים ברמזים DPR ו-Width כדי לבחור משאב. הערך של Content-DPR צריך להיות התוצאה של המשוואה הזו:
Content-DPR = [גודל משאב התמונה שנבחרה] / ([Width] / [DPR])
כשנשלחת כותרת בקשה של Content-DPR, הדפדפן יודע איך לשנות את גודל התמונה בהתאם ליחס הפיקסלים של המכשיר במסך ולפריסה. בלי זה,
יכול להיות שהתמונות לא ישתנו בהתאם לגודל.
Device-Memory
מבחינה טכנית, Device-Memory הוא חלק מ-Device Memory API, והוא חושף את נפח הזיכרון המשוער שיש למכשיר הנוכחי ב-GiB:
Device-Memory: 2
תרחיש שימוש אפשרי לרמז הזה הוא צמצום כמות ה-JavaScript שנשלחת לדפדפנים במכשירים עם זיכרון מוגבל, כי JavaScript הוא סוג התוכן הכי עתיר משאבים שהדפדפנים בדרך כלל טוענים. אפשר גם לשלוח תמונות עם DPR נמוך יותר, כי הן דורשות פחות זיכרון לפענוח.
הינטים לרשת
ממשק ה-API למידע על הרשת מספק קטגוריה נוספת של רמזים ללקוח שמתארים את הביצועים של חיבור הרשת של המשתמש. לדעתי, אלה הרמזים הכי שימושיים. בעזרתם, אנחנו יכולים להתאים את חוויית השימוש למשתמשים על ידי שינוי האופן שבו אנחנו מספקים משאבים ללקוחות בחיבורים איטיים.
RTT
הרמז RTT מספק את זמן ההלוך ושוב המשוער, באלפיות השנייה, בשכבת האפליקציה. ההצעה RTT, בניגוד ל-RTT של שכבת התעבורה, כוללת את זמן העיבוד של השרת.
RTT: 125
ההצעה הזו שימושית כי לזמן האחזור יש תפקיד בביצועי הטעינה.
באמצעות הרמז RTT, אנחנו יכולים לקבל החלטות על סמך מהירות התגובה של הרשת, מה שיכול לעזור להאיץ את ההצגה של חוויה שלמה (למשל, על ידי השמטה של חלק מהבקשות).
קישור למטה
השהיה חשובה לביצועי הטעינה, אבל גם רוחב הפס משפיע. Downlink הרמז, שמוצג במגה-ביט לשנייה (Mbps), חושף את המהירות המשוערת של ההורדה בחיבור של המשתמש:
Downlink: 2.5
בנוסף ל-RTT, Downlink יכול להיות שימושי לשינוי אופן העברת התוכן למשתמשים על סמך איכות החיבור לרשת.
שעון אקוודור
הרמז ECT מייצג את סוג החיבור בפועל. הערך שלו הוא אחד מהרשימה הממוספרת של סוגי החיבורים, שכל אחד מהם מתאר חיבור בטווחים שצוינו של ערכי RTT ו-Downlink.
הכותרת הזו לא מסבירה מה סוג החיבור בפועל – למשל, היא לא מדווחת אם השער הוא מגדל תקשורת או נקודת גישה ל-Wi-Fi. במקום זאת, הוא מנתח את זמן האחזור ורוחב הפס של החיבור הנוכחי וקובע לאיזה פרופיל רשת הוא הכי דומה. לדוגמה, אם מתחברים דרך Wi-Fi לרשת איטית, יכול להיות שהערך של ECT יהיה 2g, שהוא הקירוב הכי קרוב לחיבור האפקטיבי:
ECT: 2g
הערכים התקפים של ECT הם 4g, 3g, 2g ו-slow-2g. אפשר להשתמש ברמז הזה כנקודת התחלה להערכת איכות החיבור, ואז לשפר את ההערכה באמצעות הרמזים RTT ו-Downlink.
Save-Data
Save-Data הוא לא רמז שמתאר את תנאי הרשת, אלא העדפת משתמש שלפיה הדפים צריכים לשלוח פחות נתונים.
אני מעדיף לסווג את Save-Data כרמז לרשת, כי הרבה מהפעולות שאפשר לבצע איתו דומות לרמזים אחרים לרשת. סביר להניח שהמשתמשים יפעילו אותו גם בסביבות עם זמן אחזור גבוה או רוחב פס נמוך. אם יש רמז כזה, הוא תמיד נראה כך:
Save-Data: on
אצלנו ב-Google, דיברנו על מה שאפשר לעשות עם Save-Data.
ההשפעה של התוכן על הביצועים יכולה להיות משמעותית. זהו אות שבו המשתמשים מבקשים מכם באופן מילולי לשלוח להם פחות תוכן. אם תקשיבו לאות הזה ותפעלו בהתאם, המשתמשים יעריכו את זה.
סיכום של כל המידע
מה עושים עם רמזים ללקוח? זה תלוי בכם. הדוחות האלה מספקים הרבה מידע, ולכן יש לכם הרבה אפשרויות. כדי לקבל רעיונות, נראה מה רמזים ללקוח יכולים לעשות עבור Sconnie Timber, חברת עצים פיקטיבית שממוקמת באזור הכפרי של צפון-מערב ארה"ב. כמו שקורה לעיתים קרובות באזורים מרוחקים, החיבורים לרשת יכולים להיות לא יציבים. כאן טכנולוגיה כמו רמזים ללקוח יכולה לעשות הבדל משמעותי למשתמשים.
תמונות רספונסיביות
כל המקרים של שימוש בתמונות רספונסיביות, למעט המקרים הפשוטים ביותר, עלולים להיות מורכבים. מה קורה אם יש לכם כמה וריאציות של אותן תמונות עם שינויים שונים וגם בגדלים שונים של מסכים – וגם בפורמטים שונים? תגי העיצוב האלה מסתבכים מאוד מאוד
מהר.
קל לטעות, וקל לשכוח או לא להבין מושגים חשובים (כמו sizes).
אין ספק שהכלים <picture> ו-srcset הם מדהימים, אבל פיתוח ותחזוקה שלהם לתרחישי שימוש מורכבים יכולים להיות תהליכים ארוכים. אנחנו יכולים ליצור תגי עיצוב באופן אוטומטי, אבל גם זה מסובך כי הפונקציונליות של <picture> ושל srcset מורכבת מספיק כדי שהאוטומציה שלהם תתבצע בצורה שתשמור על הגמישות שהם מספקים.
אפשר לפשט את התהליך הזה באמצעות אותות בצד הלקוח (Client Hints). משא ומתן על תגובות עם תמונות באמצעות רמזים ללקוח יכול להיראות כך:
- אם זה רלוונטי לתהליך העבודה שלכם, קודם בוחרים טיפול בתמונה (למשל, תמונות עם בימוי אמנותי) על ידי סימון ההנחיה
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. הסקריפט מקבל שם של קובץ תמונה ופרמטרים נוספים כדי לבחור את התמונה הכי טובה בתנאים הנתונים.
השאלה הראשונה שלך היא כנראה “But isn’t this just reimplementing <picture> and srcset on the
back-end?”
במובן מסוים, כן – אבל יש הבדל חשוב: כשמשתמשים ברמזים של לקוח כדי ליצור תגובות מדיה, רוב העבודה (אם לא כולה) קלה יותר לאוטומציה, ויכולה לכלול שירות (כמו CDN) שיכול לעשות את זה בשבילכם. לעומת זאת, בפתרונות HTML צריך לכתוב תגי עיצוב חדשים כדי לספק מענה לכל תרחיש שימוש. כן, אפשר ליצור תגי עיצוב באופן אוטומטי. עם זאת, אם העיצוב או הדרישות שלכם ישתנו, סביר להניח שתצטרכו לחזור לאסטרטגיית האוטומציה שלכם בעתיד.
רמזים ללקוח מאפשרים להתחיל עם תמונה באיכות גבוהה ללא אובדן נתונים, שאפשר לשנות את הגודל שלה באופן דינמי כדי שתהיה אופטימלית לכל שילוב של מסך ופריסה. בשונה מ-srcset, שבו צריך לציין רשימה קבועה של תמונות אפשריות שהדפדפן יכול לבחור מתוכה, הגישה הזו גמישה יותר. בעוד ש-srcset מחייב אתכם להציע לדפדפנים קבוצה גסה של וריאציות – למשל, 256w, 512w, 768w ו-1024w – פתרון שמבוסס על רמזים ללקוח יכול להציג את כל הרוחבים, בלי ערימה ענקית של תגי עיצוב.
כמובן שאתם לא צריכים לכתוב בעצמכם את הלוגיקה לבחירת תמונות. Cloudinary משתמשת בהצעות ללקוח כדי ליצור תגובות של תמונות כשמשתמשים בפרמטר w_auto, ונמצא שמשתמשים ממוצעים הורידו 42% פחות בייטים כשמשתמשים בדפדפנים שתומכים בהצעות ללקוח.
אבל כדאי להיזהר! בגרסה 67 של Chrome למחשב, השינויים שבוצעו הסירו את התמיכה ברמזים ללקוח ממקורות שונים. למזלנו, ההגבלות האלה לא משפיעות על גרסאות Chrome לנייד, והן יוסרו לחלוטין מכל הפלטפורמות כשהעבודה על מדיניות התכונות תסתיים.
עזרה למשתמשים ברשתות איטיות
ביצועים דינמיים הוא הרעיון שאפשר לשנות את אופן אספקת המשאבים בהתאם למידע שזמין לנו באמצעות רמזים ללקוח, ובמיוחד מידע על המצב הנוכחי של חיבור הרשת של המשתמש.
באתר של Sconnie Timber, אנחנו נוקטים צעדים כדי להפחית את העומס כשהרשתות איטיות. לשם כך, אנחנו בודקים את הכותרות Save-Data, ECT, RTT ו-Downlink בקוד הקצה העורפי שלנו. אחרי שמסיימים את התהליך הזה, אנחנו יוצרים ציון איכות רשת שאפשר להשתמש בו כדי לקבוע אם כדאי להתערב כדי לשפר את חוויית המשתמש. הציון של הרשת הוא בין 0 ל-1, כאשר 0 הוא איכות הרשת הגרועה ביותר האפשרית ו-1 הוא האיכות הטובה ביותר.
בשלב הראשון אנחנו בודקים אם התג Save-Data קיים. אם כן, הציון מוגדר לערך 0, כי אנחנו מניחים שהמשתמש רוצה שנעשה כל מה שצריך כדי שהחוויה תהיה קלה ומהירה יותר.
אם Save-Data לא מופיע, אנחנו ממשיכים ושוקלים את הערכים של הרמזים ECT, RTT ו-Downlink כדי לחשב ציון שמתאר את איכות החיבור לרשת. קוד המקור ליצירת ציון הרשת זמין ב-Github. המסקנה היא שאם נשתמש ברמזים שקשורים לרשת באופן מסוים, נוכל לשפר את חוויית השימוש של מי שמשתמשים ברשתות איטיות.
כשאתרים מותאמים למידע שמועבר באמצעות רמזים ללקוח, אנחנו לא צריכים לאמץ גישה של 'הכול או כלום'. אנחנו יכולים להחליט בצורה חכמה אילו משאבים לשלוח. אנחנו יכולים לשנות את הלוגיקה של בחירת תמונות רספונסיביות כדי לשלוח תמונות באיכות נמוכה יותר לתצוגה מסוימת, וכך לשפר את מהירות הטעינה כשהאיכות של הרשת נמוכה.
בדוגמה הזו אפשר לראות את ההשפעה של רמזים ללקוח על שיפור הביצועים של אתרים ברשתות איטיות יותר. בהמשך מוצג תרשים waterfall של WebPagetest של אתר ברשת איטית שלא מותאם לרמזים של לקוחות:
ועכשיו, תרשים זרימה לאותו אתר באותו חיבור איטי, אבל הפעם האתר משתמש ברמזים מצד הלקוח כדי להסיר משאבים לא קריטיים בדף:
השימוש ברמזים ללקוח קיצר את זמן טעינת הדף מיותר מ-45 שניות ל-פחות מעשירית מהזמן הזה. אי אפשר להפריז בחשיבות היתרונות של רמזים ללקוח בתרחיש הזה, והם יכולים להיות משמעותיים למשתמשים שמחפשים מידע קריטי ברשתות איטיות.
בנוסף, אפשר להשתמש בהצעות ללקוח בלי לפגוע בחוויה של דפדפנים שלא תומכים בהן. לדוגמה, אם רוצים להתאים את אספקת המשאבים באמצעות הערך של הרמז ECT, ועדיין לספק את החוויה המלאה לדפדפנים שלא תומכים בכך, אפשר להגדיר חזרה לערך ברירת מחדל באופן הבא:
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
כאן, "4g" מייצג את חיבור הרשת באיכות הכי גבוהה שמתואר בכותרת ECT. אם נאתחל את $ect ל-"4g", לא תהיה השפעה על דפדפנים שלא תומכים בהצעות ללקוח. הסכמה לשימוש בנתונים היא הדרך הכי טובה!
שימו לב למטמון!
בכל פעם שמשנים תגובה על סמך כותרת HTTP, צריך לדעת איך מטמון יטפל באחזור עתידי של המשאב הזה. הכותרת Vary חיונית כאן, כי היא מקשרת בין רשומות במטמון לבין ערך כותרות הבקשה שסופקו לה. במילים פשוטות, אם אתם משנים תשובה כלשהי על סמך כותרת נתונה של בקשת HTTP, כמעט תמיד כדאי לכלול את כותרת הבקשה הזו ב-Vary, כך:
Vary: DPR, Width
עם זאת, יש כאן הערה חשובה: אף פעם לא כדאי Vary לשמור במטמון תגובות שאפשר לשמור במטמוןVary בכותרת שמשתנה לעיתים קרובות (כמו Cookie), כי המשאבים האלה הופכים למעשה לכאלה שלא ניתן לשמור במטמון. לכן, כדאי להימנע מVaryהסתמכות על כותרות של רמזים ללקוח כמו RTT או Downlink, כי אלה גורמים שקשורים לחיבור ויכולים להשתנות לעיתים קרובות. אם רוצים לשנות את התגובות בכותרות האלה, כדאי להשתמש רק בכותרת ECT, כדי לצמצם את מספר הפעמים שבהן לא נמצאים נתונים במטמון.
כמובן, זה רלוונטי רק אם אתם שומרים תגובה במטמון.
לדוגמה, לא נשמור במטמון נכסי HTML אם התוכן שלהם דינמי, כי זה עלול לפגוע בחוויית המשתמש בביקורים חוזרים. במקרים כאלה, אתם יכולים לשנות את התשובות האלה בכל דרך שנראית לכם נכונה, בלי להתייחס לVary.
רמזים על הלקוח (Client Hints) ב-Service Workers
משא ומתן על תוכן הוא לא רק לשרתים יותר! קובצי Service Worker פועלים כפרוקסי בין הלקוחות לבין השרתים, ולכן אתם יכולים לשלוט באופן שבו המשאבים מועברים באמצעות JavaScript. הנתונים האלה כוללים רמזים ללקוח. באירוע fetch של Service Worker, אפשר להשתמש בשיטה request.headers.get של האובייקט event כדי לקרוא את כותרות הבקשה של משאב, באופן הבא:
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!
})(),
);
});
אפשר לקרוא בצורה הזו כל כותרת של רמז לקוח שאתם בוחרים להשתמש בה. אבל זו לא הדרך היחידה לקבל חלק מהמידע הזה. אפשר לקרוא רמזים ספציפיים לרשת במאפייני JavaScript המקבילים האלה באובייקט navigator:
| רמז על הלקוח (Client Hint) | מקבילה ב-JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
ממשקי ה-API האלה לא זמינים בכל מקום, ולכן צריך לבדוק את התכונה באמצעות האופרטור in:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
מכאן אפשר להשתמש בלוגיקה דומה לזו שמשתמשים בה בשרת, אבל לא צריך שרת כדי לנהל משא ומתן על תוכן עם רמזים של לקוח. ל-Service Workers יש את היכולת לשפר את המהירות והיציבות של חוויית המשתמש, כי הם יכולים להציג תוכן גם כשהמשתמש במצב אופליין.
סיכום
בעזרת רמזים ללקוח, אנחנו יכולים לספק למשתמשים חוויות מהירות יותר באופן הדרגתי לחלוטין. אנחנו יכולים להציג מדיה על סמך היכולות של המכשיר של המשתמש, כך שקל יותר להציג תמונות רספונסיביות מאשר להסתמך על <picture> ועל srcset, במיוחד במקרים מורכבים. כך אנחנו יכולים לא רק לקצר את הזמן ולהקטין את המאמץ שנדרשים לפיתוח, אלא גם לבצע אופטימיזציה של משאבים – במיוחד תמונות – באופן שמכוון למסכים של המשתמשים בצורה מדויקת יותר ממה שאפשר לעשות באמצעות
יכול להיות שחשוב יותר מכך, אנחנו יכולים לזהות חיבורים חלשים לרשת ולגשר על הפער עבור המשתמשים על ידי שינוי של מה שאנחנו שולחים ואיך אנחנו שולחים את זה. השימוש בשיטה הזו יכול להקל מאוד על משתמשים ברשתות לא יציבות לגשת לאתרים. בשילוב עם service workers, אפשר ליצור אתרים מהירים במיוחד שזמינים במצב אופליין.
ההצעות ללקוח זמינות רק ב-Chrome ובדפדפנים שמבוססים על Chromium, אבל אפשר להשתמש בהן באופן שלא יפגע בדפדפנים שלא תומכים בהן. כדאי להשתמש ברמזים של לקוח כדי ליצור חוויות מותאמות וכוללות באמת, שמודעות ליכולות של המכשיר של כל משתמש ולרשתות שהוא מתחבר אליהן. אנחנו מקווים שספקי דפדפנים אחרים יראו את הערך שלהם ויביעו כוונה להטמיע אותם.
משאבים
- תמונות רספונסיביות אוטומטיות עם רמזים ללקוח
- רמזים ללקוח ותמונות רספונסיביות – מה השתנה ב-Chrome 67
- כדאי להשתמש באותות בצד הלקוח (Slides)
- הצגת אפליקציות מהירות וקלות משקל באמצעות
Save-Data
תודה לאיליה גריגוריק, אריק פורטיס, ג'ף פוזניק, יואב וייס ואסטל וייל על המשוב והעריכות החשובים שלהם במאמר הזה.