הסרת HTTP/2 Server Push מ-Chrome

Barry Pollard

בהמשך להודעה הקודמת, התמיכה ב-HTTP/2 Server Push תושבת כברירת מחדל ב-Chrome 106 ובדפדפנים אחרים המבוססים על Chromium במהדורות הבאות שלהם.

למה התוכן הזה הוסר?

HTTP/2 Server Push אפשר לאתרים לשלוח באופן יזום את המשאבים הדרושים לדף, במקום להמתין לקבלת בקשה לכך. עם זאת, הדבר היה בעייתי כפי שג'ייק ארצ'יבלד כתב על הנושא בעבר, ולרוב היה קשה לממש את היתרונות בביצועים. כתוצאה מכך, לא נעשה בה שימוש רב, ורק ב-1.25% מהאתרים שתומכים ב-HTTP/2 נעשה שימוש בתכונה הזו.

ניתוח השימוש ב-HTTP/2 Server Push הוביל לתוצאות שונות (Chrome, Akamai), ללא עלייה ברורה בביצועים נטו ובמקרים רבים, רגרסיות של ביצועים.

ההקצאה המוקדמת לא הופעלה בשרתים ובלקוחות רבים של HTTP/3, למרות שהיא נכללה במפרט. בחלק גדול מהאינטרנט שמשתמש ב-HTTP/3 החדש, כבר הוצאו משימוש את הבקשות להעברת הודעות. כשהרצנו מחדש את הניתוח הזה לאחרונה, ראינו שתמיכת HTTP/2 ב-1.25% מהאתרים ירדה ל-0.7%.

חלופות להקצאות שרת מוקדמות (Server Push) ב-HTTP/2

103 Early Hints היא חלופה עם פחות סיכוי לשגיאות, עם הרבה מהיתרונות של Push, ועם הרבה פחות מהחסרונות שלו. במקום שהשרת ידחוף משאבים, הודעה מסוג 103 Early Hints שולחת רק רמזים לדפדפן לגבי משאבים שיכול להיות שיועיל לבקש באופן מיידי. כך הדפדפן יכול להחליט אם הוא זקוק למשאבים האלה או לא – למשל, אם המשאבים האלה כבר נמצאים במטמון ה-HTTP.

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

סיכום

האינטרנט צריך להיות מסוגל לנסות דברים ולהיפטר מהם כשהם לא בשימוש. הפוטנציאל של Push נשמע מצוין, אבל בפועל השימוש בו היה בעייתי יותר מהצפוי. עם זאת, למדנו הרבה מ-Push, והתובנות האלה שימשו אותנו בתכנון של 103 Early Hints. עכשיו הגיע הזמן להשלים את התהליך ולהפסיק להשתמש ב-Push.

משאבים