Optimierte Bilder mit Google Page Speed Insights runterlagen

[Hanzo2012]

Wieso sollte eine URL mit "Versionsnummer" nicht gecached werden? Das wäre mir neu. ModPagespeed hängt genau zu diesem Zweck eine "Versionsnummer" an die Ressourcen dran, die sich aus einem Hash der Ressource ableitet. So kann man mit sehr langen Cache-Zeiten arbeiten (1 Jahr), da sich die URL automatisch ändert, sobald sich die Ressource ändert. Der Client muss dann eben nicht immer beim Server anfragen, ob seine gecachte Version noch aktuell ist (E-Tag oder Änderungsdatum).

[staticweb]

> Wieso sollte eine URL mit "Versionsnummer" nicht gecached werden?

Ja, du hast natürlich recht. Das war meinerseits etwas unklar formuliert. Ich wollte Supervisior nur den Vorteil des Versions-Parameters erklären. Das Client-Caching wird natürlich bei modernen Browsern über die Cache Control Policy gesteuert.

Allerdings sollte man dann auch aufpassen, dass die HTML-Seite nicht gecached wird, sonst erfährt der Browser nichts von der Änderung.

Im übrigen gibt es Empfehlungen die eine Dateinamen-Änderung der Parameter-Version vorziehen. Gründe sind wohl Proxy- und Performance Probleme.

Hier noch 2 Links zu diesem Thema:

https://developers.google.com/web/funda ... hing?hl=de

https://www.stevesouders.com/blog/2008/ ... erystring/

Es wäre zu klären ob dies bei HTTP/2 noch eine Rolle spielt.

[supervisior]

Wieso sollte eine URL mit "Versionsnummer" nicht gecached werden? Das wäre mir neu. ModPagespeed hängt genau zu diesem Zweck eine "Versionsnummer" an die Ressourcen dran, die sich aus einem Hash der Ressource ableitet. So kann man mit sehr langen Cache-Zeiten arbeiten (1 Jahr), da sich die URL automatisch ändert, sobald sich die Ressource ändert. Der Client muss dann eben nicht immer beim Server anfragen, ob seine gecachte Version noch aktuell ist (E-Tag oder Änderungsdatum).

Dass Du das nicht weißt, wundert mich dann schon?! (Hab aber schon darauf gewartet, dass Du Dich deswegen meldest. )Is aber so, wobei das vornehmlich ein Problem im Chrome ist. 1 Mio mal ausgetestet. Oder andersherum, suche mal nach einem Hack wie man den Chrome dazu bringt eine CSS Datei neu zu laden. Welche Cache Zeiten Du da definiert hast, ist dem Chrome nahezu Pippi. Einmal geladen, verwendet er solange die gleiche CSS, wie der Cache nicht geleert wird oder es eine neue Versionsnummer gibt.

Ich bin kein Freund von Mod Pagespeed, eben wegen der besagten Widrigkeiten und nicht nur wegen Cache Verhalten.

[supervisior]

> Wieso sollte eine URL mit "Versionsnummer" nicht gecached werden?

Ja, du hast natürlich recht. Das war meinerseits etwas unklar formuliert. Ich wollte Supervisior nur den Vorteil des Versions-Parameters erklären. Das Client-Caching wird natürlich bei modernen Browsern über die Cache Control Policy gesteuert.

Allerdings sollte man dann auch aufpassen, dass die HTML-Seite nicht gecached wird, sonst erfährt der Browser nichts von der Änderung.

Im übrigen gibt es Empfehlungen die eine Dateinamen-Änderung der Parameter-Version vorziehen. Gründe sind wohl Proxy- und Performance Probleme.

Hier noch 2 Links zu diesem Thema:

https://developers.google.com/web/funda ... hing?hl=de

https://www.stevesouders.com/blog/2008/ ... erystring/

Es wäre zu klären ob dies bei HTTP/2 noch eine Rolle spielt.

