Damals haben die Nutzer noch verstanden, dass der Vorteil eines großen Bildschirms nicht wirklich darin besteht, ein Fenster möglichst groß ziehen zu können, sondern mehrere Fenster gleichzeitig sehen zu können.
Das bei mir heute noch so
Damals haben die Nutzer noch verstanden, dass der Vorteil eines großen Bildschirms nicht wirklich darin besteht, ein Fenster möglichst groß ziehen zu können, sondern mehrere Fenster gleichzeitig sehen zu können.
Das bei mir heute noch so
Nur sahen die Seiten damals fast alle so aus. Schmalen Container halt
Wenn es ums Lesen von Text geht, dann ist Höhe besser als Breite. Man verliert nämlich sehr schnell bei zu breiten Texten die Übersicht, wo man war.
Damals haben die Nutzer noch verstanden, dass der Vorteil eines großen Bildschirms nicht wirklich darin besteht, ein Fenster möglichst groß ziehen zu können, sondern mehrere Fenster gleichzeitig sehen zu können.
Was auch zu weiten Teilen daran liegt, dass Windows quasi bis heute immer noch kein vernünftiges Fenster-Management hat und vieles umständlich zu bedienen ist. Wobei es heute besser ist.
Dazu kommt auch, dass ein breiter Monitor nicht automatisch auch wirklich sich für zwei Fenster nebeneinander wirklich eignet. Ich merk es aktuell gerne an dem FHD-Monitor in der Arbeit. Darauf zwei Fenster nebeneinander führt gerne schnell dazu, dass die Inhalte in beiden Monitoren nicht genug Breite haben. Zu Hause auf dem WQHD sieht es anders aus. Da sind zwei Fenster echt praktisch verwendbar.
Zumal man auch nicht immer zwei Fenster nebeneinander braucht.
Travellers' Choice Hotel Auszeichnungen - Tripadvisor
Mir gefällt diese Liste der "Top 25 Hotels in Österreich" von TripAdvisor ziemlich gut. Insbesondere da ich der Website-Entwickler der Hotels sowohl von Platz 1 als auch von Platz 2 bin. Für mich hängt die Zufriedenheit der Hotelgäste natürlich auch mit der Qualität der Website zusammen. Da lasse ich mir auch nichts anderes einreden.
Cadeyrn Zu mindestens bei der ersten Seite kommt loading="lazy" ohne die Angabe von Höhe und Breite vor, das erscheint mir nicht so sinnvoll und Lighthouse motzt deswegen auch rum.
Das HTML für die Bilder wird durch die verwendete Software (Pimcore) erzeugt. Wobei das bei responsiven Bildern ja nicht ganz so eindeutig ist, was da nun angegeben werden sollte. Denn die Aspect Ratio kann je nach Fenstergröße eine andere sein. Sollte man dann Maße angeben, welche das Fallback-Bild als Grundlage haben, oder ist das gar kontraproduktiv? Da muss ich selbst mal ein wenig experimentieren, ob das in der Praxis tatsächlich den gewünschten Effekt hat. Lighthouse ist schön und gut, aber nicht jeder Ratschlag von Lighthouse ist tatsächlich sinnvoll umsetzbar. Ich will damit nicht sagen, dass dieser Tipp nicht gut wäre. Nur, dass ich es sorgfältig prüfen muss.
Wobei das bei responsiven Bildern ja nicht ganz so eindeutig ist, was da nun angegeben werden sollte. Denn die Aspect Ratio kann je nach Fenstergröße eine andere sein.
Du gibst die nicht-skalierten Abmessungen der Grafik an, denn daraus kann der Browser unter Beibehaltung des Seitenverhältnisses die tatsächliche Größe berechnen.
Im HTML: height="123" width="456" auf dem <img>
Im Stylesheet: height: auto; max-width: 100%;
Das kannst du dir bei uns auf der Startseite anschauen, etwa die Grafik mit dem Notebook/Tablet/Smartphone wird so responsive skaliert.
Bonus: In allen modernen Browsern != IE11 lässt sich Dank object-fit: cover; object-position: center; mit <img> sogar das Verhalten von background-image: …; background-position: cover; erreichen. Vorteil dieser Lösung: loading="lazy" wird möglich.
Gut zu sehen bei den "Rich Embeds", etwa hier: Rich Embeds Test
Edit: Google hat angekündigt, Dinge wie Layout Shifts stärker abzustrafen, insofern ist dies bezüglich dem Lazy Loading potentiell durchaus ein Problem, wenn die Abmessungen fehlen. Potentiell, weil das wie bei Google üblich sehr schwammig beschrieben ist und nicht definitiv klar ist, ob das so etwas tatsächlich auch betrifft, oder ob man nur gegen aufploppende Werbung stichelt. YMMV
Oder man schaut einfach auf Github in commit Historie: https://github.com/WoltLab/WCF/co…d36fd4c968412af
Du gibst die nicht-skalierten Abmessungen der Grafik an, denn daraus kann der Browser unter Beibehaltung des Seitenverhältnisses die tatsächliche Größe berechnen.
Im HTML: height="123" width="456" auf dem <img>Im Stylesheet: height: auto; max-width: 100%;
Das kannst du dir bei uns auf der Startseite anschauen, etwa die Grafik mit dem Notebook/Tablet/Smartphone wird so responsive skaliert.
Das ist eh klar, aber nicht das, was ich mit responsiven Bildern meinte, sondern die Verwendung von picture/source/srcset. Wenn es um Content-Bilder geht, werden in der Regel unterschiedliche Bilder je nach Fenstergröße geladen. Das ist auch wichtig, denn es wäre völlig sinnlos, beispielsweise am Smartphone Bilder zu laden, welche 2000 Pixel breit und 3000 Pixel hoch sind, wenn diese gar nicht so groß angezeigt werden können. Das wäre dermaßen katastrophal für die Performance, dass der Layout Shift noch das kleinste Problem wäre.
Diese unterschiedlichen Bilder sind nicht immer einfach nur runter skalierte Versionen ansonsten identischer Bilder. Oftmals ist das Layout eines Website-Elemens bei einer Smartphone-Größe ein anderes als bei der Tablet- oder Desktop-Größe. Das heißt: Das Seitenverhältnis, welches für die Desktop-Ansicht gilt, kann auch mal ein komplett anderes sein als für die Smartphone-Ansicht. Und darauf zielte meine Frage ab: Ob es nicht womöglich sogar kontraproduktiv ist, wenn ich nun durch die Angabe von width und height implizit ein Seitenverhältnis vorgebe, welches nur bei manchen Fenstergrößen der Wahrheit entspricht.
So ein Beispiel findet sich auf der WoltLab-Seite nicht. Hier wird ja wirklich noch nach der ganz alten Methode gearbeitet: Bilder einfach vom Browser runterskalieren lassen, aber immer die volle Auflösung der Bilder laden. Nicht böse gemeint, aber die WoltLab-Website ist kein Best Practice-Beispiel für die Inszenierung von Bildern und die entsprechende Implementierung in modernem Webdesign. Tatsächlich ist die WoltLab-Seite ja mehr Informations-orientiert und trocken und kommt dementsprechend auch mit dieser Umsetzung auf geringe Ladezeiten. Bei meinen Kunden steht die Präsentation mehr im Vordergrund, d.h. da wird Gebrauch von vielen und großen Bildern gemacht. Entsprechend braucht es da fortgeschrittenere Methoden als das simple Runterskalieren, weil es da um ein Ersparnis im Megabytes-Bereich geht.
sondern die Verwendung von picture/source/srcset
Das ist nur von Bedeutung, wenn die Seitenverhältnisse nicht übereinstimmen. Bei identischen Seitenverhältnissen ist es irrelevant, weil die Größenangabe nur der Berechnung des Verhältnisses dient und nicht die angezeigte Größe bestimmt. Es handelt sich streng genommen um einen Workaround für die (noch) miese Unterstützung von aspect-ratio.
Danke Cadeyrn jetzt hab ich noch mehr auf der Roadmap XD
Du hast irgendwie Browser-Probleme
Kann ich nur bestaetigen, funktioniert bei mir tadellos.
Strg+F5 behebt das Problem. Mysteriös. Mal Windows neu starten
Strg+F5 behebt das Problem. Mysteriös. Mal Windows neu starten
Wobei ich der Meinung war, es sollte auch ein Fallback geben. Davon sehe ich allerdings aktuell nichts.
Wobei ich der Meinung war, es sollte auch ein Fallback geben. Davon sehe ich allerdings aktuell nichts.
WebP wird nur ausgeliefert, wenn dein Browser Unterstützung für image/webp im accept-Header sendet, ansonsten bekommst du ein JPEG.
Ah, okay. Wusste nicht, dass das Backend-seitig geregelt wird.
Es geht leider nicht anders, ohne mit der Kompatibilität zu brechen. <picture> würde die CSS-Selektoren sowie das Verhalten via JavaScript ändern und <img> kennt keine Content-Type-Negotiation…
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!