preload von Schriftdateien, z.T. mit media querys [2]

Ich frage dann öfters auch gezielt nach "pros and cons", damit beide Seiten beleuchtet werden.

Das habe ich gelegentlich auch schon gemacht.

Ich lese auch öfters die verlinkten Quellen zu den Aussagen, finde dort aber sehr häufig nur sehr indirekt die Aussagen der KI wieder.

Also behalte ich als Einheit "em" wie im Stylesheet bei und auch die gleiche MQ-Grenze des 3. MQ, das bei 670px/41.875em endet.

Dass die Nachbildung der Stylesheet-MQs neben "em" und 670px/41.875rem aber auch die Notierung aller 5 MQ einzeln mit jeweiligen Viewports umfassen müsste, dafür gibt es aber keinen Grund, oder? Dann müsste ich statt der 2 preload-tags mit 2 MQ insgesamt 6 preload-tags machen (5 MQ und desktop). Obwohl es nur 2 Fälle sind, d.h., bis 670px (3. MQ) der eine Schrift-preload, ab 671 der andere.

Noch eine andere Sache.
Wegen der Reihenfolge mehrerer webfont-preloads plus headerbild-preload im head untereinander habe ich - ganz ausführlich - gefragt:
Spielt die Reihenfolge mehrerer preload-tags im head eine Rolle? Im head stehen mehrere preload-tags für mehrere webfonts und ein headerbild, alle werden above the fold benötigt. Das headerbild ist im design ganz oben das erste Element.

Die KI kommt zum gleichen Ergebnis wie ich, nämlich das Bild-preload vor den webfont-preloads im head zu platzieren.
Das (gar nicht gefragte) Stylesheet will sie aber VOR allen preloads sehen, bei mir kommt es direkt nach den preloads.

Wahrscheinlich hat meine Reihenfolge einen Grund (den ich in einem Berg von Papier erst nachschauen müsste) und wenn ich die KI nach ihrem Grund frage, hat sie natürlich drei wirklich gut klingende Gründe für ihre CSS-Priorität im head vor den preloads: 1. Der Browser müsse erst mal per CSSOM die Seitenstruktur verstehen. 2. Evtl. werden überflüssige, gar nicht gebrauchte webfonts geladen. 3. Ein korrekt platziertes CSS-File stellt sicher, dass die Schriftarten erst dann priorisiert werden, wenn sie auch wirklich zum Rendern des Textes erforderlich sind.

Mal ganz ohne KI, würdest du spontan das ext. Stylesheet im head vor den preload-tags oder danach platzieren?

Als ich die KI nochmal frage, warum es besser ist, das Stylesheet im head nach den preloads zu platzieren, findet sie das plötzlich sehr gut und begründet es ganz ausführlich:

Webfonts (wie Google Fonts) werden oft innerhalb eines CSS-Stylesheets via @font-face definiert. [1, 2]
• Ohne Preload: Der Browser lädt das CSS, parst es, entdeckt den Font, und erst dann beginnt der Download der Schriftart. Das führt oft zu "Flash of Unstyled Text" (FOUT) oder "Flash of Invisible Text" (FOIT).
• Mit Preload vor CSS: Der Browser sieht den preload-Tag für den Font sofort beim Einlesen des HTMLs und startet den Download parallel zum Download des Stylesheets. Wenn das CSS dann bereit ist, ist der Font oft schon geladen. [1, 2, 3, 4, 5]
2. Priorisierung kritischer Bilder (LCP-Optimierung)
Bilder, die im CSS als Hintergrundbild definiert sind, werden vom Browser sehr spät entdeckt. [1]
• Preloading von kritischen Bildern (z. B. Hero-Images, Banner) sorgt dafür, dass diese bereits geladen werden, während das Stylesheet noch heruntergeladen wird.
• Dadurch wird der "Largest Contentful Paint" (LCP) – ein wichtiger Google-Performance-Messwert – deutlich verbessert. [1, 2]
•
3. Warum das Stylesheet danach kommt
• Preload-Priorität: preload weist den Browser an, eine Ressource mit hoher Priorität herunterzuladen.
• Rendering-Blockierung: Externe CSS-Dateien blockieren das Rendering der Seite, bis sie vollständig geladen sind.
• Ergebnis: Durch die Platzierung der Preloads vor dem Stylesheet (und anderen blockierenden Ressourcen) teilt man dem Browser mit: "Lade diese wichtigen Dinge sofort, und dann kümmere dich um das Stylesheet, das die Seite darstellt." [1, 2]

Zusammenfassend: Die Preloads vor dem Stylesheet sorgen dafür, dass kritische Assets (Schriften/Bilder) nicht auf das Parsen des CSS warten müssen, sondern parallel dazu heruntergeladen werden, was die Ladezeit der Seite verbessert.

Ich weiß nicht, wie ich das durch detaillierteres Fragen noch aufklären sollte. Irgendwie ist das alles richtig.

