בהמשך להודעה הקודמת, התמיכה ב-HTTP/2 Server Push תושבת כברירת מחדל ב-Chrome 106 ובדפדפנים אחרים המבוססים על Chromium במהדורות הבאות שלהם.
למה התוכן הזה הוסר?
HTTP/2 Server Push אפשר לאתרים לשלוח באופן יזום את המשאבים הדרושים לדף, במקום להמתין לקבלת בקשה עבורם. עם זאת, הפתרון הזה היה בעייתי, כפי שכתב ג'ייק ארבורידג' בעבר, ולעיתים קרובות היה קשה לממש את יתרונות הביצועים. כתוצאה מכך, לא נעשה בה שימוש רב, ורק ב-1.25% מהאתרים שתומכים ב-HTTP/2 נעשה שימוש בתכונה הזו.
ניתוח השימוש בהקצאות שרת מוקדמות (Server Push) ב-HTTP/2 מניב תוצאות מעורבות (Chrome, Akamai), ללא שיפור ברור בביצועים ובמקרים רבים עם נסיגה בביצועים.
ההקצאה המוקדמת לא הופעלה בשרתים ובלקוחות רבים של HTTP/3, למרות שהיא נכללה במפרט. בחלק גדול מהאינטרנט שמשתמש ב-HTTP/3 החדש, כבר הוצאו משימוש את הבקשות להעברת הודעות. כשהרצנו מחדש את הניתוח הזה לאחרונה, ראינו שתמיכת HTTP/2 ב-1.25% מהאתרים ירדה ל-0.7%.
חלופות להקצאות שרת מוקדמות (Server Push) ב-HTTP/2
103 Early Hints היא חלופה עם סיכוי נמוך יותר לשגיאות, עם הרבה מהיתרונות של Push, ועם הרבה פחות מהחסרונות שלו. במקום שהשרת ידחוף משאבים, הודעה מסוג 103 Early Hints שולחת רק רמזים לדפדפן לגבי משאבים שיכול להיות שיועיל לבקש באופן מיידי. כך הדפדפן יכול להחליט אם הוא זקוק למשאבים האלה או לא – למשל, אם המשאבים האלה כבר נמצאים במטמון ה-HTTP.
טעינה מראש של משאבים קריטיים היא חלופה נוספת שמאפשרת לדף ולדפדפן לעבוד יחד כדי לטעון מראש משאבים קריטיים בשלב מוקדם של טעינת הדף. כדי להשתמש בשיטה הזו, צריך לשלוח קודם את הדף עצמו, ולכן היא לא מהירה כמו Server Push או Early Hints. עם זאת, היתרון הנוסף שלה הוא שהיא לא מעכבת את המשאב הקריטי של הדף, דבר שיכול לקרות בשני הפתרונות האלה.
סיכום
האינטרנט צריך להיות מסוגל לנסות דברים ולהיפטר מהם כשהם לא בשימוש. הפוטנציאל של Push נשמע מצוין, אבל בפועל השימוש בו היה בעייתי יותר מהצפוי. עם זאת, למדנו הרבה מ-Push, והתובנות האלה שימשו אותנו בתכנון של 103 Early Hints. עכשיו הגיע הזמן להשלים את התהליך ולהפסיק להשתמש ב-Push.
משאבים
- כל ההוצאות משימוש וההסרות ב-Chromium
- רשומה ב-ChromeStatus: הסרת HTTP/2 push
- כוונה להסרה: HTTP/2 ו-gQUIC server push
- בעיה ב-Chromium: השבתה של HTTP/2 Push כברירת מחדל