פיתוח של אתרים מהירים בכל מקום עלול להיות בעייתי. שפעת יכולות המכשירים – ואיכות הרשתות שהם מחברים ליצור רושם שמדובר במשימה שאי אפשר להתגבר עליה. אומנם נוכל לקחת את היתרון של תכונות הדפדפן לשיפור ביצועי הטעינה, איך אנחנו יודעים היכולות של המכשיר של המשתמש, או איכות הרשת חיבור? הפתרון הוא לקוח רמזים!
רמזים של לקוחות הם קבוצה של כותרות לבקשת 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" />
כל הרמזים ללקוח!
הרמזים של הלקוח מתארים אחד משני גורמים: המכשיר שבו המשתמשים משתמשים, ובכן, השימוש, הרשת שבה הם משתמשים כדי לגשת לאתר שלכם. נעבור בקצרה על כל רמזים זמינים.
טיפים לגבי מכשירים
חלק מהרמזים של הלקוח מתארים מאפיינים של המכשיר של המשתמש, בדרך כלל מסך למאפיינים. חלק מהם יכולים לעזור לך לבחור את משאב המדיה האופטימלי המסך של המשתמש, אבל לא כולם בהכרח ממוקדי מדיה.
לפני שניכנס לרשימה הזו, כדאי ללמוד על כמה מונחים עיקריים כדי לתאר מסכים ורזולוציית מדיה:
גודל פנימי: המידות בפועל של משאב מדיה. לדוגמה, אם פותחים תמונה ב-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.
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
תרחיש לדוגמה אפשרי לרמז זה הוא הפחתת כמות ה-JavaScript נשלחת לדפדפנים במכשירים בעלי זיכרון מוגבל, מכיוון ש-JavaScript הוא בדרך כלל, דפדפנים מסוג תוכן עתיר משאבים . לחלופין, אפשר לשלוח תמונות DPR נמוכות יותר כי הן משתמשות בפחות זיכרון כדי לפענח את הקוד.
טיפים לגבי הרשת
ה-Network Information API מספק עוד קטגוריה של רמזים ללקוח שמתארים את ביצועי הרשת של המשתמש חיבור כזה. לדעתי, אלה הרמזים הכי שימושיים. אנחנו מאפשרים להם יכולים להתאים אישית את החוויות למשתמשים באמצעות שינוי האופן שבו אנחנו מספקים ואת המשאבים שלהם ללקוחות בחיבורים איטיים.
RTT
הרמז RTT
מספק את זמן הנסיעה המשוער, באלפיות שנייה, מופעל
בשכבת האפליקציות. הרמז RTT
, בשונה משכבת התעבורה RTT, כולל
זמן העיבוד של השרת.
RTT: 125
הרמז הזה שימושי בגלל זמן האחזור של טעינת התפקיד.
באמצעות הרמז RTT
אנחנו יכולים לקבל החלטות על סמך הרספונסיביות של הרשת,
שיכולים לזרז את התהליך של העברת התוכן (למשל,
השמטה של חלק מהבקשות).
קישור למטה
זמן האחזור חשוב בביצועי הטעינה, אבל רוחב הפס משפיע,
גם. הרמז Downlink
, שמבוטא במגה-ביט לשנייה (Mbps), חושף
מהירות משוערת במורד הזרם של החיבור של המשתמש:
Downlink: 2.5
בשילוב עם 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
כרמז לרשת כי הרבה דברים
שאפשר לעשות איתו בדומה לרמזים אחרים של רשת. משתמשים עשויים להיות גם
שתפעיל אותו בסביבות של זמן אחזור גבוה/רוחב פס נמוך. הרמז הזה,
נראה כך:
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. המסקנה היא שאם נשתמש ברמזים שקשורים לרשת
חלק מהאופנה, אנחנו יכולים לשפר את החוויות לאנשים איטיים
עמוקה מאוד,
![השוואה בין אתרים שלא משתמשים בהם בלקוח
טיפים להתאמה לחיבור איטי לרשת (משמאל) ולאותו אתר
(ימין).](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-comparison-a-site-doe-b20caac28fc7f.png?authuser=5&hl=he)
כשאתרים מסתגלים למידע שמתקבל מהרמזים של לקוחות, אנחנו לא צריכים ליישם גישה של "הכול או כלום". באפשרותנו להחליט בצורה חכמה אילו משאבים שליחה. אנחנו יכולים לשנות את הלוגיקה שלנו לבחירת תמונות רספונסיביות כדי לשלוח תמונות באיכות נמוכה יותר תמונות לתצוגה נתונה כדי להאיץ את ביצועי הטעינה כשהאיכות של הרשת גרועה.
בדוגמה הזו, ניתן לראות את ההשפעה שיש לרמזים של לקוח כשמדובר שיפור הביצועים של אתרים ברשתות איטיות יותר. בהמשך מופיע בדיקת דף אינטרנט Waterfall של אתר ברשת איטית שלא מתאימה את עצמה לרמזים של לקוחות:
![מפל של WebPagetest של Sconnie
אתר עץ טוען את כל המשאבים על חיבור רשת איטי.](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-6bc17bbfd8c27.png?authuser=5&hl=he)
ועכשיו Waterfall של אותו אתר באותו חיבור איטי, מלבד הזמן, האתר משתמש ברמזים ללקוח כדי להסיר משאבים שאינם קריטיים בדף:
![מפל של WebPagetest של Sconnie
אתר עץ המשתמש ברמזים של לקוח כדי להחליט לא לטעון משאבים לא קריטיים
חיבור איטי לרשת.](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-3ba4268e712f2.png?authuser=5&hl=he)
השימוש ב'רמזים של לקוח' קיצר את זמן הטעינה של דף מ-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!
})(),
);
});
אפשר לקרוא באופן הזה כל כותרת של רמז ללקוח שמביעים הסכמה לשימוש בה. למרות שזאת
לא הדרך היחידה לקבל חלק מהמידע הזה. רמזים ספציפיים לרשת
אפשר לקרוא במאפייני JavaScript המקבילים הבאים באובייקט navigator
:
רמז ללקוח | שווה ערך ל-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
, במיוחד בתרחישים מורכבים. זה מאפשר לנו
כדי לצמצם לא רק את הזמן והמאמצים בצד הפיתוח, אלא גם לבצע אופטימיזציה
באופן שמטרגט למסכים של משתמשים, במיוחד תמונות,
יותר מכפי ש-
יותר חשוב מזה, נוכל לאתר חיבורים חלשים לרשת את הפער בנתונים של המשתמשים, באמצעות שינוי של המידע שאנחנו שולחים והאופן שבו אנחנו שולחים אותו. מי יכול יש דרך ארוכה בגישה לאתרים עבור משתמשים ברשתות שביריות. בשילוב עם עובדי שירות, אנחנו יכולים ליצור אתרים מהירים להפליא זמין במצב אופליין.
אמנם רמזים ללקוח זמינים רק ב-Chrome — ומבוססים על Chromium דפדפנים — אפשר להשתמש בהם בצורה שלא גורמת למלכוד בדפדפנים שלא תומכים בהם. כדאי להשתמש ברמזים של לקוחות כדי ליצור חוויות שמעודדות את קבלת האחר וניתנת להתאמה, והן מודעות לכל מכשיר של משתמש ביכולות וברשתות שאליהן הם מתחברים. אני מקווה שספקי דפדפנים אחרים יראה את הערך שלהם ויראה כוונה ליישם אותם.
משאבים
- תמונות רספונסיביות אוטומטיות בעזרת הלקוח רמזים
- טיפים של לקוחות ותמונות רספונסיביות – מה השתנה ב-Chrome 67
- קבלו רמז (לקוח)! (Slides)
- אספקת אפליקציות מהירות וקלות באמצעות
Save-Data
תודה לאיליה גריגוריק, אריק פורטיס, ג'ף פוזניק, יואב Weiss ו-Estelle Weyl בשביל משוב ועריכות חשובות על המאמר הזה.