Für Proxies verwende ich die no-transform Anweisung. Das hat aber andere Gründe, was mit meinem Lichtgeschwindigkeits-Server zu tun hat.

Header set Cache-Control "xxxx, xxx, no-transform"

[staticweb]

> Oder andersherum, suche mal nach einem Hack wie man den Chrome dazu bringt eine CSS Datei neu zu laden.

Hast du mal ein neutrales Beispiel mit welcher Konfiguration es im Chrome nicht klappen soll?

Ich vermute mal der Grund liegt im caching des documents.

[supervisior]

Es könnte durchaus sein, dass das am caching des Documents liegt, wobei das aber eben nur auffällig beim Chrome so ist. Ich hatte erst vor kurzem ein massives Problem damit als es darum ging eine js Datei zu laden, wenn eine bestimmte js Bedingung erfüllt ist, welche aber im HTML Code als inline script definiert war. Der Chrome wollte sich absolut nicht an diese Bedingung halten, bzw. hat den im Cache verwendeten Code verwendet. Erst als ich der zu ladenden js Datei eine Versionsnummer, bzw. einen ständig wechselnden Parameter ( ?time() ) angehängt hatte, ließ sich Chrome dazu überreden diese js Datei zu laden.

Der Chrome ist in dieser Hinsicht extrem und schert sich sehr oft um Standards wie z.B. Cache Verfallszeiten usw., besonders bei den mobilen Nutzern. Google speichert js und css Dateien und schickt besonders aber nicht nur mobilen Geräten die selbst gespeicherten Versionen von css und js Dateien, was besonders bei der Versionisierung fatale Auswirkungen haben kann.

[staticweb]

> Es könnte durchaus sein, dass das am caching des Documents liegt, wobei das aber eben nur auffällig beim Chrome so ist.

Danke ich auch. Eigentlich sollten sich alle modernen Browser an die cache control policy halten.

> Der Chrome ist in dieser Hinsicht extrem und schert sich sehr oft um Standards wie z.B. Cache Verfallszeiten usw.,

Das wäre möglich, aber an die cache control policy sollte er sich eigentlich halten.

> besonders bei den mobilen Nutzern.

Das ist noch einmal ein anderes Thema. Hier musst du noch einmal einen Unterschied zwischen Mobilfunk und WLAN machen, da einige Provider (Vodafone) hier Inhalte verfälschen um Bandbreite zu sparen.

[supervisior]

> Es könnte durchaus sein, dass das am caching des Documents liegt, wobei das aber eben nur auffällig beim Chrome so ist.

Danke ich auch. Eigentlich sollten sich alle modernen Browser an die cache control policy halten.

> Der Chrome ist in dieser Hinsicht extrem und schert sich sehr oft um Standards wie z.B. Cache Verfallszeiten usw.,

Das wäre möglich, aber an die cache control policy sollte er sich eigentlich halten.

> besonders bei den mobilen Nutzern.

Das ist noch einmal ein anderes Thema. Hier musst du noch einmal einen Unterschied zwischen Mobilfunk und WLAN machen, da einige Provider (Vodafone) hier Inhalte verfälschen um Bandbreite zu sparen.

Wie schon erwähnt. Google setzt sich schon seit längerem über so ziemlich alles hinweg. Das soll letztlich zwar dazu dienen, dass die Inhalte schneller beim Nutzer sind, aber es gibt keine Möglichkeit das zu unterbinden, wobei das mit dem Cachen keineswegs ein Einzelfall ist.

[supervisior]

Es führt zwar etwas am Hauptthema vorbei, aber bietet mir eine Steilvorlage für mein Lieblingsthema "Optimieren".

Der Großteil der Welt kennt eigentlich nur Apache und ein kleiner Rest nginx. Ohne mich jetzt über diese beiden Server Lösungen auszulassen, gehts mir eigentlich mehr darum, dass vermutlich 98% all jener, die für Ihre Seite zum Thema Optimieren was gemacht haben, nur einen Bruchteil dessen optimiert haben, was überhaupt möglich ist. Allerdings in dem Glauben sind, dass man das Möglichste schon gemacht hätte.

