preload von Schriftdateien, z.T. mit media querys

Seite 12 3

1 Martin

Hallo,
ich möchte drei selbstgehostete Schriftdateien, die above the fold erscheinen, preloaden:

- "Gelasio regular" für die h1, sie soll bei jedem User vorab geladen werden, egal welcher Viewport, desktop oder mobile;

- "Inter Tight" für die Headernavigation, die im viewport des 1. und 2. media query, aber auch desktop zu sehen ist;

- "Inter bold" für die resp. Menü-Buttons, die im 3., 4. und 5. media query zu sehen sind.

Die Site hat 5 media queries, desktop-first.

Der zweite und dritte preload treten nicht gemeinsam auf.
Entweder ein User hat einen kleinen Viewport, der max. 670px breit ist (3. MQ geht von 500 - 670px), dann soll Inter Bold für die resp. Menü-Buttons vorgeladen werden.
Oder der User hat einen größeren Viewport, der zumindest 671px groß ist (2. MQ geht von 671 - 829px), dann soll Inter Tight für die breite Headernavi vorgeladen werden.

Stimmt das wie folgt:

<link rel="preload" media="(min-width: 671px)" href="./schriftarten/inter-tight-v9-latin-regular.woff2" as="font" type="font/woff2" crossorigin="anonymous">
<link rel="preload" media="(max-width: 670px)" href="./schriftarten/inter-v20-latin-700.woff2" as="font" type="font/woff2" crossorigin="anonymous">
<link rel="preload" href="./schriftarten/gelasio-semibold-webfont.woff2" as="font" type="font/woff2" crossorigin="anonymous">

Ich möchte zusätzlich noch die Headergrafik preloaden. Zwei kleine Schriftdateien von ca. 30KB und eine Grafik mit - je nach Viewport - mind. 50KB oder max. 280KB ist hoffentlich noch nicht zu viel "Preload" (Bandbreite).

Macht es Sinn, solche angelegten preloads lokal auf meinem PC in Visual Studio Code zu testen mit dem Browser DevTool? Wahrscheinlich läuft da einiges anders als in real life auf einem Hoster Server... Jedenfalls lese ich bei einem ersten Versuch nirgendwo etwas von "LCP" oder "preload", allerdings von priority "high".

2 Jörg Kruse

Macht es Sinn, solche angelegten preloads lokal auf meinem PC in Visual Studio Code zu testen mit dem Browser DevTool?

Also ohne lokalen Webserver? der Zugriff direkt über das Dateisystem ist um Längen schneller als über einen Webserver.

In den Entwickler-Tools von Firefox lässt sich in der Netzwerkanalyse in der zweiten Menüzeile auch eine Drosselung einstellen. Bei der Auswahl von "GPRS" und mit der Option "Cache deaktivieren" kannst du dann zuschauen, wie die Seite im Zeitraffer aufgebaut wird. Ich weiß aber nicht, ob das auch beim direkten Laden aus dem lokalen Dateisystem so funktioniert.

3 Martin

Einen in VSC per plugin eingerichteten lokalen "Server" gibt es schon. Das Plugin nennt sich Live Server und hat wohl jeder VSC-Nutzer.

Es scheint zu klappen, da im Wasserfall die beiden Schriftdateien gleichzeitig mit dem ext. Stylesheet begonnen werden zu laden. Explizit von "preload" oder LCP lese ich aber dennoch nirgends, zumindest nicht im Chrome-devtool.

Mit Auswahl der Drosselung bzw. deren Verneinung ändert sich die Ladezeit insgesamt extrem, von unglaublich schnellen 62ms bei "no throttling" bis zu furchtbaren 21 Sekunden (!) bei 3G.

Ist der Code für mein beschriebenes Setting in Ordnung? Zuerst wollte ich alle fünf media queries jeweils einzeln in einem eigenen preload tag berücksichtigen, quasi exakt parallel zu meinen Stylesheet media queries. Aber das müsste so klappen mit den nur zwei media queries in den nur zwei preload tags?

Ich frage den Viewport in den betreffenden zwei tags mit MQ mit der Einheit Pixel ab. Im Stylesheet nutze ich aus Acc.-Gründen für die MQ dort "em", weil manche User die Schriftgröße im Browser ändern.

Hier beim preload der webfonts macht das aber wohl keinen Sinn, oder warum sollte sich bei vergrößerter Schriftgröße eines Sehbehinderten der Viewportbereich dann ändern? Das wird dann eher falsch, weil es ändert doch nichts daran, bei welchem Viewport eine große Headernavi oder resp. Menü-Buttons zu sehen sein sollen (mit deren Schriften).

Danke.

4 Jörg Kruse

Ist der Code für mein beschriebenes Setting in Ordnung?

Das schaut OK aus.

Aber das müsste so klappen mit den nur zwei media queries in den nur zwei preload tags?

Ja, der Beschreibung auf MDN zufolge sollte es das:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload#including_media

