nicht angemeldet
AugeHallo
Was mir an dieser Art der Optimierung schwer missfällt: dabei wird nur das Bedürfnis der Seitenbetreiber bedacht: Nutzer so lange wie möglich auf einer Seite zu halten.
Klar Nutzer sind weg, wenn sie zu lange warten müssen, wollen also selber auch, dass etwas schnell erscheint.
Aber: lazy loading macht große Datenmengen schwerer identifizierbar.
Bedeutet: man hat das Gefühl, dass man auf einer leichten (weil flotten) Seite untergwes ist und dabei wird im Hintergrund ständig fleißig teures Datenvolumen verbraten.
Die Begründung für das Attribut, das im web.dev-Artikel, transportiert über die Frage „Why native lazy-loading?“, geliefert wird, erscheint mir in dieser Hinsicht auch recht blauäugig.
„According to HTTPArchive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send about 4.7 MB of images on desktop and mobile. That's a lot of cat pictures.
Embedded iframes also use a lot of data and can harm page performance. Only loading non-critical, below-the-fold images and iframes when the user is likely to see them improves page load times, minimizes user bandwidth, and reduces memory usage.“
Was ändert sich mit Lazy Loading am Datenvolumen? Nichts! ob ich 4.7 MB an Bildern sofort während des Seitenaufbaus lade oder verteilt über die nächsten Minuten, in denen ich auf der betreffenden Seite scrolle, es sind und bleiben 4.7 MB. Damit wird meiner Meinung nach auch das Argument „minimizes user bandwidth“ wackelig. Der einzige Unterschied ist die Zeit, die bis zur Benutzbarzeit der Seite verstreicht, weil eben nicht alle Bilder/Iframes sofort bei Seitenaufruf geladen werden (müssen).
Tschö, Auge
Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
Hohle Köpfe von Terry Pratchett
marctrix
Der Martin
Gunnar Bittersmann
MudGuard
Henry