Um hier tatsächlich was zu optimieren, das sich im Vergleich zu den herkömmlichen Optimierungsmethoden wie ein Turbo mit Lachgas Einspritzung verhält, muss man die Sache an der Wurzel anpacken, also am Webserver selbst. Damit sind aber keine Optimierungsmethoden an der Konfiguration des Servers gemeint. Damit lässt sich zwar auch etwas rausholen, aber die Möglichkeiten sind nicht nur begrenzt, sondern lohnen zumeist den Aufwand gar nicht. Außerdem brauchts dafür wirkliches Experten KnowHow, was die wenigsten haben.

Das grundsätzliche Problem ist wie schon erwähnt die Wurzel, bzw. das Übel der Wurzel und ist sog. systemisch und liegt in der Architektur der beiden bekannten Server Lösungen zugrunde und lässt sich auch nicht wegoptimieren. Da helfen auch noch so gute Optimierungsmaßnahmen für den Client, wenn der Server zu lahm ist und das ungeachtet der Hardware, bzw. der System Ressourcen, wie CPU, RAM, HDD usw..

Nur um einen kleinen Ausblick zu geben nachfolgend mal eine Gegenüberstellung der gemessenen Zeiten wie lange es dauert bis der Server den Zeitpunkt erreicht hat den generierten Code an den Client zu schicken, exklusive der statischen Sourcen. (zu finden in der access.log, wenn man %D konfiguriert hat)

Jeweils gleiche Seite, gleicher Browser bei geleertem Cache auf einem Managed Server

Apache:
*******
91373 µs -> 91,373 ms -> 0,091373 s

"Lichtgeschwindigkeitsserver":
************************
418 µs -> 0,418 ms -> 0,000418 s

Unterschied: ~20.000% oder Faktor ~220

Das ist jetzt nur ein Beispiel von vielen und um das der messbaren Realität im Browser etwas näher zu bringen, bedeutet der obige Vergleich in der Praxis eine Beschleunigung der Ladezeit um den Faktor 10. Wenn man also in der Developer Console des Browsers z.B. 240ms für das Laden des Hauptdokumentes messen würde, würden daraus dann 20ms. Der Unterschied wird dann aber noch deutlicher, weil zum Hauptdokument ja noch die statischen Sourcen hinzukommen, die um einen ähnlichen Faktor schneller übertragen werden als mit den herkömmlichen Server Lösungen.

Die bekannten Optimierungsmethoden sind zwar immer nötig und verstehen sich eigentlich als selbstverständlich, aber wenn man wirklichen Speed haben will, muss man das Übel an der Wurzel anpacken, aber ohne zum IT-Experten werden zu müssen und einen HighEnd Server verwenden zu müssen. VPS genügt.

[nerd]

Apache:
*******
91373 µs -> 91,373 ms -> 0,091373 s

"Lichtgeschwindigkeitsserver":
************************
418 µs -> 0,418 ms -> 0,000418 s

Unterschied: ~20.000% oder Faktor ~220

Was ist dass denn fuer eine michmaedchenrechnung?

Bei mir dauert jede neue verbindung mindestens 500-800ms in welcher DNS lookup, initial connection und SSL ausgehandelt werden, aus dem mobilfunknetz noch laenger. On dein server da 0.01ms oder 10ms braucht bis er die gewuenschte seite liefern kann faellt dabei ueberhaupt nicht ins gewicht.

Das ist jetzt nur ein Beispiel von vielen und um das der messbaren Realität im Browser etwas näher zu bringen, bedeutet der obige Vergleich in der Praxis eine Beschleunigung der Ladezeit um den Faktor 10.

Ja, aber nur wenn der kunde bis in dein rechenzentrum kommt und seinen PC per twisted pair kabel direkt hinten an deinen server anklemmt - ansonsten haettest du noch das internet mit der oben genannten verzoegerung dazwischen.