Ich frage den Viewport in den betreffenden zwei tags mit MQ mit der Einheit Pixel ab. Im Stylesheet nutze ich aus Acc.-Gründen für die MQ dort "em", weil manche User die Schriftgröße im Browser ändern.

Hier beim preload der webfonts macht das aber wohl keinen Sinn, oder warum sollte sich bei vergrößerter Schriftgröße eines Sehbehinderten der Viewportbereich dann ändern?

Bei welcher Media Query bindest du die jeweiligen Fonts im CSS ein? der Preload sollte ja analog dazu erfolgen. Wenn eine Schriftart beispeilsweise bei kleinerer Schrift besser lesbar ist, würde ich deren Einsatz von der Einheit em abhängig machen. Wenn ich so schlecht gucken kann, dass ich die Schriftgröße im Browser auf 24px voreinstelle, dann möchte ich eine besser lesbare Schrift auch schon bei entsprechend größeren Viewports sehen.

5 Martin

Im externen Stylesheet sind die selbstgehosteten webfonts bereits alle im Basislayout eingebunden (font-face-Definitionen plus Element-Zuordnung, beides), also vor den MQ. Ich habe den desktop-first-Ansatz.

So z.B. "Inter regular" für den Fließtext beim body-Styling, "Gelasio regular" für die Überschriften beim h-Styling und "Inter Tight" beim Styling der Headernavigation.
Die Schriftdatei für "Inter bold", die ich beim preload speziell für die Menü-Button-Beschriftung bei den kleineren MQ brauche, ist im Stylesheet ebenfalls bereits im Basislayout eingebunden, weil ich die Fettungen im Fließtext ja "überall" gelegentlich brauche.

Die so im Basislayout eingebundenen Webfonts vererben sich dann auf die MQ.

Beim preload schaue ich nur auf die Elemente above the fold, und welche Schriftdateien diese brauchen, denn etwas anderes soll ja nicht vorabgeladen werden.
Wenn ich dort im preload nun die MQ-Abfragen in em angebe, dann verschiebt sich für User, die die Schriftgröße im Browser verändert haben, mein festgelegter Viewportbereich.

Das z.B. fürs preload relevante 3. MQ geht von 500px/31.25em - 670px/41.875em. So steht es im Stylesheet, also mit em. Beim body ist das default des Browser-Stylesheets mit font-size 1rem bestätigt.

Wenn ich aber jetzt im preload tag 41.875em verwende und ein User hat die Schriftgröße verändert im Browser, dann wird das eine andere Grenze für ihn ergeben. Nicht mehr meine für das 3. MQ definierte. Die breakpoints verschieben sich dann oder verstehe ich etwas falsch?

6 Jörg Kruse

Das z.B. fürs preload relevante 3. MQ geht von 500px/31.25em - 670px/41.875em. So steht es im Stylesheet, also mit em.

Wenn der Breakpoint im CSS mit 41.875em angegeben ist, entspricht das in einem Browser, in welchem 24px als Standardgröße definiert sind, 1005px.

Wenn ich aber jetzt im preload tag 41.875em verwende und ein User hat die Schriftgröße verändert im Browser, dann wird das eine andere Grenze für ihn ergeben.

Das ergibt dann auch wieder eine Weite von 1005px, wenn 24px als Standardschriftgröße definiert ist.

Wenn im CSS der Breapoint mit em definiert ist, und im Preload mit px, passt das nur zusammen, wenn der User die Standardschriftgröße (16px) nicht verändert hat.

Die breakpoints verschieben sich dann oder verstehe ich etwas falsch?

Gemessen in Pixeln verschieben sich die Breakpoints dann, wenn der User in den Browser-Einstellungen die Standardschriftgröße ändert. Das tun sie dann aber gleichermaßen im CSS wie im Preload.

7 Martin

Gemessen in Pixeln verschieben sich die Breakpoints dann, wenn der User in den Browser-Einstellungen die Standardschriftgröße ändert. Das tun sie dann aber gleichermaßen im CSS wie im Preload.

Im CSS bin ich mir sicher, dass die Verschiebung "gut" ist. Das ist der normale Acc.-Gedanke, weswegen man em im CSS bei den MQ verwenden sollte.
Bei den preloads im HTML bin ich nicht sicher, ob die Verschiebung gut ist. Mir schwirrt da gerade etwas der Kopf :)...

Ich habe heute zwei Mal die Google-KI genau die gleiche Frage gestellt, nämnlich "is it good to use em as unit for media queries in preload tags which preload webfonts.

Beim 1. Mal spricht sie sich klar für Px aus und begründet das auch gut. Unter anderem so:

Avoid double Loading: If you use em and a user increases their browser font size, a min-width: 40em breakpoint might trigger on a mobile device, loading desktop fonts and potentially load mobile fonts later, causing a double-download and disrupting performance.

Browser Consistency: Modern browser interpret px-based MQ accurately, even when zooming.

Unreliable base: em units are relative to the font size of the parent. In the head, the context for em can be inconsistent, making 40em behave differently than intended.

Recommendation: Use px in your preload links for maximum reliability, ensuring the correct font is loaded for the intended screen width without wasting bandwidth.

