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