Ich habe die preload-tags jetzt auf allen Seiten im head ergänzt, vor dem Stylesheet-tag.

Bislang habe ich in Chrome die Seiten angeschaut und getestet, und wollte jetzt mal zum FF zwecks Testen wechseln (Wasserfall). Dort habe ich "Good 3G" gewählt.

Dort sind mir zwei Sachen aufgefallen, die anders als in Chrome sind:

1.lazy-imageset?
Das Headerbild erscheint im Wasserfall mit der Bezeichnung "lazy-imageset" unter "Initiator"!?

Das Headerbild ist im HTML-body mit einem komplexeren <picture> umgesetzt:
Art Direction, je nach Viewport verschiedene Bilder plus verschiedene x-Auflösungen.
Die preload tags zum headerbild bilden das nach.

Da das Headerbild ganz oben im header ist und gleichzeitig mit dem Stylesheet zu laden beginnt, wird es aber nicht "lazy" geladen. Ich verwende so etwas auch in keiner Weise.

Die Google-KI sagt dazu:
<picture>-Tag Verhalten: Wenn Sie <picture> verwenden, entscheidet Firefox, welches <source>-Bild am besten passt. Die lazy-imageset-Meldung erscheint, wenn das ausgewählte Bild auf den Ladevorgang wartet, der durch den loading="lazy"-Parameter im inneren <img>-Tag ausgelöst wird.
Warum es nicht immer ein Bug ist: Es ist ein gewolltes Feature, um die Performance zu verbessern, indem die Anzahl der Anfragen beim ersten Laden reduziert wird.

lazy-imageset scheint also nur die Auswahl aus picture zu meinen, aber ich verwende definitiv kein lazy-Attribut, wovon es dennoch spricht!? Passt das trotzdem, solange es mit dem Stylesheet lädt?

2.Headerbild kommt nach den Webfonts im Wasserfall und Stylesheet hat nur Pririty "normal"

Eigentlich sollte wie in Chrome im Wasserfall das Headerbild kurz vor den Webfonts kommen, schließlich ist es im head vor den Webfonts als preloaded notiert.
Wobei es wohl keinen Unterschied macht, da in FF dennoch beides gleichzeitig mit dem Stylesheet zu laden beginnt.
Seltsamerweise tun das aber auch alle anderen Bilder (Priority low!), die irgendwann mal auf der Seite kommen und kein preload haben.

Das Stylesheet hat seltsamerweise nur Priorität "normal".

Ignoriert FF da einfach meine Entscheidung zu Gunsten des Headerbildes (gegenüber Webfonts) und modelt das nach eigenem Gutdünken etwas um?

Kein WP, reines HTML/CSS, halt lokal auf meinem PC, mit dem HTML-Editor VSC und dem Live Server-Plugin.

Es sieht echt ganz anders aus als in Chrome.
Das Headerbild-preload steht im head vor den drei preloaded Webfonts und vor dem Stylesheet, kommt im Wasserfall aber nach Webfonts und Stylesheet, auch nach dem unwichtigen JS-Link zur JS-Datei am Ende der Seite. Wobei alles zum gleichen Zeitpunkt zu laden beginnt laut Balken (plus low priority-Bilder).

Ist das doch kein "Anzeigefehler" mit lazy-imageset, somndern greift da tatsächlich ein lazy? Aber dann müsste es doch auch in Chrome so sein.

Ich hab mal einen screenshot angefügt.



Aussehen tut es wie http2, aber ich habe das Protokollfeld eingeblendet und da steht überall 1.1.

Nur das Favicon, drei Dekografiken und die nicht above the fold benötigten Webfonts werden später geladen, alles andere zum gleichen Zeitpunkt wie Stylesheet und Webonts above the fold.

Wenn ich es mit GPSR mache, stimmt die Reihenfolge, ist wie in Chrome (dauert aber fast 2 Minuten). Bei DSL und 4G ist es wieder wie bei good 3G "falsch", also das Headerbild unten im Wasserfall.
Bei "good 2G" ist es fast richtig, nur eine der drei preloaded webfonts kommt vor der Headergrafik, ansonsten ist sie fast ganz oben.
Je langsamer die Verbindung, desto eher macht FF es korrekt, je schneller, desto eher "falsch"? Wobei ja wie gesagt die Balken immer gleich beginnen und das bleibt bei allen Geschwindigkeiten gleich.

Ist HTTP 2.0 denn serverseitig implementiert? das hat ja auch nicht unerheblichen Einfluss auf die Performance.

Du meinst im Software "Server", dem Plugin von Visual Studio Code, dem HTML-Editor? In der offiziellen Beschreibung steht davon nichts. Geht das lokal überhaupt?

Ich habe jetzt mal alle Auflösungen/media queries für das Headerbild im FF und im Chrome DevTool durchprobiert.
Chrome macht es immer korrekt. Es lädt nur ein Bild, es ist das korrekte Bild und es wird als oberster preload im head wie gewünscht ganz oben im Wasserfall sofort geladen.

