CnC: Cache&Compress für CMSimple_XH

Ein CMSimple Support Forum für deutsch sprechende Nutzer und Entwickler
cmb
Posts: 12047
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby cmb » Wed Nov 01, 2017 10:54 pm

Holger wrote:Na ja, standardkonform ist das nicht. Aber nicht ohne Grund pushen Google / Chrome solch eine Technik - Stichwort: "Above the fold" (aber - wie groß ist "the fold" :?: ).

Vor allem, wenn relevantes CSS noch gar nicht geladen wurde!

Holger wrote:Ein lesenswerter Artikel zu dem Thema findet man hier: https://jakearchibald.com/2016/link-in-body/

Danke! Hier scheint aber das wesentliche, dass man Stylesheets per JS lädt, und nicht, dass man sie im <body> verlinkt. Und loadCSS sieht sich selbst wohl nur als Polyfill für <link rel="preload">.

Holger wrote:Alles JS einfach nach ganz unten zu verschieben, scheint mir aber auch keine Lösung zu sein. Zu später Eingriff des JS während des Renderings kann leicht zum springen der Darstellung führen. Das schaut meistens sehr bescheiden aus.

Hm, https://github.com/cmb69/themeswitcher_xh/issues/16 könnte so ein Fall sein. Aber ich denke, da gibt es keine Pauschallösung; vermutlich wird man diesbezüglich das JS aufteilen müssen.

Holger wrote:Aber zu jQuery: man könnte optional und ohne BC-Break zumindest alles nach $bjs, anstatt nach $hjs schreiben. Ich fürchte aber, dass es in vielen Fällen zu unschönen Effekten während des Seitenaufbaus kommen wird.

Na ja, das geht spätestens in die Hose, wenn ein Plugin das zu ladende JS bereits mitten im <body> referenziert (habe ich früher gelegentlich so gemacht). Und auch wenn ein jQuery-Plugin nicht per jQuery_includePlugin() sondern direkt im <head> eingebunden wird (habe ich bei Plugins schon gesehen), gibt es Probleme.

Holger wrote:Interessant ist, dass das vom Server automatisch implementierte Caching, also ohne CnC, wegen fehlendem Ablaufdatum als ungültig angesehen wird, und dass das nicht minifizierte xhstyles.css zur Abwertung führt. Also bringt im konkreten Fall das Plugin auch hier zumindest eine kleine Verbesserung :) .

Soweit ich es überblicke, dürfte das derzeitige CnC client-seitig die Situation nie verschlechtern, und nicht selten zumindest ein bisschen verbessern (manchmal sogar drastisch). Das ist auf jeden Fall gut. Zu prüfen wäre vielleicht, wie viel Mehraufwand es dem Server verursacht, und ob da noch nachgebessert werden könnte. Diesbezüglich könnten vielleicht neuere Versionen von minify hilfreich sein.
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+

cmb
Posts: 12047
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby cmb » Wed Nov 01, 2017 11:08 pm

Holger wrote:Dann werden auch Bilder aus dem Template-Ordner etc. berücksichtigt. Die wurden von PageSpeed Insights, trotz vom Server implementiertem Caching, angemäkelt.

Google Pagespeed meckert bisweilen aber auch über nicht ausreichend "optimierte" Bilder – ist natürlich immer so eine Sache. Interessant ist in diesem Zusammenhang wohl der Guetzli Encoder. Sehr interessant finde ich folgende Aussage:
Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.
(da weiß man doch gar nicht mehr, wie man es machen soll …)

Holger wrote:Außerdem nutzt das neue Standard-Template auch Fonts aus dem Template-Ordner, anstatt sie von einem CDN zu beziehen.

Na ja, CDN ist immer so eine Sache. Funktioniert gar nicht bei Offline-Ausführung, und kann anscheinend auch immer mal Probleme verursachen, siehe https://github.com/cmsimple-xh/cmsimple-xh/issues/206. (Ein nicht ganz unähnliches Problem trat übrigens kürzlich bei Google Docs auf.)
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+

