21
Ja. Mit dem Preload kannst du den Download des Bildes aber nicht verkürzen, sondern nur früher starten lassen. Da die Bilder aber eh schon zeitgleich mit der CSS Datei heruntergeladen werden, errreichst du mit dem Preload hier gar nichts. Im Fall von Firefox hast du sogar den gegenteiligen Effekt, dass ggf. ein größeres Bild heruntergeladen wird, welches erst später in den leeren Platz gefüllt wird.
Da FF auch sämtliche anderen Bilder, ja alles bis auf Favicon und drei Dekografiken, zum gleichen Zeitpunkt runterlädt und dieses seltsame lazy-imageset vergibt, das auf jeden Fall falsch ist, vertraue ich dem FF-Wasserfall nicht. Die Codes sind ja offenbar korrekt und Chrome macht es perfekt richtig.
Und wie viele User nutzen FF, 10%.
Andererseits wird der Effekt wohl auch bei größeren Seiten überschaubar sein und das preload müsste wohl nicht sein. Wobei ich es auch als Zukunftsvorsorge betrachte und auch für andere Sites dann so übernehmen würde. Grundsätzlich ist es sinnvoll (ganz oben im Header, LCP, schmale mobile-Verbindungen).
Wenn FF in real life ebenso arbeitet, läuft es aber bei 10% der User dann schlecht. Was fehlt denn FF für einen "perfectly match", warum nimmt er das falsche Bild, das er dann später korrigiert?
Auf manchen Webseiten wird ein stark komprimiertes JPEG-Bild vorgeladen, welches wegen geringer Größe schneller vorhanden ist und nach dem Download der endgültigen scharfe Version durch letzteres ersetzt wird. Stichworte: "Blur up", 'LQIP".
Der Effekt wäre mir lieber, damit könnte ich leben, weil der User das Bild trotzdem sofort sieht. Bei FF läuft es aber als Anti-preload, d.h., es bleibt erst mal leer und wird erst am Schluss mit dem richtigen Bild gefüllt. Tolle Lösung von FF... kann man m.E. auch als bug bezeichnen, statt als "optimization".