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

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

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

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

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

איך פועל שרת proxy של אחזור מראש פרטי

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

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

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

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

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

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

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

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

שמירה במטמון

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

תחילת העבודה עם שרת proxy פרטי ל-prefetch

לבעלי אתרים

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

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

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

תוכן או שירותים שמוגבלים לאזור גיאוגרפי מסוים

אם האתר שלכם מתנהג בצורה שונה (למשל, תוכן שונה או גישה סלקטיבית) בשווקים שונים על סמך כתובת ה-IP של המשתמש, יכול להיות שתתהו איך לטפל בבקשות של שרת proxy לאינטרנט פרטי לטעינה מראש. חשוב לדעת ששרת ה-proxy של אחסון נתונים מראש פרטי מופעל על ידי כמה שרתים ברחבי העולם, ושכתובת ה-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 הוא מספר צף בין 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 פרטי של אחזור מראש' כדי לזרז את הניווטים האלה בין מקורות שונים. כדי ש-Chrome ידע איזה דף כדאי לו לבצע לו אחסון מקדים דרך שרת proxy לאחסון מקדים פרטי, תצטרכו להוסיף לדפים כללים של ספקולציה. הנה דוגמה פשוטה:

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

מה השלב הבא?

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

למידע נוסף