Firefox มีแผนหยุดรองรับ HTTP/2 Push

 (groups.google.com)
1 คะแนน โดย GN⁺ 2024-09-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Firefox จะปิดใช้งาน HTTP/2 Push บนทุกแพลตฟอร์มภายในไม่กี่วัน เนื่องจากมีการใช้งานต่ำและภาระด้านความเข้ากันได้เพิ่มขึ้น ส่วนโค้ดการทำงานจะยังคงอยู่ใน tree ไปก่อนสักระยะ
  • ในระบบนิเวศของเบราว์เซอร์ การรองรับได้ลดลงไปแล้ว โดย Chrome 106 ปิดฟีเจอร์นี้ไปเมื่อเดือนกันยายน 2022 และ Safari เวอร์ชันล่าสุดก็ปฏิเสธ push stream ในการทดสอบภายในเครื่องเช่นกัน
  • Chrome ระบุเหตุผลว่า HTTP/2 Push มีการใช้งานต่ำ และแนะนำ rel="preload" กับ 103 Early Hints เป็นทางเลือกทดแทน
  • Firefox ยังคงรองรับต่อมาเพราะต้นทุนการดูแลรักษาไม่ได้สูงมาก แต่ในช่วงไม่กี่เดือนที่ผ่านมาเกิด บั๊กความเข้ากันได้ของเว็บที่เกิดเฉพาะใน Firefox เนื่องจาก HTTP/2 Push
  • หากเซิร์ฟเวอร์และเว็บไซต์ใช้ push แต่ข้ามการทดสอบบน Firefox เว็บไซต์บางแห่งอาจ ไม่ทำงานเฉพาะบน Firefox

แผนปิดใช้งาน HTTP/2 Push ของ Firefox

  • Firefox มีแผนจะปิดใช้งาน HTTP/2 Push บนทุกแพลตฟอร์ม
  • งานถอดออกถูกติดตามใน Bugzilla ที่ 1915848 - Pref off HTTP/2 push
  • ตอนนี้จะปิดผ่าน preference ก่อน และโค้ดการทำงานจะยังคงอยู่ใน tree ไปสักระยะ
  • การถอดออกอย่างสมบูรณ์มีแนวโน้มสูงว่าจะเกิดขึ้นก่อนการแตก branch ESR 140 ในฤดูใบไม้ผลิปีหน้า

