Ladezeit & Antwortzeit (Seite 2)

arnego2 schrieb:
Für mich will Google uns ablenken von den tatsächlichen Dingen des Lebens, Dinge die wichtiger sind als sich um 20% schneller ladende Webseiten zu kümmern.
Ich bei Geschwindigkeiten von um die 15 mb/s was macht das ein Reduzierung aus? Eine 10tel Sekunde?

Ich hatte mich bei meiner Frage nur auf den speziellen Fall mit Xenotyps Bildern bezogen.

Allgemein muss ich Dir aber widersprechen. In Zeiten exponentiell wachsenden Datenverkehrs finde ich es richtig, Entwickler zu sensibilisieren, ihre Datenmenge im Auge zu behalten.
Beim einzelnen Request sind Zehntelsekunden keine große Sache, aber bei größeren Zugriffszahlen summiert sich die Einsparung massiv. Und das ist es, was ich wichtig finde.

Es ist für jemanden, der Kunst verkauft, völliger Unsinn, die Online-Bilder klein zu rechnen und als jpgs mit 70% Qualität hochzuladen. Aber sie so sparsam wie möglich zu präsentieren und anzubieten, ist völlig korrekt.
Pagespeed ist dabei keine Vorgabe, sondern das rein auf die Daten bezogene ideal mögliche Maximum. Dass man dabei als Entwickler abwägen muss, wo die Grenze zur sinnvollen Darstellung gezogen wird, sollte jedem Profi klar sein.
Ich sage es hier immer wieder: entwickelt für die Benutzer, nicht für die Tools.

Matthes schrieb:

Ich sage es hier immer wieder: entwickelt für die Benutzer, nicht für die Tools.

Das sowieso, obwohl die Tools diesen Weg meist ebnen. In diesem Fall hat mich das Tool jedoch völlig verwirrt, da es mir bereits angezeigt hat dass alles OK ist und das Nachbessern via TinyPNG nicht einmal was gebracht hat. Wenn ich da noch etwas hätte rauskitzeln können, hätte ich das natürlich sofort gemacht.

Daheim habe ich die PSDs zu meiner Website, da werde ich die Grafiken noch einmal mit veränderter Kompression neu erstellen, mal sehen ob Insights, mir dann immer noch so seltsame Ergebnisse liefert.

Xenotyp schrieb:

Matthes schrieb:

Ich sage es hier immer wieder: entwickelt für die Benutzer, nicht für die Tools.

Das sowieso, obwohl die Tools diesen Weg meist ebnen. In diesem Fall hat mich das Tool jedoch völlig verwirrt, da es mir bereits angezeigt hat dass alles OK ist und das Nachbessern via TinyPNG nicht einmal was gebracht hat. Wenn ich da noch etwas hätte rauskitzeln können, hätte ich das natürlich sofort gemacht.

Daheim habe ich die PSDs zu meiner Website, da werde ich die Grafiken noch einmal mit veränderter Kompression neu erstellen, mal sehen ob Insights, mir dann immer noch so seltsame Ergebnisse liefert.

Du darfst nicht vergessen das beim Berechnen der zu sparenden Datenmenge ein 0.1kb immer noch weniger ist auch wenn das bild selbst 1 mb hat. So muß den eigene Kopf anschalten um zu sehen das der Arbeitsaufwand zur Einsparung in keiner Relation steht. Da stimme ich mit Matthes voll überein. Egal ist es nicht wie schnell dein Webseite lädt nur so außergewöhnlich wichtig ist es auch nicht.

Lade dir den TOR Browser runter und sehe dir das laden deiner Webseite an unter gethrottleten Bedingungen. Wenn deine Webseite einigermaßen gut lädt hast du kein Problem.

Ich denke ich weiß nun, warum Google die Zügel bei der Bildkompression angezogen hat. Gestern haben sie ein neues Tool zum komprimieren von JPGs vorgestellt: research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html

Wow... Noch einmal 35% kleiner als aktuelle Methoden. Nicht schlecht.

Klingt wirklich gut. Ich will das auf jeden Fall ausprobieren.

Matthes schrieb:

Wow... Noch einmal 35% kleiner als aktuelle Methoden. Nicht schlecht.

Besser nicht alles glauben was geschrieben steht

Rodrigo Polo schrieb:
I have tried this software, using it with the flags:
--quality 86 --verbose png.png gt-q86.jpg
It produces a file that is 1k bigger than the version generated with Adobe Photoshop at q60 and has more visible artifacts, I did other tests with similar results, so, I believe it needs some polishing.

Was unglaublich ist das von 197 Leuten die hurra geschrieben haben nur 2 dabei waren es auszutesten und ihre Zweifel anzumelden. ;( Wie unkritisch wir geworden sind. Erschreckend eigentlich.

arnego2 schrieb:
Besser nicht alles glauben was geschrieben steht

Ja, ich hätte im Konjunktiv schreiben sollen. Mal schauen, was dabei herumkommt, ich werde es später mal ausprobieren und selbst schauen, was es kann.

Matthes schrieb:

arnego2 schrieb:
Besser nicht alles glauben was geschrieben steht

Ja, ich hätte im Konjunktiv schreiben sollen. Mal schauen, was dabei herumkommt, ich werde es später mal ausprobieren und selbst schauen, was es kann.

Das ist ein super Idee so wissen wir es aus erster Hand und nicht nur kopiert aus Foren was irgendwie wenig Beweiskraft hat. Halt uns auf den laufenden

Ich habe es jetzt einmal ausprobiert. Die fertige Binary gegen tinypng und jpegmini, alle in Standardeinstellungen, mit dem Beispielbild von GitHub und drei eigenen Fotos unterschiedlicher Größe, die alle den Hinweis von Guetzli erfüllen:
"Note that Guetzli is designed to work on high quality images (e.g. that haven\'t been already compressed with other JPEG encoders)"

Größenangaben in Bytes.

Guetzli-Beispiel "bees"
177.424

Guetzli
37.910 (21,37%)
jpegmini
ging nicht, Quelle ist png
tinypng
59.149 (33,34%)


Privates Foto 1
134.927

Guetzli
47.463 (35,18%)
jpegmini
20.971 (15,54%)
tinypng
33.280 (24,67%)


Privates Foto 2
1.595.290

Guetzli
581.659 (36,46%)
jpegmini
460.029 (28,84%)
tinypng
349.259 (21,89%)


Privates Foto 3
4.049.546

Guetzli
1.493.802 (36,89%)
jpegmini
1.260.747 (31,13%)
tinypng
1.041.044 (25,71%)

Guetzli gewinnt nur beim eigenen Beispielbild. Allerdings habe ich nicht weiter überprüft, ob jpegmini und tinypng eventuell die Qualität des Ergebnisses herunterdrehen, Guetzli lief auf 100%.

Bei den beiden großen Bildern lief Guetzli über 5 Minuten und hat bis zu 2,5GB RAM benötigt.

Für das letzte Bild habe ich Guetzli testweise noch einmal mit 84% Qualität laufen lassen (weniger geht mit den fertigen Binaries nicht und würde Veränderungen im Quellcode erfordern), das Ergebnis liegt aber auch über dem von tinypng:

Guetzli 84%
1.058.897 (26,15%)