[staticweb]

> Apache: 91,373 ms <--> Lichtgeschwindigkeitsserver: 0,418 ms

Von welchen Zeiten reden wir hier? TTFB oder ...?

Wenn ich einen Ping zu diesem Host schicke benötigt die Antwort bereits 30ms. Das ist schon fast die unterste Ebene. Im lokalen Netzwerk komme ich schon auf unter 1ms, aber es ist unrealistisch das im Internet zu erwarten.

Du solltest deine Messungen am Ziel und nicht an der Quelle machen!

[supervisior]

Apache:
*******
91373 µs -> 91,373 ms -> 0,091373 s

"Lichtgeschwindigkeitsserver":
************************
418 µs -> 0,418 ms -> 0,000418 s

Unterschied: ~20.000% oder Faktor ~220

Was ist dass denn fuer eine michmaedchenrechnung?

Bei mir dauert jede neue verbindung mindestens 500-800ms in welcher DNS lookup, initial connection und SSL ausgehandelt werden, aus dem mobilfunknetz noch laenger. On dein server da 0.01ms oder 10ms braucht bis er die gewuenschte seite liefern kann faellt dabei ueberhaupt nicht ins gewicht.

Das ist jetzt nur ein Beispiel von vielen und um das der messbaren Realität im Browser etwas näher zu bringen, bedeutet der obige Vergleich in der Praxis eine Beschleunigung der Ladezeit um den Faktor 10.

Ja, aber nur wenn der kunde bis in dein rechenzentrum kommt und seinen PC per twisted pair kabel direkt hinten an deinen server anklemmt - ansonsten haettest du noch das internet mit der oben genannten verzoegerung dazwischen.

Tust Du Dir bitte einen Gefallen und liest was ich geschrieben haben bitte nochmal? Wenn Du es dann immer noch nicht verstanden hast, schreib ich extra für Dich ein HowTo.

[supervisior]

> Apache: 91,373 ms <--> Lichtgeschwindigkeitsserver: 0,418 ms

Von welchen Zeiten reden wir hier? TTFB oder ...?

Wenn ich einen Ping zu diesem Host schicke benötigt die Antwort bereits 30ms. Das ist schon fast die unterste Ebene. Im lokalen Netzwerk komme ich schon auf unter 1ms, aber es ist unrealistisch das im Internet zu erwarten.

Du solltest deine Messungen am Ziel und nicht an der Quelle machen!

Du denkst komplett falsch und in die falsche Richtung. Nix Ping oder was Du sonst kennst. Es geht, wie oben schon beschrieben, um die Verarbeitungszeit und nicht darum, wie schnell etwas übertragen werden kann. Das kommt danach und ist relativ. Bevor ich mich jetzt darüber auslasse, hast Du die Möglichkeit die Ausgabe Deiner access_log zu verändern? [LogFormat (combined)] Wenn ja, würde das das Verständnis erheblich verbessern.

[staticweb]

> Es geht, wie oben schon beschrieben, um die Verarbeitungszeit und nicht darum, wie schnell etwas übertragen werden kann.

Das war ja meine Frage um welche Zeiten es bei dir geht.

Es ist schon klar, dass das bauen einer dynamischen Website die meiste Zeit kostet. Wenn du an dieser Stelle optimieren willst musst du PHP zu C++ (HPHPc) oder Bytecode (HHVM) kompilieren.

> hast Du die Möglichkeit die Ausgabe Deiner access_log zu verändern? [LogFormat (combined)]

Das ist schon eingestellt und fügt den Referrer und den User Agent hinzu. Was soll mir das bringen?

[supervisior]

Da muss man nix kompilieren oder das Rad neu erfinden. Referrer und User Agent sind doch Standard. Was willstn jetzt damit?!

Egal, ruf mal die Apache Seite auf und scroll runter zu "%D" bei den Custom Log Formats und lese was dazu als Beschreibung steht.

https://httpsd.apache.org/docs/2.4/mod/ ... #logformat