สถานะการรองรับตามเบราว์เซอร์และเหตุผลในการปิดใช้งาน

  • Chrome

    • Chrome 106 ปิดใช้งาน HTTP/2 Push เมื่อเดือนกันยายน 2022
    • สามารถตรวจสอบสถานะที่เกี่ยวข้องได้ที่ Chrome Platform Status
    • Chrome ระบุเหตุผลว่าใช้งานต่ำ และแนะนำ rel="preload" กับ 103 Early Hints เป็นทางเลือกทดแทน

  • Safari

    • ยังไม่พบเอกสาร deprecation อย่างเป็นทางการ แต่เวอร์ชันปัจจุบันปฏิเสธ push stream ในการทดสอบภายในเครื่องด้วยเซิร์ฟเวอร์ Node.js

  • Firefox

    • Firefox ยังคงรองรับ HTTP/2 Push มาโดยตลอด เพราะภาระการดูแลรักษาไม่ได้สูงมาก
    • ในช่วงไม่กี่เดือนที่ผ่านมา HTTP/2 Push ก่อให้เกิด ปัญหาความเข้ากันได้ของเว็บ ที่ส่งผลต่อ Firefox เท่านั้น
      • กรณีที่เกี่ยวข้องคือ bug 1915830
      • หากเซิร์ฟเวอร์และเว็บไซต์ใช้ push แต่ไม่ได้ทดสอบบน Firefox เว็บไซต์อาจหยุดทำงานเฉพาะบน Firefox ได้ โดยมีตัวอย่างคือ bug 1913100

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-08
ความคิดเห็นจาก Hacker News

  • แม้หลังจากมี “การค้นพบแบบกะทันหัน” ว่า HTTP/2 Push สุดท้ายแล้วใช้ไม่ได้จริง ก็ยังไม่มีคำขอโทษใด ๆ ต่อคนที่อธิบายมานานแล้วว่าทำไมมันถึงไม่น่าจะเวิร์ก แต่กลับถูกเมิน ซึ่งน่าหงุดหงิดมาก
    บรรยากาศอยู่หลายปีคือพอคนที่ฉลาดกว่าของ Google บอกว่าจำเป็น ก็ยัดมันเข้าไปในสเปกได้เลย ทั้งที่ควรเข้าหาสเปกด้วยท่าทีอนุรักษนิยมกว่านี้มาก ควรเลิกเอา เป้าหมายขยายแบบคาดเดา ที่บางส่วนของ Google คิดว่าดีใส่เข้าไปเรื่อย ๆ ได้แล้ว

    • การปรับปรุง HTTP และประสิทธิภาพเว็บดูไม่ค่อยมีความหมายเท่าไรแล้ว เรามีแบนด์วิดท์มากพอสำหรับ สตรีมวิดีโอ 1080p อยู่แล้ว มี latency ต่ำพอสำหรับเล่นเกมแบบเรียลไทม์ และ CPU ก็แรงกว่าตอนที่เราออนไลน์ครั้งแรกถึง 1000 เท่า
      สิ่งที่ทำให้เบราว์เซอร์ช้าส่วนใหญ่ก็มีแค่โฆษณา ตัวติดตาม และขยะจิปาถะที่กดทับเว็บไซต์ไว้ และสิ่งที่ใช้แก้ปัญหานั้นไม่ใช่สิ่งประดิษฐ์ของ Google แต่คือ uBlock Origin ทุกวันนี้สิ่งที่ Google ผลักเข้าไปในมาตรฐานเว็บดูเหมือนไม่ได้ทำเพื่อให้นักพัฒนาทั่วไป แต่เพื่อใส่โฆษณาเพิ่ม หรือประหยัดต้นทุนดาต้าเซ็นเตอร์ 0.1% มากกว่า
    • เมื่อก่อนถ้าพูดใน HN ว่าสำหรับการใช้เว็บแบบไม่เน้นกราฟิก เช่น การค้นหาข้อมูลที่รวดเร็วและไม่ต้องโต้ตอบ HTTP/1.1 pipelining ให้ความรู้สึกน่าพอใจกว่า HTTP/2 ก็มักจะโดน downvote และตอบกลับแบบประชด
      HTTP/2 ดูเหมือนเป็นกรณีที่บริษัทเดียวพยายามควบคุมการเข้าถึงทรัพยากรสาธารณะอย่าง www ต่อไปให้สอดคล้องกับผลประโยชน์ของตัวเอง ถ้าใช้ Chrome ก็จะพยายามใช้ HTTP/2 และบริษัทเดียวกันนั้นก็ควบคุมทั้งเสิร์ชเอนจิน ฮาร์ดแวร์ เบราว์เซอร์ และตอนนี้ยังรวมถึงโปรโตคอลเครือข่ายด้วย HTTP/2 แทบจะมองได้ว่าเป็น HTTP/Chrome
    • โปรดเข้าใจว่าคนเหล่านั้นต้องการ เอกสารประกอบการเลื่อนตำแหน่งประจำปี จริง ๆ
    • ทายถูกเร็วเกินไปก็เท่ากับผิด

  • คำอธิบายที่ถูกยกมาเป็นเหตุผลว่า HTTP/2 Push ล้มเหลวไม่เคยรู้สึกน่าเชื่อถือเลย Google มักจะชี้ไปที่บทความของ Jake Archibald แต่บทความนั้นดูเหมือนเป็นการไล่รายการว่าการ implement ในเบราว์เซอร์แย่แค่ไหน มากกว่าจะเป็นเหตุผลว่าโปรโตคอลเองใช้ไม่ได้
    เบราว์เซอร์รองรับลิงก์ preload อยู่แล้ว และมันควรทำหน้าที่แทบเหมือนกับ Push header จึงสงสัยว่าปัญหาในการ implement เมื่อปี 2017 เช่น caching หรือ auth header ทำไมถึงเอาโค้ดจัดการ preload เดิมกลับมาใช้ซ้ำไม่ได้
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Preload header ไม่อาจมองว่า “แทบเหมือนกัน” กับ HTTP/2 Push ได้ ผลลัพธ์อาจคล้ายกัน แต่กลไกการทำงานต่างกัน และนอกจากส่วนผิวเผินมาก ๆ ที่ใช้คำว่า “Preload” แล้วก็ค่อนข้างต่างกันมาก
      HTTP/2 Push คือวิธีที่เซิร์ฟเวอร์ส่งทรัพยากรที่คิดว่าไคลเอนต์จำเป็นต้องใช้ไปให้ล่วงหน้า เพื่อลด round trip ลง 1 ครั้ง โดยมีเป้าหมายเพื่อลด latency ด้วยการส่งทรัพยากรแยกจาก pipeline DOM→render ส่วน Preload header คือวิธีที่เซิร์ฟเวอร์บอกพร้อมกับ body ว่ามีทรัพยากรใดควรโหลดแบบขนาน เพื่อให้ดึงมาก่อนการ parse หรือการ evaluate JS ส่วน 103 Early Hints จะส่ง hint ของ Preload ก่อนที่การสร้าง response จะเสร็จ และก่อน byte แรกของ body เพื่อเลื่อนขั้นตอนการ fetch ให้เร็วขึ้นอีก
      ความต่างหลักอยู่ที่เป็น server-driven หรือ client-driven และมาพร้อมกับ body หรือมาก่อน first byte เหตุผลที่ง่ายที่สุดว่าทำไม HTTP/2 Push ถึงทำเป้าหมายได้ไม่ดีคือเรื่อง cache เบราว์เซอร์จะไม่ขอทรัพยากรที่มีอยู่แล้ว แต่เซิร์ฟเวอร์ไม่รู้ว่าใน cache ของไคลเอนต์มีอะไร Push จึงมีความเสี่ยงสูงที่จะส่งทรัพยากรที่ไม่จำเป็น ส่วน 103/Preload ต่อให้เดาผิด สิ่งที่เสียไปก็แค่ header ไร้ประโยชน์ไม่กี่ไบต์ จึง implement ง่ายกว่าและต้นทุนต่ำกว่า
    • ความเข้าใจเกี่ยวกับสเปก Push สนิมขึ้นพอ ๆ กับตัวสเปกเลย ลืมไปว่าเซิร์ฟเวอร์จะ push เนื้อหาทั้งหมด ที่คาดว่าไคลเอนต์ต้องใช้จริง ๆ และเข้าใจผิดว่าใน request จะมีแค่ header ที่บอก dependency แบบ preload link
    • ด้วยเหตุผลด้านความปลอดภัย ทรัพยากรที่ถูก push ต้องถูกปฏิบัติเป็น กรณีพิเศษ จนกว่าหน้าจะดึงไปใช้ และหนึ่งในนั้นคือต้องมี cache แยกต่างหาก
    • ข้ออ้างในการถอด Push ออกนั้นน่าขันเป็นพิเศษ เพราะเดิมทีนักพัฒนาแทบไม่เคยได้โอกาสใช้ Push อย่างเหมาะสมเลย มองเห็น Push ที่เข้ามาก็ไม่ได้ และตอบสนองต่อมันก็ไม่ได้
      https://github.com/whatwg/fetch/issues/51
      แม้แต่กรณีใช้งานด้านการส่งมอบคอนเทนต์ที่ทุกคนให้ความสนใจ ก็ดูเหมือนว่ายังมีโอกาสอีกมาก ความพยายามที่มองเห็นได้ต่อสาธารณะก็มีไม่มาก และแทบไม่มีใครเข้าถึงไลบรารีหรือจุดเริ่มต้นสำหรับทดลองว่าควร Push อะไร

  • ด้วย HTTP/3 0-RTT startup อาจได้ความเร็วบางส่วนกลับคืนมา และด้วย 103 Early Hints ก็ทำให้เบราว์เซอร์ preload asset ได้เร็วขึ้น ชุดผสมนี้ยังมีข้อดีคือเข้ากันได้ย้อนหลังในเชิงความหมายกับ HTTP/1 และยังจัดการได้ง่ายกว่าใน reverse proxy หรือ load balancer

  • เห็นว่า HTTP/2 Push สุดท้ายกำลังหายไปก็รู้สึกเสียดายนิดหน่อย ไอเดียดูเรียบร้อยดี แต่การนำไปใช้ในเฟรมเวิร์กไม่ดีนัก และเป็นฟีเจอร์ที่น่าจะได้รับความสนใจมากกว่านี้
    ฝั่ง .NET สุดท้ายก็ไม่เคยปล่อยออกมา ส่วน nginx มี implementation พื้นฐานระดับหนึ่ง การไม่มี cache digest ก็เป็นอุปสรรคมาตลอด Chrome ถอดมันออกโดยให้เหตุผลบางส่วนทำนองว่า “ยังไงก็ไม่มีใครสังเกตอยู่แล้ว” และดูเหมือนว่างานออกแบบทุกอย่างใหม่บน UDP ซึ่งทำงานได้ยอดเยี่ยมเสมอหลัง NAT จะสำคัญกว่า

    • ไม่เคยเจอปัญหากับ UDP และ NAT เอง แต่ถ้ามันทำให้ผู้คนหงุดหงิดจนกระตุ้นให้เกิด การย้ายไป IPv6 ก็จะขอแอบยิ้มเงียบ ๆ

  • ตอนคุยกับ Mike Belshe ก่อนที่ HTTP/2 จะถูกทำเป็นมาตรฐาน ก็มีบรรยากาศอยู่แล้วว่าจะเอาฟีเจอร์นี้ออกจาก H2 เพราะทำให้เกิดประโยชน์จริงได้ยาก และมีปัญหากับกับดักเยอะ
    หนึ่งในปัญหาใหญ่ที่สุดคือ การ Push มากเกินไป เช่น ส่งสิ่งที่มีอยู่แล้วใน cache ของเบราว์เซอร์ หรือส่งคอนเทนต์ไม่สำคัญมากเกินไป จริง ๆ เคยเห็นกรณีแย่มากที่ Push ทำให้การโหลดหน้าเว็บช้าลงด้วย มีข้อเสนอให้เบราว์เซอร์บอกเซิร์ฟเวอร์ว่ามีอะไรอยู่ใน local cache บ้าง แต่ก็ชนปัญหาหลายอย่าง HTTP Early Hints และ Resource Hints ได้เข้ามาแทนที่ความจำเป็นของ H2 Push โดยรวม และ implement ได้ง่ายกว่ามาก หลีกเลี่ยงการ fetch ที่ไม่จำเป็น และเข้าใจง่ายกว่า

  • อาจตีความได้ว่า “ถ้าเว็บเซิร์ฟเวอร์และเว็บไซต์ใช้ Push แต่ไม่ทดสอบบน Firefox เว็บไซต์อาจค้างเฉพาะบน Firefox” แต่ก็มีการตีความแบบอื่นได้เช่นกัน
    ในขณะที่เบราว์เซอร์อื่นปฏิเสธ HTTP/2 Push แล้วเพิกเฉยไปเงียบ ๆ แต่ Firefox กลับพังอย่างหนักในบางเงื่อนไขขอบเขต เช่น เนื้อหาประมาณว่า “ดูเหมือน Firefox จะรีเซ็ตการเชื่อมต่อเมื่อเจอชื่อเฮดเดอร์ที่มีตัวพิมพ์ใหญ่”

    • การตีความนั้นไม่ค่อยตรงนัก เบราว์เซอร์อื่นต่างหากที่ไม่ได้ implement ตามสเปก ส่วน Firefox implement ตามสเปก สเปกระบุชัดเจนมากว่าต้องจัดการการละเมิดนี้อย่างไร ดังนั้น implementation ของเว็บเซิร์ฟเวอร์และเว็บไซต์เหล่านั้นจึงเป็นฝ่ายที่เสีย หากทดสอบกับไคลเอนต์ที่ปฏิบัติตามสเปก ก็น่าจะรู้ได้ว่ามันเสีย
    • ในบทความก็พูดไว้อย่างชัดเจน Firefox ยังรองรับ HTTP/2 Push ต่อไปเพราะต้นทุนการรองรับไม่ได้สูงมากจนถึงเมื่อไม่นานนี้ แต่ในช่วงไม่กี่เดือนที่ผ่านมา มี บั๊กด้านความเข้ากันได้ของเว็บที่กระทบเฉพาะ Firefox เกิดขึ้นผ่าน HTTP/2 Push
      บทความนี้ดูเหมือนจะอธิบายมาตรการนั้นเอง คือการปฏิเสธ H2 Push และเพิกเฉยไปเงียบ ๆ เหมือนเบราว์เซอร์อื่น ไม่ได้ดูเหมือนว่ากำลังปิดบังอะไร
    • เรื่องแบบกลับกันก็เกิดขึ้นได้ไม่ยากเช่นกัน สเปกใหม่ถูก implement แค่ในเบราว์เซอร์เดียว และบ่อยครั้ง Chrome มักปล่อยของที่ยังไม่สมบูรณ์ออกมาก่อน แล้วเซิร์ฟเวอร์ก็ implement มันผิดจนเกิดปัญหาแบบเดียวกัน

  • สงสัยว่าทำไม Push ถึงไม่ได้ถูกนำไปใช้แพร่หลายกว่านี้ ทั้งที่แม้จะมีข้อบกพร่องใหญ่ ๆ แต่มันก็เคยถูกมองว่าเป็นหนึ่งในเหตุผลสำคัญที่ทำให้ HTTP/2 เป็นฟีเจอร์เปลี่ยนเกม
    ไม่แน่ใจว่าเป็นเพราะเบราว์เซอร์รองรับไม่พอ หรือเพราะมันไม่เข้ากับ CDN กันแน่

    • เหตุผลที่ Server Push ไม่ได้ถูก deploy ในวงกว้างคือมันอาจเป็นผลเสียได้ เซิร์ฟเวอร์ผลัก asset ที่ไคลเอนต์อาจต้องใช้เข้าไป แต่ asset นั้นอาจมีอยู่แล้วในแคชของไคลเอนต์
      ในกรณีหลัง โดยเฉพาะบนมือถือ มันกลายเป็นภาระที่เป็นผลเสีย เซิร์ฟเวอร์ไม่มีทางรู้ได้อย่างแม่นยำเลยว่า asset นั้นจำเป็นต่อไคลเอนต์จริงหรือไม่ Early Hints น่าจะดีกว่า เพราะเมื่อเซิร์ฟเวอร์แจ้ง asset ที่จำเป็นให้เร็ว ไคลเอนต์ก็สามารถตัดสินใจได้ว่าจะดึงมา หรือมีอยู่แล้ว
    • เคยพิจารณาจะใช้แล้วเปลี่ยนใจ เมื่อมี request ไปยัง Index.html โดยปกติก็คงอยาก push script.js กับ style.css เข้าไป แต่แบบนั้นก็เท่ากับส่งข้อมูลไปหลายร้อย kbit
      ถ้าผู้ใช้ request index.html อีกครั้ง ควรต้องส่งทั้งหมดอีกไหม? ทรัพยากรมีโอกาสสูงที่จะอยู่ในแคชของผู้ใช้อยู่แล้ว ถ้าไม่ส่ง แล้วจะรู้ได้อย่างไรว่าควรส่งอะไร? มีแต่เบราว์เซอร์เท่านั้นที่รู้ว่าในแคชมีหรือไม่มีอะไร สุดท้ายตัวเลือกคือทำให้การเข้าชมครั้งแรกเร็ว แต่สิ้นเปลืองแบนด์วิดท์ในการกลับมาเข้าซ้ำ หรือปล่อยให้การเข้าชมครั้งแรกช้า แล้วทำให้การกลับมาเข้าซ้ำเร็ว
    • มันอาจเป็นฟีเจอร์เปลี่ยนเกมจริงก็ได้ แต่คงเป็นกรณีของบริษัทระดับ Google/Amazon/Meta หรือเล็กกว่านั้นเล็กน้อย
      สำหรับคนส่วนใหญ่ที่เหลือ มันคือ ความซับซ้อนที่เพิ่มขึ้นอย่างมหาศาล และโดยแทบทั้งหมดก็ถูกมองข้ามไป
    • อาจเป็นประโยชน์ถ้าดูบทวิเคราะห์ที่ละเอียดกว่าซึ่ง Chrome เผยแพร่ตอนตัดสินใจยุติการรองรับ Push
      https://developer.chrome.com/blog/removing-push/
    • ดูเหมือนว่าไม่ได้มีเวลาให้มากพอ Apache รุ่นแรกที่รองรับ HTTP/2 เพิ่งออกมาในปี 2015 ซึ่งเป็นปีที่ RFC ของ HTTP/2 เสร็จสิ้น และในปี 2017 ก็ยังมีความไม่สอดคล้องกันระหว่างเบราว์เซอร์เรื่องวิธีจัดการ Server Push
      การรองรับ Push ของ nginx ดูเหมือนจะเข้ามาราวปี 2018 ตามข้อมูลจากวิกิพีเดีย การเปลี่ยนแปลงแบบนี้ต้องใช้เวลากว่าจะไหลลงไปถึงเวอร์ชันของดิสโทรที่เสถียรและค่าเริ่มต้น ตัวผมเองก็เพิ่งเปิด HTTP/2 บนเซิร์ฟเวอร์ Apache ครั้งแรกในปี 2020 และแม้ในปี 2024 ก็ยังมีความเป็นไปได้ที่จะมีแอปพลิเคชันเซิร์ฟเวอร์ที่ไม่รองรับโดยตรง

  • …หมายถึง บน Firefox น่ะ

    • ดูเหมือนว่าที่อื่น ๆ จะถูกเอาออกไปหมดแล้ว

  • ดูเหมือนจะเป็นบทความที่เกี่ยวข้อง มีอีกไหม?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - สิงหาคม 2022, 201 ความคิดเห็น
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - กรกฎาคม 2022, 2 ความคิดเห็น
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - ธันวาคม 2020, 168 ความคิดเห็น
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - พฤศจิกายน 2020, 133 ความคิดเห็น
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - กันยายน 2020, 2 ความคิดเห็น
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - มกราคม 2020, 71 ความคิดเห็น
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - ตุลาคม 2018, 16 ความคิดเห็น
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - กุมภาพันธ์ 2018, 63 ความคิดเห็น
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - กรกฎาคม 2017, 23 ความคิดเห็น
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - พฤษภาคม 2017, 20 ความคิดเห็น
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - เมษายน 2017, 59 ความคิดเห็น
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - มีนาคม 2017, 2 ความคิดเห็น
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - กุมภาพันธ์ 2017, 9 ความคิดเห็น
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - สิงหาคม 2016, 6 ความคิดเห็น
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - สิงหาคม 2016, 25 ความคิดเห็น
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - สิงหาคม 2016, 2 ความคิดเห็น
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - กุมภาพันธ์ 2016, 13 ความคิดเห็น

  • ไม่น่าแปลกใจ ถ้าเอาฟีเจอร์ที่แทบไม่เกี่ยวกับเป้าหมายการออกแบบเดิมไปพ่วงไว้บนโปรโตคอลเดิมที่สร้างมาเพื่อวัตถุประสงค์เฉพาะ ก็มักจะออกมาแบบนี้
    ส่วนใหญ่แล้วควรเริ่มจากโปรโตคอลระดับต่ำแล้วปรับให้เข้ากับกรณีใช้งานโดยตรงจะดีกว่า และในแง่นั้นผมมองว่า WebSockets แก้ปัญหาการสื่อสารสองทางได้อย่างงดงามอยู่แล้ว ส่วนการลดดีเลย์ตอนโหลดลำดับชั้นไฟล์/สคริปต์ที่ลึก ๆ แท็ก rel="preload" หรือ rel="modulepreload" ก็เป็นโครงสร้างที่ยอดเยี่ยมและเรียบง่าย

    • HTTP/2 Push น่าจะเหมาะกับกรณีใช้งานเดียวกันพอดีกับ ลิงก์ preload ที่ลดดีเลย์
      ประเด็นคือให้เซิร์ฟเวอร์ส่งคอนเทนต์ที่ควรโหลดล่วงหน้าไปในเฮดเดอร์ เพื่อให้เริ่มโหลดล่วงหน้าได้ตั้งแต่ก่อนที่แท็กลิงก์จะถูกส่งหรือถูกพาร์ส สำหรับหน้าที่รองรับการสตรีมอาจมีประโยชน์น้อยกว่า แต่ในกรณีที่คำขอค้างอยู่จนกว่า HTML ทั้งหน้าจะเรนเดอร์ฝั่งเซิร์ฟเวอร์เสร็จ ก็อาจได้ประโยชน์ที่เห็นได้ชัด
    • HTTP/2 เป็นโปรโตคอลระดับต่ำตัวใหม่ และ HTTP Push ก็ไม่ได้เป็นฟีเจอร์เกี่ยวกับ การสื่อสารสองทาง มาตั้งแต่แรก
    • HTTP ก็เป็นการสื่อสารสองทางไม่ใช่เหรอ?