FF macht es bei allen Viewports immer falsch und zwar in folgender Weise:
Es lädt immer zwei Headerbild-Varianten, nämlich das korrekte, aber erst ganz unten im Wasserfall, mit priority low und Initiator "imageset".
Und FF lädt oben als wichtiges preload-Bild immer das Bild, das im komplexen <picture> und ebenso bei den preload-tags im head als default-Bild notiert ist, nämlich das große desktop-Bild. Dieses hat als Initiator das schon angesprochene "lazy-imageset". Da im devTool DPR 2 eingestellt ist, ist es das 1860x600-Bild (2x-Variante).

Mit dieser Konstruktion im picture und nachgebildet als preload-Tag-Varianten kommt FF scheinbar nicht klar.

Oder ist doch ein Fehler drin, den Chrome toleriert und FF nicht. Vielleicht magst du mal schauen, ob dir etwas auffällt:

<link rel="preload" as="image" fetchpriority="high" media="(max-width: 429px)" imagesrcset="./grafiken/headerbild-430x172-1x.jpg 1x, ./grafiken/headerbild-860x344-2x.jpg 2x">
<link rel="preload" as="image" fetchpriority="high" media="(min-width: 430px) and (max-width: 499px)" imagesrcset="./grafiken/headerbild-500x200-1x.jpg 1x, ./grafiken/headerbild-1000x400-2x.webp 2x">
<link rel="preload" as="image" fetchpriority="high" media="(min-width: 500px) and (max-width: 670px)" imagesrcset="./grafiken/headerbild-670x268-1x.jpg 1x, ./grafiken/headerbild-1340x536-2x.webp 2x">
<link rel="preload" as="image" fetchpriority="high" media="(min-width: 671px) and (max-width: 829px)" imagesrcset="./grafiken/headerbild-930x372schmal-1x.webp 1x, ./grafiken/headerbild-1395x558-15x.webp 1.5x">
<link rel="preload" as="image" fetchpriority="high" media="(min-width: 830px) and (max-width: 960px)" imagesrcset="./grafiken/headerbild-930x372schmal-1x.webp 1x, ./grafiken/headerbild-1395x558-15x.webp 1.5x">
<!-- Für das default-img bzw. desktop-Bild bei desktop-first  -->
<link rel="preload" as="image" fetchpriority="high" media="(min-width: 961px)" imagesrcset="./grafiken/headerbild-930x300breit-1x.webp 1x, ./grafiken/headerbild-1860x600breit-2x.webp 2x">

Ich glaube, die KI hat mir die Ursache genannt, die ich aber leider nicht lösen kann.

does Firefox devtools network waterfall handle complex <picture> code with media queries and preload tags in head handle wrong? It loads two images instead of one.

Yes, Firefox DevTools can accurately report a scenario where a complex <picture> tag causes two images to be loaded. However, this behavior is usually not a fault of the DevTools waterfall display itself, but rather a browser-level optimization issue where the preloader and the rendering engine conflict.The scenario where two images load instead of one is a common issue when combining <link rel="preload"> with complex responsive image (<picture> or srcset) logic.

Why Double Loading Happens in Firefox

Preload vs. Picture Evaluation Conflict: The preload scanner in the browser head often runs before the browser has finalized the viewport dimensions. If a <link rel="preload" media="..."> tag has a query that doesn't perfectly match the final computed <source media="..."> in the <picture> tag, the browser will preload one image, realize it's wrong, and download the correct one later.

src vs. srcset Behavior: If the <img> tag within the <picture> element has a src attribute that doesn't exactly match one of the URLs in the <source srcset="..."> options, Firefox might load the src image and the srcset image.

Cache Partitioning Glitch: In some scenarios, Firefox can download the same asset twice if it considers the preloaded version to be in a different cache partition (e.g., partitioned by origin) than the one used for rendering.

Ich habe schon ein paar Sachen probiert, aber leider ohne Erfolg. Zum Beispiel das scr im picture-img gelöscht oder testweise in eines der sources angelegt. Dann media="(min-width: 961px)" im untersten preload tag für das default img gelöscht.

Das Laden geschieht übrigens so, dass das Bild längere Zeit einen Platz belegt, der leer bleibt und erst spät sich mit dem Bild füllt.

Was die Notwendigkeit des preloads angeht, es ist als größtes Element wohl das LCP-Element und kommt auf allen Viewports ganz oben als Erstes. Wer weiß, wie die Unterschiede zwischen den Viewports sind oder sich noch mal verändern werden... Und es gibt noch andere Seiten, bei denen der Vorteil vielleicht größer ist. Die Tests sind ja mit nur einer bestimmten Seite.

Selbst wenn es im Moment nicht viel bringen sollte, ist es grundsätzlich eine sinnvolle Maßnahme. Es gar nicht zu preloaden, kam mir daher noch gar nicht in den Sinn. Aber wer weiß...