Ich kann nicht erklären, warum HTTP/1.1 manchmal verwendet wird, aber nicht die anderen basierend auf den begrenzten Informationen, die Sie in Ihren Screenshots angegeben haben, da dies nicht passieren sollte.
Sind Sie 100% sicher, dass sie beide denselben Ursprung haben? Werden die Ressourcen möglicherweise aus dem Cache bereitgestellt und wurden sie unter HTTP/1.1 zwischengespeichert?
An einem anderen Punkt, warum fordern Sie die gleiche Quelle zweimal innerhalb der gleichen Seite laden, wie auch immer das scheint falsch? Angemessen genug für Daten, die sich ändern (z. B. JSON-Anforderungen), aber nicht verstehen, warum Sie jQuery-UI mehrere Male oder sogar die gleiche CSS-Datei laden würden, wie Sie es anscheinend tun? Scheint ein sehr seltsamer Anwendungsfall und zumindest sollten Sie es zwischenspeichern, um es wieder zu verwenden.
Zu Ihrer zweiten Frage, unter HTTP/2 wird dieselbe Verbindung für den gleichen Ursprung wiederverwendet (und dies beinhaltet die gleichen Effektursprünge in bestimmten Anwendungsfällen, wenn Sie einen separaten vhost unter derselben IP-Adresse mit demselben https-Zertifikat haben) . Dies führt nicht zu einem Leiter der Leitungsblockierung, da das HTTP/2-Protokoll speziell für dieses Szenario entwickelt wurde und Multiplexing verwendet, um Anforderungen zu mischen.
Dies ändert jedoch das Profil der Anforderungen in den Dev Tools je nach Client, Server und Bandbreite. Angenommen, Sie haben eine Anforderung für zwei Ressourcen, die jeweils 5 Sekunden zum Herunterladen benötigen. Unter HTTP/1.1 Sie sehen würden:
Beispiel
Request 1: start 0 seconds, end 5 seconds.
Request 2: start 5 seconds, end 10 seconds.
Total time to download could be calculated as: 5s + 5s = 10s
Overall Page load time would be 10 seconds
Unter HTTP/2 Sie können sehen dies (unter der Annahme erste Anforderung priorisiert wurde vollständig zuerst zurückgeschickt werden):
Beispiel 2a
Request 1: start 0 seconds, end 5 seconds.
Request 2: start 0 seconds, end 10 seconds.
Total time **looks** be 5s + 10s = 15s
Overall Page load time would still be 10 seconds
Oder alternativ könnte es so aussehen, wenn Sie genug haben b andwidth um beiden Anfragen im Flug bei gleichzeitig handhaben und wenn Server antwortet mit zweiter Anforderung eine Sekunde später als die ersten:
Beispiel 2b
Request 1: start 0 seconds, end 5 seconds.
Request 2: start 0 seconds, end 6 seconds.
Total time **looks** be 5s + 6s = 11s
Overall Page load time would be 6 seconds
Der Punkt wird sowohl „Look“ langsamer unter HTTP/2 , wenn Sie versuchen, die Teile zu summieren, obwohl die Gesamtzeit für Beispiel 2a gleich ist und tatsächlich 4 Sekunden schneller für Beispiel 2b. Sie können einzelne Anforderungen in Like-for-Like-Datenbanken in Developer-Tools nicht zwischen HTTP/1.1 und HTTP/2 vergleichen.
Dies ist der gleiche Weg wie der Vergleich mehrerer HTTP/1.1 Anfragen (Browser öffnen normalerweise 4-8 Verbindungen pro Host statt nur einer), außer dass es keinen Overhead zum Öffnen und Verwalten mehrerer Verbindungen unter HTTP/2 seit dem Brennen gibt in das Protokoll. Und es gibt keine 4-8 Grenze unter HTTP/2, durch Browser und Server wird oft eine implementiert Apache defaults to 100 for example).
Ich sage alles, was ich noch denke, es gibt noch viele Optimierungen auf Client und Server, um das meiste aus HTTP/2 herauszuholen. Das Internet wurde auch stark für HTTP/1.1 optimiert und wie es funktionierte, so dass einige dieser Dinge möglicherweise rückgängig gemacht oder zumindest optimiert werden müssen, um den größten Teil von HTTP/2 zu machen. Zum Beispiel lädt eine Seitenladung typischerweise HTML, dann CSS, dann Bilder, was natürlich zu einer Priorität führt. Unter HTTP/2 können Sie alle Assets gleichzeitig anfordern, sollten aber das CSS zum Beispiel über die Bilder priorisieren. Die meisten Browser tun dies, aber tun sie es auf die optimale Weise?
Haben Sie jemals eine Lösung dafür gefunden? Ich habe ein ähnliches Problem – Jimbo