Holger
Site Admin
Posts: 2715
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby Holger » Wed Nov 01, 2017 11:19 pm

mhz wrote:habe ich gemacht. dann kommt:
Forbidden. You don't have permission to access / on this server.

Also wieder gelöscht
Komisch, bei mir klappt das, wie man ja unter oben geposteten Link sehen kann. Aber da bin ich wirklich kein Experte :( .

cmb wrote:
Holger wrote: Ein lesenswerter Artikel zu dem Thema findet man hier: https://jakearchibald.com/2016/link-in-body/

Danke! Hier scheint aber das wesentliche, dass man Stylesheets per JS lädt, und nicht, dass man sie im <body> verlinkt. Und loadCSS sieht sich selbst wohl nur als Polyfill für <link rel="preload">.
Hmm, da hast Du wohl nicht bis zum Ende gelesen. Hier der direkte Link zum Fazit: https://jakearchibald.com/2016/link-in- ... better-way und auch noch ein kleines Video, wie das Rendering dann abläuft: https://twitter.com/jaffathecake/status ... 1429392385

cmb wrote:Soweit ich es überblicke, dürfte das derzeitige CnC client-seitig die Situation nie verschlechtern, und nicht selten zumindest ein bisschen verbessern (manchmal sogar drastisch). Das ist auf jeden Fall gut. Zu prüfen wäre vielleicht, wie viel Mehraufwand es dem Server verursacht, und ob da noch nachgebessert werden könnte. Diesbezüglich könnten vielleicht neuere Versionen von minify hilfreich sein.
Minify3 habe ich hier schon getestet. Es macht mir noch Probleme bei der Konfiguration / dem Zusammenbau der URLs. Das werde ich aber kurzfristig nochmal genauer ansehen. Es wird damit auch viel einfacher mehrere Assets zu einem Request zu verbinden. Allerdings würde ich das neue Static file serving noch nicht verwenden wollen, da die Dateien bei Änderungen (noch) nicht gelöscht werden. Der kleine Overhead der nötig ist, um die Assets per PHP zu senden, wird meiner Meinung nach nicht so sehr ins Gewicht fallen. Aber wir können ja mal mit und ohne CnC nachmessen ;) .

cmb wrote:Na ja, CDN ist immer so eine Sache.
Ich wollte das nicht kritisieren. Auch ich verwende lieber keine CDNs. Aber Caching der serverseitig gespeicherten Fonts hatte noch gefehlt.
Ich wäre froh, wenn es für Bilder, Fonts etc. auch noch eine einfache Lösung abseits von .htaccess geben würde. Wie oben bei Michel passiert, gibt es damit ja immer wieder Probleme. Vielleicht müsste CnC eine .htaccess irgendwie liefern / generieren :? .

cmb
Posts: 12047
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby cmb » Thu Nov 02, 2017 12:31 am

Holger wrote:Hmm, da hast Du wohl nicht bis zum Ende gelesen. Hier der direkte Link zum Fazit: […]

Nein, ich hatte tatsächlich nicht bis zum Ende gelesen. Aber wenn ich dann lese:
The HTML spec doesn't cover how page rendering should be blocked by CSS, and it discourages <link rel="stylesheet"> in the body, but all browsers allow it.

Soll ich mir denken, dass der Autor hier einfach nur ein "fast"/"praktisch" (alle Browser) vergessen hat, oder dass er nicht weiß, worüber er schreibt? Und wenn ich dann den Abschnitt "Firefixing" lese, wird mir klar, dass der Artikel auf den Mainstream abzielt, und den Rest ignoriert. Okay, 98% sind schon was – aber ich sollte mein aktuelles CTM noch mal gründlich überdenken … Auf jeden Fall halte ich es für gefährlich, ein nicht standardisiertes Browserverhalten vorauszusetzen – das kann sich jederzeit ändern, und dann muss man nachbessern.

