Ladezeit wegen viele Bilder - Suche nach Alternative

[supervisior]

Ich hab auf Deiner Seite gerade mal versucht das besagte Header Bild zu finden, aber ich find da nix. Hast Du eine URL zu der Seite?

Nimm zum Beispiel auf der Startseite dieses hier: https://one-million-places.com/wp-conte ... s-2020.jpg

Dieses Bild hat alle Klassen, aber nicht die von Dir genannte Klasse

Und in Beiträgen sind Headerbilder für mich immer die, die über dem Inhaltsverzeichnis stehen. Hilft das?

Das gilt auch für das sich wiederholende Bild im Kopf der Seite ganz oben

Du hast nicht wenige Bilder in CSS als Hintergrundbild definiert.

Hast Du dafür ein Beispiel? Ich glaube nicht, dass ich da was selber definiert habe.

Schau mal alle Bilder auf der Startseite unterhalb von "Aktuelle Reiseberichte". Die sind alle als Hintergrundbild definiert.

[Hanzo2012]

Das mit dem srcset-Attribut könnte man so machen, keine Frage. Andererseits, warum dem Browser noch mehr Arbeit aufladen, wenn man das dem Server machen lassen kann?

Kann der Server denn wissen, wie groß z. B. das Browser-Fenster gerade ist oder wie hoch die Pixeldichte des Displays ist (Verhältnis zwischen CSS-Pixeln und echten Pixeln)? Ich glaube nicht.

[supervisior]

Das mit dem srcset-Attribut könnte man so machen, keine Frage. Andererseits, warum dem Browser noch mehr Arbeit aufladen, wenn man das dem Server machen lassen kann?

Kann der Server denn wissen, wie groß z. B. das Browser-Fenster gerade ist oder wie hoch die Pixeldichte des Displays ist (Verhältnis zwischen CSS-Pixeln und echten Pixeln)? Ich glaube nicht.

Auf meine diffus wirkende Aussage hin, würde ich mir das von Dir genannte auch als Antwort geben.

Weißt Du was RESS ist, bzw. wofür das steht?

[Hanzo2012]

Weißt Du was RESS ist, bzw. wofür das steht?

Jetzt schon

Für Mobilgeräte mag das einigermaßen funktionieren, vorausgesetzt du hast eine stets aktuelle Datenbank, in der die Infos über die täglich neu erscheinenden Modelle von Smartphones, Tablets etc. korrekt erfasst sind (Wer pflegt sowas?).

Bei Laptops oder PCs hast du damit aber keine Chance. Der Server hat keine Möglichkeit zu wissen, ob ich die Seite auf einem ollen HD-Bildschirm oder auf einem 4K-Monitor betrachte, weil der Browser diese Information nicht mitsendet.

[supervisior]

Weißt Du was RESS ist, bzw. wofür das steht?

Jetzt schon

Für Mobilgeräte mag das einigermaßen funktionieren, vorausgesetzt du hast eine stets aktuelle Datenbank, in der die Infos über die täglich neu erscheinenden Modelle von Smartphones, Tablets etc. korrekt erfasst sind (Wer pflegt sowas?).

Bei Laptops oder PCs hast du damit aber keine Chance. Der Server hat keine Möglichkeit zu wissen, ob ich die Seite auf einem ollen HD-Bildschirm oder auf einem 4K-Monitor betrachte, weil der Browser diese Information nicht mitsendet.

Ich wusste, dass Du darauf hereinfällst. Das Ur-Prinzip von RESS siehst tatsächlich vor, dass man eine Gerätedatenbank dafür verwendet und es gibt auch heute noch PHP Klassen, die meinen, dass man damit dem Prinzip von RESS vollumfänglich entsprechen würde. Aber das ist natürlich Quatsch. Es geht viel einfacher und man braucht dazu auch keine Gerätedatenbank, wobei es auch nicht notwendig ist auch noch Laptops identifizieren zu müssen.

