Re: CnC: Cache&Compress für CMSimple_XH
Posted: Wed Nov 01, 2017 3:53 pm
Und woran sehe ich das bzw. wo kann ich das überprüfen?
Welcome to the CMSimple_XH–Community!
https://cmsimpleforum.com/
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 ???
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 .
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.
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.
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.
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 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>
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.
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"
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.
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.