CnC: Cache&Compress für CMSimple_XH
Re: CnC: Cache&Compress für CMSimple_XH
Und woran sehe ich das bzw. wo kann ich das überprüfen?
Re: CnC: Cache&Compress für CMSimple_XH
Zum Beispiel, wenn in deinem Template JS eingebunden wird, dass schon minifiziert ist - als z.B. javascript.min.js.
Und, wenn die Stylesheets und JavaScripte sowieso sehr klein sind, ist der Effekt auch nicht sehr groß.
Aber, das ist nur so eine Vermutung.
Wie oben beschrieben, kann es auch Server-Ursachen haben.
Rufe doch mal die selbe Seite auf mit dem Parameter &nocache.
http://example.com?&nocache
oder muss es heißen:
http://example.com&nocache
Holger?
Und, wenn die Stylesheets und JavaScripte sowieso sehr klein sind, ist der Effekt auch nicht sehr groß.
Aber, das ist nur so eine Vermutung.
Wie oben beschrieben, kann es auch Server-Ursachen haben.
Rufe doch mal die selbe Seite auf mit dem Parameter &nocache.
http://example.com?&nocache
oder muss es heißen:
http://example.com&nocache
Holger?
Re: CnC: Cache&Compress für CMSimple_XH
Aus https://example.de?&nocache wird automatisch https://example.de/?&nocache gemacht.
Bei http://example.de&nocache/ wird gemeldet, dass PageSpeed nur gültige HTTP- oder HTTPS-URLs analysieren kann .
Bei http://example.de&nocache/ wird gemeldet, dass PageSpeed nur gültige HTTP- oder HTTPS-URLs analysieren kann .
Re: CnC: Cache&Compress für CMSimple_XH
Ich denke, das hat wenig mit der Minifizierung zu tun. Relevanter für Pagespeed dürfte einerseits komprimierte Auslieferung und andererseits passende Caching-Header sein. Das macht der Server aber u.U. auch ohne CnC Plugin.frase wrote:Das liegt möglicherweise daran, dass das Meiste schon minifiziert ist ???
Christoph M. Becker – Plugins for CMSimple_XH
Re: CnC: Cache&Compress für CMSimple_XH
Das ein "?" vor den ersten URL-Parameter gehört hatte ich vorausgesetzt. Sorry für die Verwirrung.mhz wrote:Aus https://example.de?&nocache wird automatisch https://example.de/?&nocache gemacht.
Bei http://example.de&nocache/ wird gemeldet, dass PageSpeed nur gültige HTTP- oder HTTPS-URLs analysieren kann .
Richtig ist im konkreten Fall also:
Code: Select all
http://example.com?&nocache
Das die Seite so schlechte Ergebnisse liefert, kann an vielen Dingen liegen. Caching und Kompression ist nur ein kleiner Baustein. Die Details zur Fehlerbehebung werden dir doch unter den Links auf der Ergebnisseite angezeigt.mhz wrote:Danke für den Link mit der Speed-Testseite!
Ich habe das gerade bei einer aktiven Homepage getestet.
ohne CnC:
Mobile = Poor 53 / 100
Desktop = Needs Work 67 / 100
mit CnC:
Mobile = Poor 54 / 100
Desktop = Needs Work 70 / 100
Mehrfach Cache geleert, es bleibt dabei.
Gerne kannst du auch mal die URL zu der Testseite hier posten.
Re: CnC: Cache&Compress für CMSimple_XH
Zumindest gibt es einen sehr deutlichen Unterschied beim ersten Besuch der Seite: durch die Komprimierung von HTML und allen Assets werden deutlich weniger Daten übertragen.cmb wrote:Ich habe mir zunächst einmal das Netzwerk-Tab für meine XAMPP Installation genauer angeschaut, und musste feststellen, dass es eigentlich kaum einen Unterschied macht, ob CnC aktiviert ist oder nicht. Da wird so wie so extrem aggressiv gecache't. Dann mal mit Portable_XH ausprobiert, und da macht es wirklich den gewünschten/erhofften Unterschied. Daraufhin habe ich mir 3-magi.net und cmsimple.holger-irmler.de angeschaut, und beide Sites werden ebenfalls aggressiv gecache't. Hauptsächlich ausprobiert mit einem aktuellen Chrome, aber ein aktueller Firefox verhält sich wohl bezüglich des Caching gleich. Und ja, ganz offensichtlich hängt das vermutlich v.a. vom Server ab: XAMPP und cmsimple.holger-irmler.de senden E-Tag-Header, 3-magi.net Last-Modified, aber Portable_XH eben nichts dergleichen. Was mich allerdings wundert, ist, dass der Chrome anscheinend bei 3-magi.net gar nicht mehr nachfragt, ob die Datei aktualisiert wurde (das Netzwerk-Tab zeigt 200). Müsste man sich vielleicht mit einem Netzwerksniffer noch mal genauer anschauen.
Was das Caching angeht: natürlich haben Client und Server Caching-Strategien implementiert. Allerdings hat der User normalerweise keine Kontrolle über die Einstellungen. Das Assets dann über einen bestimmten Zeitraum, den ich nicht beeinflussen kann, gültig bleiben, obwohl auf dem Server neuere Versionen liegen, halte ich für einen (faulen) Kompromiss.
Das man Minifizierung, Komprimierung und Caching auch mit anderen Methoden hinbekommt, ist mir schon klar. Mit CnC geht es aber "out of the Box" und man kann sicher sein, dass immer die aktuellste Version der Assets an den Besucher gesendet wird obwohl die Gültigkeitsdauer einer einmal heruntergeladenen Datei bei einem Jahr liegt.
Ob HTTP/2.0 wirklich so der Bringer für alle (insbesondere eher kleine XH-) Seiten sein wird, mag dahingestellt sein. So sicher scheinen auch Experten da nicht zu sein, Stichwort: TCP Slow Start. Außerdem frage ich mich, wann HTTP/2.0 "flächendeckend verfügbar" ist. IMO sollte der Standard schon Mitte 2014 festgenagelt sein. Auch die Browser und Server sind doch bereits verfügbar.cmb wrote:Das wäre schon wünschenswert, ist aber durch HTTP/2.0 eventuell gar nicht mehr wirklich wichtig.Holger wrote: Was fehlt ist die Verringerung der Seitenanfragen am Server (Requests), was durch zusammenführen mehrerer Dateien zu einer Anfrage möglich ist.
Back to topic: alle Assets die im <head> der Seite stehen, blockieren das Rendering der Seite. Es würde also eine kleine Verbesserung sein, wenn die dort enthaltenen CSS und JS-Dateien jeweils zu einem einzigen Request zusammengefasst werden. Bei ein paar zusätzlich installierten Plugins könnte man da durchaus etwas sparen. Nur das Template-CSS müsste exklusiv geladen werden, weil hier @import erlaubt ist, was ja bekanntlich nur ganz am Anfang der Datei erlaubt ist. Aber alles was im <body> steht würde ich nicht anfassen. Zumal schon heute Mode ist CSS-Dateien per <link> Element auch im <body> zu laden - "Above the fold" lässt grüßen.
Da bin ich mir nicht sicher, ob das eine Lösung für die Allgemeinheit sein kann. Ich glaube nicht, dass der größte Teil der User die Bedeutung und die Auswirkungen des Features versteht und richtig verwendet.cmb wrote:Was vielleicht noch sehr interessant wäre, wäre die optionale Integration von Cache_XH (jedenfalls sinngemäß); das könnte zumindest für CMSimple_XH Sites bei denen sich nur selten was ändert interessant sein.
Da CnC aber zumindest die Seiten mit E-Tag Header schickt und bei Übereinstimmung einen 304 Not modified Header anstatt der ganzen Seite sendet, ist das in meinen Augen ein guter Kompromiss. Zumal auch hier dynamische Änderungen durch Plugins (Quote of the day zum Beispiel) erkannt werden und der Besucher wirklich den vorgesehenen Inhalt zu Gesicht bekommt. Das wird mit statisch per Cache_XH gesetzten Gültigkeitszeiträumen schwierig.
Re: CnC: Cache&Compress für CMSimple_XH
Ups, noch vergessen:
Wenn du das Bild dann mal aktualisierst und du möchtest, dass es trotzdem jeder Stammbesucher auch gleich geliefert bekommt kannst du es einfach unter einem andern Namen einbinden. Alternativ kann auch ein Parameter, den du mit einem vorangestelltem Fragezeichen an den Dateinamen anhängst, zur sofortigen Auslieferung der neuen Bildversion "missbraucht" werden.
Da gibt es mehrere Möglichkeiten. Hier mal eine Variante:mhz wrote:Was wird denn in die .htaccess -Datei eingetragen?Cachen von Bildern etc. aus dem Userfiles-Ordner lässt sich per .htaccess
Code: Select all
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 7 days"
ExpiresByType image/ico "access plus 7 days"
ExpiresByType image/jpeg "access plus 7 days"
ExpiresByType image/jpg "access plus 7 days"
ExpiresByType image/png "access plus 7 days"
</IfModule>
Re: CnC: Cache&Compress für CMSimple_XH
Die Server, die ich mir angeschaut hatte, haben das bereits "selbst" so gemacht.Holger wrote:Zumindest gibt es einen sehr deutlichen Unterschied beim ersten Besuch der Seite: durch die Komprimierung von HTML und allen Assets werden deutlich weniger Daten übertragen.
Ich auch. Allerdings wurden bei XAMPP und cmsimple.holger-irmler.de bereits ETags ausgeliefert (weiß nicht, ob per mtime oder Content-Hash generiert, aber im Zweifel ist beides ja okay).Holger wrote:[…] Das Assets dann über einen bestimmten Zeitraum, den ich nicht beeinflussen kann, gültig bleiben, obwohl auf dem Server neuere Versionen liegen, halte ich für einen (faulen) Kompromiss.
CnC ist auf jeden Fall gut. Ich wollte es nicht schlecht reden (falls das so verstanden wurde), sondern war über das bereits ohne CnC erfolgte Caching sehr überrascht.Holger wrote:Das man Minifizierung, Komprimierung und Caching auch mit anderen Methoden hinbekommt, ist mir schon klar. Mit CnC geht es aber "out of the Box" und man kann sicher sein, dass immer die aktuellste Version der Assets an den Besucher gesendet wird obwohl die Gültigkeitsdauer einer einmal heruntergeladenen Datei bei einem Jahr liegt.
Interessant. Danke!Holger wrote:Stichwort: TCP Slow Start.
Gute Frage. Es scheint sich zwar nur langsam durchzusetzen, aber immerhin.Holger wrote:Außerdem frage ich mich, wann HTTP/2.0 "flächendeckend verfügbar" ist.
Letzteres (CSS im <body> zu verlinken) halte ich für eine fragliche Technik, zumal das AFAIK gar nicht standardkonform ist. Zusammenfassung von Stylesheets halte ich daher für sinnvoll, wobei der Core diesbezüglich ja schon viel tut (und Entwickler und Designer dies nutzen können, wenn halt alle Stylesheets vor der Auslieferung des Templates/Plugins zusammengefasst werden; einziger Haken sind eventuelle Updates). Bezüglich JS: die würde ich eben immer am Ende des <body> (oder noch später) einbinden; dann sind mehrere Anfragen zumindest nicht mehr so problematisch. Wäre schön, wenn das auch für jQuery und -Plugins möglich wäre – vermutlich aus BC Gründen aber ein Problem.Holger wrote:Back to topic: alle Assets die im <head> der Seite stehen, blockieren das Rendering der Seite. Es würde also eine kleine Verbesserung sein, wenn die dort enthaltenen CSS und JS-Dateien jeweils zu einem einzigen Request zusammengefasst werden. Bei ein paar zusätzlich installierten Plugins könnte man da durchaus etwas sparen. Nur das Template-CSS müsste exklusiv geladen werden, weil hier @import erlaubt ist, was ja bekanntlich nur ganz am Anfang der Datei erlaubt ist. Aber alles was im <body> steht würde ich nicht anfassen. Zumal schon heute Mode ist CSS-Dateien per <link> Element auch im <body> zu laden - "Above the fold" lässt grüßen.
Da hast du nicht unrecht. Vielleicht doch lieber ganz lassen – für mich okay.Holger wrote:Da bin ich mir nicht sicher, ob das eine Lösung für die Allgemeinheit sein kann. Ich glaube nicht, dass der größte Teil der User die Bedeutung und die Auswirkungen des Features versteht und richtig verwendet.cmb wrote:Was vielleicht noch sehr interessant wäre, wäre die optionale Integration von Cache_XH (jedenfalls sinngemäß); das könnte zumindest für CMSimple_XH Sites bei denen sich nur selten was ändert interessant sein.
Christoph M. Becker – Plugins for CMSimple_XH
Re: CnC: Cache&Compress für CMSimple_XH
Ich finde, wenn vielleicht auch nicht alles perfekt ist (ich selbst habe es noch gar nicht getestet), das ist der entscheidende Punkt.Holger wrote:Mit CnC geht es aber "out of the Box"
Sicher kann man mit anderen Mitteln, oder sogar mit Kombinationen noch etwas mehr erreichen, oder besser auf ganz bestimmte Szenarien eingehen.
Aber, dann ist es eben nicht mehr so simple, wie der Name es suggeriert. Von daher für die Allgemeinheit eine prima Lösung.
Und, davon gehe ich aus, mit der Zeit wird es auch noch die eine oder andere Verbesserung geben.
Gruß Olaf, Plugins for CMSimple_XH
Ich habe schon lange den Verdacht, dass so viele so eifrig auf Gender, Trans und Queer machen:
Weil sie für das Fachliche ganz einfach zu doof sind.
Ich habe schon lange den Verdacht, dass so viele so eifrig auf Gender, Trans und Queer machen:
Weil sie für das Fachliche ganz einfach zu doof sind.
Re: CnC: Cache&Compress für CMSimple_XH
Ja, ein schlauer Hoster schaltet die Kompression schon aus Eigennutz serverseitig an . Und, wer es weiß, kann das Feature ja in CnC abschalten.cmb wrote:Die Server, die ich mir angeschaut hatte, haben das bereits "selbst" so gemacht.
BTW: da würde mich die URL zu Ludwigs Testseite ja mal brennend interessieren...
Darum ging es mir.olape wrote:Ich finde, wenn vielleicht auch nicht alles perfekt ist (ich selbst habe es noch gar nicht getestet), das ist der entscheidende Punkt.Holger wrote:Mit CnC geht es aber "out of the Box"
Das hoffe ich sehr. Gerne auch mit konkreten Lösungsvorschlägen.olape wrote:Und, davon gehe ich aus, mit der Zeit wird es auch noch die eine oder andere Verbesserung geben.