Es genügt zunächst zu identifizieren, ob es ein mobiles Gerät ist oder nicht. Laptops sind davon ausgenommen und auch Desktop Geräte im Allgemeinen. Es braucht zunächst nur eine Erkennung, ob Android oder Mac und erst im zweiten Schritt abhängig vom OS eine Erkennung, ob Smartphone oder Tablet. Damit hast Du alles, was Du brauchst und man keine 10 Zeilen PHP Code dafür braucht, um die entsprechenden Definition aus dem UA kommend zu generieren. Damit bekomme ich zwar keine Auflösungen, aber die brauch ich gar nicht, weil es genügt 3 verschiedene große Bilder bereitstellen. Das müsste man jetzt sicherlich noch genauer beschreiben, aber ich denke, dass Dir klargeworden ist, was man damit wie gut machen kann. Das ist jetzt aber nicht nur eine Lösung speziell für Bilder, sondern ermöglicht ungeahnte Möglichkeiten bis hin zu 3 verschiedene Seiten mit gänzlich anderem Code je Geräteklasse. Jede Klasse bekommt ihren eigenen Code von links oben bis rechts unten, wenn man es so macht wie ich. Heißt für alle Geräte Score 100(0) nicht nur bei Pagespeed.

[Hanzo2012]

Was heißt hier "darauf reinfallen"? In dieser Diskussion geht es doch um Bilder, und du meintest das srcset-Attribut könne man sich sparen, weil man auch serverseitig die passende Bildauflösung bestimmen könne. Und genau dafür habe ich dir ein Beispiel genannt, bei dem das eben nicht funktioniert -> deine Lösung ist kein vollwertiger Ersatz für srcset.

[supervisior]

Was heißt hier "darauf reinfallen"? In dieser Diskussion geht es doch um Bilder, und du meintest das srcset-Attribut könne man sich sparen, weil man auch serverseitig die passende Bildauflösung bestimmen kann. Und genau dafür habe ich dir ein Beispiel genannt, bei dem das eben nicht funktioniert -> deine Lösung ist kein vollwertiger Ersatz für srcset.

Okay hast Recht. Das war falsch geantwortet. Reingefallen bist aber trotzdem, aber nicht, was das Thema hier anbetrifft, sondern wegen der Erläuterungen zu RESS. Nachdem Du ein schlaues Kerlchen bist, hab ich Dir einfach mal unterstellt, dass man diese RESS Methode auch viel einfacher machen könnte.

RESS macht das srcset-Attribut aber nicht gänzlich obsolet. Es ist ja immer noch Responsive Webdesign, weshalb ich damit auch die üblichen Methoden anwenden kann. Nur, dass zumindest ich nicht dafür verwende, um abhängig davon die passenden Bilder je Auflösung zu definieren.

[Hanzo2012]

Responsive Webdesign heißt für mich nicht nur "statisch" (= zum Zeitpunkt des Aufrufs) zwischen Gerätetypen zu unterscheiden, sondern auch dafür zu sorgen, dass z. B. sich das Layout der Seite anpasst, wenn ich das Browser-Fenster kleiner mache. Und idealerweise würde der Nutzer mit protzigem 4K-Monitor eine hochaufgelöste Version des Bilds kriegen und der arme Tropf, der vor seinem "HD ready"-Bildschirm hockt, eben nur eine niedrig aufgelöste Version.

[nerd]

Ich habe WPRocket deaktiviert, alle Caches gelöscht, den Rocket CDN ausgeschaltet und gelöscht, das Kritische CSS und Autoptimize deaktiviert und stattdessen LightSpeed aktiviert.

Lazy Load hab ich angeschlatet und auch den Responsive Placeholder aktiviert. Die Bilder above-the-fold hab ich aber bei den Lazy Load Image Excludes ausgeschlossen, sonst erscheinen die wirklich sehr spät im sichtbaren Bereich.

Also genau das gegenteil von allem gemacht was sinnvoll gewesen waere und deine seite schneller gemacht haette?



Antwortzeit des servers von ~300ms rauf auf 560ms. Statt vorher 4.4MB sind es jetzt 7MB am desktop mit 300MBit leitung. Auf dem handy mit 3G laedt die erste seite nach 2 minuten (!) immer noch.

