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

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

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

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

המשך לקרוא כדי ללמוד איך התכונה הזו פועלת ואיך היא יכולה לעזור בשיפור משמעותי של האתרים שלך' Largest Contentful Paint (LCP), או איך אתרים מפנים יכולים לעזור למשתמשים שלהם להשיג את היעדים שלהם על ידי האצת ניווטים באתרים שונים.

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

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

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

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

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

מניעת זיהוי משתמשים

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

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

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

שמירה במטמון

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

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

לבעלי אתרים

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

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

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

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

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

לכן, אחרי הדברים האלה, מומלץ לבצע את הפעולות הבאות:

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

פיקוח תנועה

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

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

השדה fraction הוא מספר ממשי (float) בין 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 כמה זמן לחכות לפני ניסיון חוזר של בקשות לשליפה מראש.

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

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

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

מה השלב הבא?

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

למידע נוסף