Holger wrote:Ich wäre froh, wenn es für Bilder, Fonts etc. auch noch eine einfache Lösung abseits von .htaccess geben würde.

Zumindest prinzipiell könnten diese ja ebenfalls per PHP ausgeliefert werden.
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+

olape
Posts: 330
Joined: Fri Mar 13, 2015 8:47 am
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby olape » Thu Nov 02, 2017 11:43 am

mhz wrote:habe ich gemacht. dann kommt:
Forbidden. You don't have permission to access / on this server.

Also wieder gelöscht

Das ist sehr unwahrscheinlich, wenn wirklich nur drin stand, was Holger gepostet hat.
Ich vermute mal, da stand noch mehr drin. Oder?

Holger
Site Admin
Posts: 2715
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby Holger » Thu Nov 02, 2017 1:57 pm

cmb wrote:Soll ich mir denken [...]
Na ja, eigentlich ist das hier ja komplett off-topic. Es ging mir doch lediglich darum, was man an CnC mittelfristig besser machen könnte. Einer meiner Punkte war, dass man die CSS und JS Assets im <head> noch mittels CnC zu weniger Requests zusammenfasst. Denn so, wie es jetzt ist, wird das Rendering eh geblockt bis alle dort enthaltenen Ressourcen abgearbeitet sind.
Lediglich für den Bereich nach </head> wollte ich keine Manipulationen machen. Der Grund dafür sind solche Experimente wie Styles im <body> laden (wie auch immer). So etwas kann ein Plugin oder ein Template selber erledigen. Mehr wollte ich mit dem Link auch nicht bezwecken.

Aber, interessant ist die "Technik" schon. Standard hin oder her; das, was die Browserhersteller tun, ist eine andere Geschichte. Und ja, auch ein Style-Element im Body war kurzfristig sogar mal im Entwurf der HTML 5 Spezifikation. Es flog aber wieder heraus, genau wie Spec. Und <link rel="stylesheeet"> und <style> im Body wird von den Browsern toleriert - wie so viele nicht standardkonforme Dinge in manchen großen Seiten oder einfach nur unabsichtliche Fehler. Google selbst, als Mitgestalter der HTML 5 Spezifikation, schert sich oft genug selbst nicht um Konformität.
In dem Zusammenhang ist es auch zumindest lustig, dass die Demo-Seite im w3c-HTML-Validator keine Fehler produziert - wohlgemerkt mit <link rel="stylesheet"> innerhalb des Bodys :shock: . Aber auch deswegen wird es nicht standardkonform, klar. Also, streiten wir nicht weiter darüber. Für die Zukunft bin ich aber hoffnungsvoll, dass so etwas mal standardkonform wird.
Vielleicht machen sich Plugin- und Templateentwickler ja noch noch ein paar Gedanken zu dem Problem. Eigentlich ist es ja auch Verschwendung, wenn die kompletten Styles aller Plugins immer geladen werden, obwohl sie nicht gebraucht werden. Ein einfacher (und standardkonformer) Weg wäre ja, das CSS per JS genau dann in den <head> zu schreiben, wenn es wirklich gebraucht wird. Als Fallback wäre dann nur noch ein <noscript> mit dem Link zum CSS im Head nötig. Dafür gibt es ja auch Tools, die so etwas halbwegs gut automatisch erledigen.
Aber wenn ich mit CnC anfange dort herum zu manipulieren, wird das im Chaos enden und nebenbei den Weg für Skripte, die der Autor so optimiert hat, verbauen.

cmb wrote:Zumindest prinzipiell könnten diese ja ebenfalls per PHP ausgeliefert werden.
Schon, aber wäre das nicht overkill?
Ich stelle mir eher vor, dass das Plugin eine .htaccess generieren kann und auch prüft, ob es die Datei schon gibt und welchen Inhalt sie hat...
Aber vermutlich genügt es auch, wenn man ein Muster liefert und genau erklärt, was der User damit machen kann / soll.