Ich hoffe mal du bist nicht auf den traffic oder irgendwelche werbeeinnahmen der seite angewiesen...

[supervisior]

@Hanzo2012

Natürlich kannst Du so was bis zum Exzess definieren, um auch noch für die exotischste Auflösung das passende Bild bereitzustellen Das kann ich mit klassischem RWD genauso wie mit RESS machen. Das Eine schließt ja das andere nicht aus. Aber wer macht das schon? Du? Auch wenn ich Dir indirekt rechtgebe, setze vermutlich nicht nur ich irgendwo Grenzen und orientiere mich dabei an der Wirtschaftlichkeit und den Fakten aus der Statistik. Wenn ich mit meiner Methode, die ebenfalls das srcset-Attribut verwendet, > 98% aller Nutzer abdecke, dann reicht mir das, zumal man berücksichtigen muss, dass man oftmals gar nicht so große Bilder hat, um es selbst 4K auch noch recht machen zu können. Wir wollen es also nicht übertreiben, oder?

[supervisior]

Ich habe WPRocket deaktiviert, alle Caches gelöscht, den Rocket CDN ausgeschaltet und gelöscht, das Kritische CSS und Autoptimize deaktiviert und stattdessen LightSpeed aktiviert.

Lazy Load hab ich angeschlatet und auch den Responsive Placeholder aktiviert. Die Bilder above-the-fold hab ich aber bei den Lazy Load Image Excludes ausgeschlossen, sonst erscheinen die wirklich sehr spät im sichtbaren Bereich.

Also genau das gegenteil von allem gemacht was sinnvoll gewesen waere und deine seite schneller gemacht haette?



Antwortzeit des servers von ~300ms rauf auf 560ms. Statt vorher 10s ladezeit bei 4.4MB sind es jetzt 19s bei 7MB am desktop mit 300MBit leitung. Auf dem handy mit 3G laedt die erste seite nach 2 minuten (!) immer noch.

Ich hoffe mal du bist nicht auf den traffic oder irgendwelche werbeeinnahmen der seite angewiesen...

Schau Dir bitte mal den HTTP header des Hauptdokuments der aufgerufenen URL an. Wenn Du dort den Header x-litespeed-cache: miss findest, dann lade die Seite erneut und Du wirst den Unterschied feststellen

[nerd]

Schau Dir bitte mal den HTTP header des Hauptdokuments der aufgerufenen URL an. Wenn Du dort den Header x-litespeed-cache: miss findest, dann lade die Seite erneut und Du wirst den Unterschied feststellen

Ja geilo - ladezeiten, antwortzeiten und alle anderen metriken schlimmer als vorher aber schaut her leute - im header steht jetzt "litespeed"!

[Hanzo2012]

Aber wer macht das schon? Du?

Wenn ich eine "bildlastige" Seite hätte, z. B. ein Foto-Blog, dann würde ich das vermutlich tun.

zumal man berücksichtigen muss, dass man oftmals gar nicht so große Bilder hat, um es selbst 4K auch noch recht machen zu können. Wir wollen es also nicht übertreiben, oder?

Zwischen HD und UHD zu unterscheiden finde ich jetzt nicht so übertrieben. Insbesondere Macbooks haben diese hochauflösenden Displays.

Aber davon abgesehen: Es geht ja auch in die andere Richtung, nämlich dynamisch kleinere Varianten bereitstellen. Stell dir z. B. eine Fotogalerie vor. Du kannst die Fotos entweder in der Übersicht als kleine Kacheln sehen (in einem Gitter angeordnet) oder in einer vergrößerten Ansicht. Mit srcset-Attribut kann ich sowohl für das kleine Bild in der Übersicht als auch für das vergrößerte Bild dasselbe HTML-Element nehmen, ich vergrößere es einfach nur, und der Browser sollte daraufhin die passende Auflösung nachladen. Je nach Breite des Viewports könnte sich auch die Anzahl der Bilder pro Zeile im Gitter verändern. Mit srcset vereinfachen sich solche viele Anwendungsfälle enorm. Kombiniert mit modernem CSS gibt's da kaum Grenzen.

