שרת proxy פרטי לשליפה מראש ב-Chrome

Katie Hempenius
Katie Hempenius
X
Kenji Baheux
Kenji Baheux
Michael Buettner
Michael Buettner

האצה של מדד ה-LCP באמצעות שליפה מראש (prefetch) מאתרים שונים.

החל מגרסת Chrome 103 ל-Android, נשיק בהדרגה ב-Chrome תכונה פרטית לשרת proxy לשליפה מראש (prefetch) כדי לזרז את הניווט המתמשך מחיפוש Google ומאתרים אחרים שמשתתפים בתוכנית ב-30% בחציון. תכונת שרת ה-proxy לשליפה מראש (prefetch) פרטית מאפשרת שליפה מראש (prefetch) של תוכן ממקורות שונים בלי לחשוף את פרטי המשתמשים לאתר היעד, עד שהמשתמשים מנווטים.

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

איך פועל שרת proxy לשליפה מראש (prefetch) באופן פרטי

ערוץ תקשורת מאובטח

בתכונה הזו נעשה שימוש בשרת proxy של CONNECT כדי ליצור ערוץ תקשורת מאובטח בין Chrome לבין השרת שמארח את התוכן לשליפה מראש (prefetch). ערוץ התקשורת המאובטח הזה מונע משרת ה-Proxy לבדוק כל העברת נתונים. חשוב לציין: למרות ששרת ה-Proxy לשליפה מראש (prefetch) הוא פרטי רואה בהכרח את שם המארח כדי ליצור ערוץ תקשורת מאובטח, הוא לא רואה את כתובות ה-URL המלאות או את המשאבים עצמם.

אנימציה שמציגה זרימת נתונים דרך שרת proxy.
שליפה מראש (prefetch) של אתרים דרך שרת proxy של CONNECT מונעת דליפה של פרטי משתמש.

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

לא ניתן לזהות את המשתמש

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

  • קובצי Cookie: בקשות לשליפה מראש (prefetch) לא יכולות להעביר קובצי Cookie.
    • אם למשאב מסוים יש קובץ cookie, Chrome יבצע אחזור ללא פרטי כניסה, אבל לא ישתמש בתגובה (מידע נוסף מפורט בהמשך בקטע שמירה במטמון).
    • אמנם התגובות לבקשת שליפה מראש (prefetch) יכולות לכלול קובצי cookie, אבל קובצי ה-cookie האלה יישמרו רק אם המשתמש ינווט לדף שנשלף מראש.
  • טביעת אצבע: גם משטחים אחרים שאפשר להשתמש בהם ליצירה של טביעת אצבע דיגיטלית מותאמים. לדוגמה, הכותרת User-Agent שנשלחת על ידי שרת proxy לשליפה מראש כוללת מידע מוגבל בלבד.

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

שמירה במטמון

Chrome יבצע שליפה מראש (prefetch) של משאבים גם אם הם כבר נמצאים במטמון, אבל הם לא יכללו כותרות מותנות כמו ETag או If-Modified-Since (אלה כוללים ערכים שהוגדרו על ידי השרת, שאפשר להשתמש בהם למעקב גם ללא קובצי cookie). השליפה מראש (prefetch) מתבצעת כדי למנוע דליפה של מצב המטמון של הלקוח לאתר שנשלף מראש. בנוסף, Chrome יבצע במטמון משאב שנשלף מראש רק אם המשתמש יחליט לעבור לאתר שנשלף מראש.

תחילת העבודה עם שרת proxy פרטי לשליפה מראש (prefetch)

לבעלי אתרים

בעלי האתרים לא צריכים לעשות שום דבר כדי להתחיל ליהנות משרת proxy פרטי לשליפה מראש (prefetch) של קישורים שעבורם למשתמש אין קובצי cookie או מצב מקומי. מהניסויים שערכנו, זו הזדמנות משמעותית עבור רוב האתרים. בנוסף, תמיד מומלץ להרשים את המבקרים בפעם הראשונה או את המבקרים הלא תדירים, וליהנות מחוויית טעינה מהירה במיוחד. מניסויים קודמים הראו מהירות גבוהה יותר ב-20% עד 30% במדד 'המהירות שבה נטען רכיב התוכן הכי גדול' (LCP) בניווטים עם אחזור מראש.

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

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

