Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉
Der Sinn von HTTP/2 besteht darin, die Anzahl der Requests zu verringern.
Nicht nur, aber nehmen wir der Einfachheit halber mal an, es wäre der einzige Vorteil.
Insofern gibt es keinen Unterschied zu meiner Demo: Anstatt für 3 Images 3 Requests zu feuern ist nur noch ein Request erforderlich.
Insofern kannst Du das schon so sagen. Nur hast Du gleichzeitig eine Menge Nachteile gegenüber HTTP/2 im Gepäck. Beispiele:
- die Ressourcen können nicht mehr einzeln gecached werden
- du benötigst einen teuren Scriptprozess, um die Ressourcen serverseitig zusammenzupacken
- Bilder / Videos sind nicht mehr einzeln adressierbar
- ...
Ebenso wie bei HTTP/2 muss eine solche Vorgehensweise serverseitig unterstützt sein und auch das Protokoll muss bestimmte Voraussetzungen bieten.
Ja. Beinahe alle gängigen Clients können heute schon HTTP/2, einfach so. Wenn ich (du/er/sie/es) dann irgendwann auf dem Server HTTP/2 implementiere(aktiviere), dann funktioniert das. Einfach so!
Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren, die zwar das Ziel, mehrere Ressourcen mit einem Request zu übertragen ebenfalls erreicht, bezahlst das aber im Vergleich zu HTTP/2 mit heftigen Nachteilen.
Das bring mich zu meiner Eingangsfrage zurück: warum?