cmb
Posts: 12047
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby cmb » Thu Nov 02, 2017 2:48 pm

Holger wrote:Als Fallback wäre dann nur noch ein <noscript> mit dem Link zum CSS im Head nötig.

<noscript> ist zumindest heutzutage nicht unbedingt geeignet. Ich hatte, glaube ich, schon zweimal einen interessanten Artikel im Forum verlinkt, wo mal untersucht wurde, wie es mit der JS Unterstützung so aussieht (kann den Link bei Bedarf raussuchen). Jedenfalls war das Ergebnis, dass nur sehr wenige Clients gar kein JS unterstützten, aber etwa zehnmal so viele zwar JS prinzipiell unterstützten, es aber, aus welchen Gründen auch immer, nicht ausgeführt wurde. Da bringt dann <noscript> eben nichts. In diesem Fall fände ich es aber okay, und ich fände es ginge gar auch ohne <noscript> – CSS ist halt progressive Enhancement.

Holger wrote:Aber wenn ich mit CnC anfange dort herum zu manipulieren, wird das im Chaos enden und nebenbei den Weg für Skripte, die der Autor so optimiert hat, verbauen.

Ja, sehe ich auch so.

Holger wrote:Ich stelle mir eher vor, dass das Plugin eine .htaccess generieren kann und auch prüft, ob es die Datei schon gibt und welchen Inhalt sie hat...
Aber vermutlich genügt es auch, wenn man ein Muster liefert und genau erklärt, was der User damit machen kann / soll.

Ich denke, dass letzteres am meisten Sinn macht. Schließlich gibt es viele CMSimple(_XH) User, die gar keine (volle) Unterstützung für .htaccess haben. Würde ein Plugin eine solche generieren, käme man dennoch nicht umhin zu dokumentieren, dass dies eventuell gar nicht unterstützt wird. Außerdem finde ich, dass es besser ist, für .htaccess keine Schreibrechte zu setzen.
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+

cmss
Posts: 82
Joined: Mon Jan 02, 2017 6:15 pm

Re: CnC: Cache&Compress für CMSimple_XH

Postby cmss » Sat Nov 04, 2017 8:43 pm

Worin besteht der prinzipielle Unterschied zu einem mit cache-dev.zip und ob_start("ob_gzhandler") und mod_deflate getuntem XH_CMS.

mhz
Posts: 528
Joined: Tue Jun 25, 2013 8:46 pm
Location: Heusenstamm, Hessen
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby mhz » Sun Nov 05, 2017 7:02 am

Schaut auch mal hier zu den beschriebenen Problemen ...
Michael Zajusch (mhz)-- Mein Tutorial für CMSimple_XH. Früher

cmb
Posts: 12047
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: CnC: Cache&Compress für CMSimple_XH

Postby cmb » Sun Nov 05, 2017 11:34 am

cmss wrote:Worin besteht der prinzipielle Unterschied zu einem mit cache-dev.zip und ob_start("ob_gzhandler") und mod_deflate getuntem XH_CMS.

Cache_XH forciert ein längerfristiges clientseitiges Cachen der eigenlichen HTML-Dokumente, so dass ein Client u.U. eine geänderte Version des Dokuments gar nicht zu sehen bekommt. Bei CnC erhalten die Dokumente ein ETag, so dass der Client bei Bedarf eine aktuellere Version des Dokument herunter lädt.

Bezüglich JS- und CSS-Assets wirkt CnC im Prinzip wie zlib.output_compression=1, aber zusätzlich werden diese Assets zuvor minifiziert (falls diese unminifiziert vorliegen), und der Zeitstempel der Asset-Datei wird in die URL aufgenommen, und bei Bedarf aktualisiert.
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+


Return to “Deutsch”

Who is online

Users browsing this forum: No registered users and 3 guests