תוכן או שירותים התלויים במיקום גיאוגרפי

אם האתר שלכם מתנהג באופן שונה (לדוגמה, תוכן שונה או גישה סלקטיבית) בשווקים שונים על סמך כתובת ה-IP של המשתמש, ייתכן שתהיתם איך לטפל בבקשות לשליפה מראש (prefetch) של שרת proxy פרטי לשליפה מראש (prefetch). חשוב לדעת ששרת ה-proxy לשליפה מראש (prefetch) מופעל על ידי מספר שרתים ברחבי העולם, ושכתובת ה-IP של שרת ה-proxy תעבור מיקום גיאוגרפי למדינה שממנה המשתמש הפעיל שליפה מראש (prefetch).

לאור זאת, הנה ההמלצות שלנו:

  1. זיהוי בקשות לשליפה מראש משרת proxy לשליפה מראש (prefetch) באמצעות נוכחות של כותרת HTTP מסוג Sec-Purpose: Prefetch; anonymous-client-ip.
  2. יש לחפש את המיקום הגיאוגרפי של שרת ה-proxy הפרטי לשליפה מראש (prefetch) ששלח את הבקשה דרך כתובת ה-IP שלו. במשאב הזה תוכלו למצוא רשימה עדכנית של אזורים גיאוגרפיים שהושקו ואת כתובות ה-IP התואמות.
  3. מתן שירות למשאבים בהתאם לשוק הקשור למיקום גיאוגרפי ספציפי זה.

פיקוח תנועה

מניסויים שביצענו בעבר, אנחנו יודעים שהתכונה הזו בדרך כלל מובילה לעלייה של פחות מ-2% בבקשות נוספות למשאבים עיקריים (למשל, מסמכי HTML). עם זאת, אם אתם נוהגים בזהירות, תוכלו להשתמש בשדה השאלון של הייעוץ לגבי תנועה כדי לשלוט בכמות התנועה ששרת ה-proxy לשליפה מראש (prefetch) צריך לאפשר לו לעבור. אפשר להתחיל עם חלק קטן, כמו 0.3 (כלומר 30%), ולהגדיל אותו בהדרגה ל-1.0 (כלומר, 100%) על-ידי הוספת קובץ ה-JSON הבא לקובץ /.well-known/traffic-advice, שאותו יש להציג באמצעות סוג ה-MIME application/trafficadvice+json:

[{
  "user_agent": "prefetch-proxy",
  "fraction": 0.3
}]

השדה fraction הוא ערך צף בין 0.0 (ללא שליפה מראש כלל) ל-1.0 (100% מהבקשות לשליפה מראש מתקבלות).

אפשר גם להשבית זאת לחלוטין באמצעות ההגדרות הבאות:

[{
  "user_agent": "prefetch-proxy",
  "disallow": true
}]

הקובץ /.well-known/traffic-advice אוחזר על ידי שרת ה-proxy, לא הלקוח, ומאוחסן במטמון בשרת ה-proxy בהתאם לסמנטיקה הרגילה של מטמון HTTP. כדי לשפר את הגמישות – למשל, שיא פתאומי של גישה חזקה – כדאי לדחות באופן זמני בקשות לשליפה מראש (Sec-Purpose: prefetch;anonymous-client-ip) עם קוד סטטוס 503, ועל ידי הגדרת הכותרת Cache-Control: no-store בתגובה. אפשר גם להוסיף את הכותרת Retry-After כדי להגדיר ל-Chrome כמה זמן להמתין לפני ניסיון חוזר של בקשות לשליפה מראש (prefetch).

לבעלי אתרים מפנים

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

<script type="speculationrules">
{
  "prefetch": [
    "source": "list",
    "urls": ["https://example.com/index.html"],
    "requires": ["anonymous-client-ip-when-cross-origin"]
  ]
}
</script>

מה השלב הבא?

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

למידע נוסף