-
"deutlich schneller laden"
Autor: Unix_Linux 22.06.17 - 13:56
Naja deutlich kann es nicht sein. Ihr schreibt ja selber das es 15% Einsparung gibt.
Damit sollte es bestenfalls ein paar Prozent schneller sein, da die Webseite ja nicht nur aus Werbung besteht.
Unter deutlich verstehe ich was anderes.
Ich finde golem benutzt das Wort "deutlich" sehr inflationär. In fast jedem Beitrag ist immer von "deutlich" die Rede.
Seid doch bitte so nett und versucht da nicht immer so zu übertreiben. -
Re: "deutlich schneller laden"
Autor: spaceMonster 22.06.17 - 14:29
Wenn du 10000 Server hast die auf Volllast Werbung ausliefern und du plötzlich 1500 davon abschalten* könntest ist das mehr als deutlich.
Google macht das um mehr zu verdienen und nicht primär damit der Kunde 2 Sekunden schneller sein Katzenvideo sehen kann. -
Re: "deutlich schneller laden"
Autor: PiranhA 22.06.17 - 14:45
spaceMonster schrieb:
--------------------------------------------------------------------------------
> Google macht das um mehr zu verdienen und nicht primär damit der Kunde 2
> Sekunden schneller sein Katzenvideo sehen kann.
Zum einen spart Google so natürlich Traffic, aber gleichzeitig erhöht es auch die Akzeptanz beim Nutzer. Wenn die Werbung nicht mehr so stark stört, bin ich weniger geneigt diese zu blockieren. Aus dem gleichen Grund plant Google einen eigenen Werbeblocker für Chrome, welcher gezielt als besonders nervig empfundene Werbung blockiert (aber eben nicht alles). -
Re: "deutlich schneller laden"
Autor: Sammie 22.06.17 - 14:58
Unix_Linux schrieb:
--------------------------------------------------------------------------------
> Naja deutlich kann es nicht sein. Ihr schreibt ja selber das es 15%
> Einsparung gibt.
>
> Damit sollte es bestenfalls ein paar Prozent schneller sein, da die
> Webseite ja nicht nur aus Werbung besteht.
Wird wohl eh nur um den reinen Scriptcode hinter der Werbung gehen, also Javascript-Files. Denn es macht absolut Null Sinn bestehende Grafikformate wie gif, jpg oder png mit Brotli zu komprimieren, da deren Daten alle bereits eine gzip/deflate Komprimierung nutzen. Würde man da Brotli drüber laufen würden die Files durch dessen Headerinfos eher größer statt kleiner werden und doppelt so lag zum Dekomprimieren brauchen. ^^
Abgesehen davon, dass Brotli nur minimal bessere Kompression besitzt, sind dessen Kompressionszeiten auf den höheren Kompressionstufen um ein zigfaches höher als bei gzip - und das nicht nur 2fach oder 3fach, sondern zig 100fach, was für on-the-fly-Kompressionen im Gegensatz zu gzip absolut unbrauchbar ist. In der Hinsicht ist brotli relativ lahm. Für statische Scripts & CDN-Files usw taugts aber, wenn mans nur einmal komprimiert und dann die Files an mehrere Clients so ausliefert.
Auf der Clientseite nehmen sich gzip und brotli dagegen fast nichts, was die Dekomprimierungszeit angeht, aber Brotli verbraucht beim Dekomprimierungsprozess etwas mehr Speicher. Letztendlich verringert sich primär die Datenmenge und dadurch auch die Zeit, die für die Übertragung benötigt wird - das ist der Hauptvorteil von Brotli. Die Zeit, die serverseitig zum Komprimieren benötigt wird, ist dagegen höher. Daher sollte man immer überlegen, wann gzip und wann brotli die bessere Wahl ist. Und man sollte natürlich immer bedenken, dass Brotli in diversen ältern Browsern schlicht nicht existiert. Mit dem guten alten gzip kann man dagegen nichts falsch machen. ^^
1 mal bearbeitet, zuletzt am 22.06.17 15:00 durch Sammie. -
Re: "deutlich schneller laden"
Autor: Unix_Linux 22.06.17 - 17:02
Ganz zu schweigen von dem mehr Verbrauch an Strom beim komprimieren. Brotli scheint viel mehr CPU Leistung zu benötigen.