[omp-blog]

Also genau das gegenteil von allem gemacht was sinnvoll gewesen waere und deine seite schneller gemacht haette?

Erst einmal ist es ein Test um zu sehen, ob LightSpeed in meinem Fall wirklich besser ist als WPRocket was das reine Caching angeht. Nur so kann ich es leider beurteilen, oder siehst Du da einen anderen Weg?

Klar ist, dass ich anscheinend noch ne Menge andere Sachen machen muss, um die Seite weiter zu optimieren. Aber das geht nicht von heute auf morgen und bei vielen Sachen muss ich auch erst mal schauen, ob ich das mit meinem Wissen überhaupt technisch umsetzen kann.

Ich denke, der Lightspeed ist auch noch nicht komplett fertig konfiguriert. Auch hier muss ich nach und nach noch optimieren. Aber auch da klappt leider nicht alles "out of the box" und ich muss beim Support nachfragen.

Und wenn ich das in den Diskussionen richtig lese, dann gibt es selbst unter Euch Profis zu verschiedenen Punkten ja verschiedene Meinungen. Umso schwerer fällt es mir natürlich als Laie, da am Ende durchzublicken und de richten Weg zu finden.

Ich bin wirklich für jede Hilfe dankbar.

[supervisior]

Aber wer macht das schon? Du?

Wenn ich eine "bildlastige" Seite hätte, z. B. ein Foto-Blog, dann würde ich das vermutlich tun.

zumal man berücksichtigen muss, dass man oftmals gar nicht so große Bilder hat, um es selbst 4K auch noch recht machen zu können. Wir wollen es also nicht übertreiben, oder?

Zwischen HD und UHD zu unterscheiden finde ich jetzt nicht so übertrieben. Insbesondere Macbooks haben diese hochauflösenden Displays.

Aber davon abgesehen: Es geht ja auch in die andere Richtung, nämlich dynamisch kleinere Varianten bereitstellen. Stell dir z. B. eine Fotogalerie vor. Du kannst die Fotos entweder in der Übersicht als kleine Kacheln sehen (in einem Gitter angeordnet) oder in einer vergrößerten Ansicht. Mit srcset-Attribut kann ich sowohl für das kleine Bild in der Übersicht als auch für das vergrößerte Bild dasselbe HTML-Element nehmen, ich vergrößere es einfach nur, und der Browser sollte daraufhin die passende Auflösung nachladen. Je nach Breite des Viewports könnte sich auch die Anzahl der Bilder pro Zeile im Gitter verändern. Mit srcset vereinfachen sich solche viele Anwendungsfälle enorm. Kombiniert mit modernem CSS gibt's da kaum Grenzen.

Du hast mit allem, was Du sagst recht, wobei ich Dir nur bedingt dahingehend widerspreche, dass ich es nicht allein dem Browser überlasse, welches Bild ich welchem Gerät anzeigen lasse. Im Grunde genommen nehme ich nur eine serverseitige Filterung vor, womit ich schon mal >98% alles abdecke. Eine nochmalige Selektierung, bzw. Differenzierung mittels srcset-Attribut erspare ich mir damit, zumal ich gar nicht so große Bilder habe, dass ich Mannsgroße Auflösungen auch noch abdecken könnte. Ob man das nun bis zur 100%igen Vollständigkeit auch noch abdecken muss/sollte, ist eine Fallentscheidung abhängig vom Thema einer Seite, also z.B. Foto Seite oder ähnlich.

Mir gehts letztlich nur darum vorhandenes auf Server Seite mit Minimalstaufwand zu nutzen, dass ich den Browser erst gar nicht in Verlegenheit bringen muss sich irgendwas raussuchen zu müssen. Ich decke ja alles ab und unterm Strich sind meine Seiten x-fach schneller als so ziemlich jede andere. Zumal Pagespeed für mich kein Thema ist. Da weiß ich schon vor dem testen, dass ich einen Score von 100 auf allen Geräten habe.