Also technisch für den Betreiber einer Webseite macht das Attribut loading="lazy" eigentlich nur Sinn, wenn er vorher nichts getan hat und zugleich seine Seiten jeweils sehr lang sind. Wenn bereits ein IntersectionObserver läuft, dann erzeugt das neue Attribut eigentlich mehr Serverlast, weil mehr Daten geladen werden, direkt. Bei den meisten Seiten, die eine gewisse Höhe nicht überschreiten, ändert sich damit gar nichts. Die sparen keine Datenlast und keine Ladezeit ein.
Bei mir lädt der IntersectionObserver z.B. Bilder erst, wenn sie 20px unterhalb oder oberhalb vom Viewport sind. Mit loading="lazy" hat man diese Option nicht, man kann es nicht steuern, es kommt nativ aus Chrome oder Opera. Sie Serverlast steigt also. Im Vergleich: Der Aufruf einer Bildergalerie bei mir (ohne Scrollen, 4k Monitor, 24 Zoll): Mit IntersectionObserver: 4 Bilder, mit loading="lazy" 18 Bilder. Es sind nur 4 Bilder direkt sichtbar, die anderen unterhalb. Natürlich steigt damit auch das zu übertragende Datenvolumen, und die Seite wird langsamer.
Den IntersectionObserver kann man also steuern, das Attribut "loading" nicht, das gibt der Browser-Hersteller vor. Aber auch dort gibt es einen "threshold", der meiner Meinung nach aber viel zu hoch ist. Vorteil dennoch, er variiert ja nach Verbindung. Also Mobil mit langsamen oder schnellem Netz, 2G, 3G, 4G etc. Was auch immer der Browser erkennt, er verwendet einen anderen Wert. Dennoch sind alle irgendwie viel zu hoch.
Aktuell zum Beispiel, im Chrome 78:
Unbekannte Verbindung: 5000px
Offline gespeichert: 8000px
Langsames 2G: 8000px
Normales 2G: 6000px
3G: 4000px
4G: 3000px
Diese Daten stammen direkt aus dem Quellcode von Chromium und sind von Chrome und Opera so übernommen. Sie sind für Bilder. Für iFrames gibt es andere, aber eigentlich auch zu hoch.
Klar, eine langsame Verbindung muss früher laden, dass das Bild da ist, wenn der User da hin scrollt. Bei IntersectionObserver oder LazyLoad per JS kann es passieren, dass das Bild in den Viewport kommt, aber denn 5 Sek braucht, bis es geladen wird. Das verhindert das Attribut loading="lazy" damit, dass es früher lädt. Es ignoriert aber, ob ein User vielleicht direkt abspringt und gar nicht interagiert mit der Seite. Aber dennoch finde ich das hoch angesetzt. Für einen mit langsamen 2G, also GPRS, bedeutet das, dass der auf eine Seite geht und alles geladen wird, was irgendwie 8000px entfernt vom Screen ist, was bei den meisten Seiten ALLES sein dürfte. Für die Nutzung ist das sicherlich gut, für die Datenübertragung und Ladezeit nicht. ("Für die Nutzung ist das sicherlich gut", weil loading="lazy" priorisiert. Das was am nächsten ist sofort, das andere direkt danach - dennoch ist es Traffik extra)
Erstaunlich ist dennoch, und daher auch der andere Post, dass es wohl keine Rolle spielt, wann was geladen ist und wie viel es an Datenvolumen braucht. Wichtig ist, es ist da, wenn der User es "sehen könnte". Da sind wird also wieder im Bereich "FID". Und ja, der wird besser, obwohl sich Ladezeit und Datenvolumen verschlechtern. Das Gesamtergebnis der Auswertung ist aber besser. Die Prioritäten scheinen sich also verschoben zu haben.
Anderes Thema, später. Auslagerung von CPU-Aktivität, die auch eine Rolle in der Auswertung spielt, auf die GPU des Rechners. Auch dafür gibt es was Neuest, vorgestern erst zufällig gesehen, wobei das eine CSS-Anweisung ist.