Beim 2. Mal spricht sie sich eher für em aus:
Accessibility & Zooming: If a user increases their browser’s default font size (e.g., from 16px to 20px), em-based media queries will scale accordingly. If you use px, the font will not load at the correct time for users who need larger text.

Consistency with CSS: It aligns with the best practice of using em for breakpoints in your CSS files. Das ist dein Argument hier.

Optimal Performance: According to web.dev, using <link rel="preload" media="..."> with appropriate media queries (using em or px) ensures that browsers only download fonts necessary for the current viewport.

Wahrscheinlich dachte sich die KI, ich war mit der 1. Antwort unzufrieden und hat jetzt die Gegenposition eingenommen. Schon witzig.

Man kann es so und so sehen, was ist da für mich jetzt maßgeblich? Wichtig erschien mir ursprünglich des gefettete Argument oben, das gegen em sprach.

8 Jörg Kruse

Bei der ersten Antwort ging Gemini möglicherweise stillschweigend davon aus, dass du die Breakpoints im CSS mit px setzt, und bei der zweiten Antwort, dass dort em in den Media Queries verwendet wird?

Bei unterschiedlichen Antworten hilft es manchmal zu präzisieren:

Is it good to use em as unit in media attribute of <link rel="preload"> tags which preload webfonts? in the CSS file the breakpoints are set with the unit em.

Da kam dann diese Antwort:

Short answer: Yes, it is actually the best practice.

If your CSS media queries use em, your preloads should use em too. Using different units (like mixing px and em) can lead to "double-loading" or the font not preloading at all when a user has a custom browser font size.

Why em is the Right Choice

When you use em in a media query, it is relative to the browser’s default font size (usually 16px). If you use px in your preload tag but em in your CSS, a user who has increased their default font size to 20px might trigger a different breakpoint than the preload tag expects.

The Risk of Unit Mismatch
Unit in Preload Unit in CSS Result
600px           37.5em (600/16)   Success (only if browser default is 16px).
600px           37.5em            Fail: If browser default is 20px, the CSS breakpoint is now 750px. The preload won't match the actual CSS application.
37.5em          37.5em            Success: They stay perfectly synced regardless of user settings.

9 Martin

Bei unterschiedlichen Antworten hilft es manchmal zu präzisieren:

Ja, scheint so, angesichts der Antwort dann. Ich dachte, meine Frage ist eh schon so lang und präzise... es noch länger zu machen, da wäre ich nie drauf gekommen :). Wahrscheinlich denke ich doch noch sehr wie ein Mensch und nicht wie eine KI. Was mich nicht traurig macht.
Gute Idee von dir! Werde ich mir merken.

War aber auch gut, dass ich misstrauisch geblieben bin und die KI überhaupt ein 2. Mal gefragt habe (sowie zusätzlich hier im Forum), sonst hätte ich das sehr deutliche "Px-pro" der 1. Antwort einfach angenommen und fertig. Manchmal ist es nicht schlecht, wenn man dazu neigt, nachzuhaken und nachzubohren, bis man wirklich überzeugt ist (aber auch anstrengender und zeitaufwendiger).

Also mein 1. Hauptargument, mit em könnte dann etwas schief laufen bei User-Settings der Schriftgröße, ist in Wahrheit umgekehrt, d.h., nur dann läuft es richtig. Es verschieben sich dann zwar die breakpoints, aber eben analog zum Stylesheet und daher passt es so für die Acc.
Und das ist ein echtes Argument.

Die beiden anderen Argumente scheinen dagegen nicht sehr überzeugend:

Browser Consistency: Modern browser interpret px-based MQ accurately, even when zooming.

Unreliable base: em units are relative to the font size of the parent. In the head, the context for em can be inconsistent, making 40em behave differently than intended.

Keine Ahnung, was so eine Inkonsistenz sein könnte und das funktionierende Zoomen mit Pixel... ja gut, aber warum sollte das mit em nicht auch klappen?

Bei deiner KI-Antwort waren diese zwei Sachen offenbar plötzlich völlig irrelevant. Kein Wort mehr davon.

Also dann doch em wie im Stylesheet oder haben wir noch etwas übersehen? Dürfte alles dazu gesagt sein.

10 Jörg Kruse

Die Antworten von Gemini sind ja wie bei allen LLM nicht determistisch, es antwortet mal so und mal so. Da die Trainingsdaten sehr umfangreich sind und mitunter auch viele ältere Texte umfassen, greift es dann auch mal auf Argumente zurück, die in früheren Zeiten häufiger vertreten wurden. Dieses scheint mir noch aus einer Zeit zu stammen, in welcher Pixel-definierte Layouts der Standard waren:

Browser Consistency: Modern browser interpret px-based MQ accurately, even when zooming.

Und wenn das LLM schon eine Position eingenommen hat, bleibt es (innerhalb des jeweiligen Chats) oft auch dabei und fügt weitere passende Argumente hinzu, die es in den Trainingsdaten "findet".

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

Seite 12 3

nach oben weiter >