Static content - cookieless

rage_all · 05. März 2018 10:49

Hallo zusammen,

gerade teste ich mein jüngstes Projekt und werde natürlich ehrgeiziger was den PageSpeed angeht.
Die komplette Seite habe ich eingedampft auf 13 requests, inkl. überflüssigem Erst-Content wie Cookie Consent, etc. und bin bei sagenhaften 702 ms @ 634.1 kB trotz Full-HD-Hintergrundfotos, Fonts, JavaScripts, vollem Framework, etc. Goil! big_smile

Aber: Jetzt mault das Ding wegen unnötigem Traffic, weil statische Teile mit Cookies geladen werden (müssen). Klar, für eine Grafik oder eine CSS brauche ich nicht wirklich erst ein Cookie vom Client auslesen.

Lösungsansatz 1:
Funktioniert, ist aber nicht präferiert:
Statische Inhalte auf eine andere Domain umlagern und in der .htaccess die Cookies abschalten.
In meinem Fall also http://cookieless.meineeigeneagenturwebsite.de/ (statt http://cookieless.meinekundenwebseite.de/).
Funktionieren würde natürlich auch eine Subdomain des Kunden ... warum also auf meiner statt gleich beim Kunden? Irgendwann muss SSL her. Das machen wir nicht unnötig mit Wildcard sondern nur auf der www.-Subdomain.
Da würde ich mir leichter eine high-performance SSL-Cookieless-Subdomain bei mir einrichten für alle Projekte und so günstiger fahren.

Lösungsansatz 2?
Nun bin ich zufällig über ein Setting im (mir äußerst verhassten) WordPress gestolpert, wo man in der config eine Cookie-Domain einsetzen kann.
Über die normale .htaccess und Apache ist es - nach einiger Recherche - wohl nicht möglich, Cookies nur für den root zu platzieren, bzw. bestimmte Unterordner wie /assets oder /uploads auszunehmen. Nach etwas weiterer Suche habe ich einen Forenbeitrag hier gefunden, aus dem ich aber nicht schlau werde:
http://forum.cmsmadesimple.de/viewtopic.php?id=2463

Wie stellt man in der include.php die Cookie-Domain ein? Oder hab ich was falsch verstanden?
Wie löst Ihr solche marginalien beim PageSpeed? CSS & Co. haben wir doch alle...

Vielen Dank!

NaN · 05. März 2018 13:36

Wie stellt man in der include.php die Cookie-Domain ein?

Garnicht. In dem Beitrag geht es darum, die Cookies im Frontend generell komplett abzustellen. Da geht es nicht um eine konkrete Domain

Bei Deinem WordPress-Beispiel geht es darum, dass WordPress je nachdem unter welcher Domain es aufgerufen wird, selber entscheidet, ob es im Frontend ein Cookie setzt oder nicht - das ist das, was in CMSms fehlt. Da wird immer ein Cookie gesetzt. D.h. das System muss dazu über die index.php ausgeführt werden.

Wenn Du aber über eine Subdomain direkt zu Bildern, CSS und JavaScripts verlinkst, wird das System ja nicht ausgeführt. D.h. man agiert am System und etwaigen Config-Einstellungen/Hacks etc. vorbei. Daher wird da auch kein Cookie gesetzt.

Also wenn Du den Weg über eine Subdomain gehst, sollte Dein Problem damit gelöst sein.
Wenn Du aber im Frontend generell keine Cookies benötigst, dann stell das in der include.php ab. Da ich leider nicht weiß, von welcher CMSms-Version wir reden, kann ich Dir da auch leider nicht sagen, wo Du evtl. was ändern musst.

rage_all · 05. März 2018 15:00

Hey, vielen Dank!

Mit Cookies hab ich im Grunde kein Problem. Im Gegenteil: Ich setze eine 'Cookie-Hinweis'-Geschichte um, aus meinem persönlichen Verständnis der DSGVO in Zusammenhang mit Tracking und eben der Aufklärung dass Daten gesammelt werden und dass man ... eh, ganz, ganz anderes Thema.

Das CMSms-Cookie ist außerdem ein technisches — ohne konkret zu wissen, welchen Zweck es tatsächlich erfüllt, habe ich wegen dem keinerlei Bedenken.

Mir geht es nur ausschließlich darum statische Inhalte ohne Cookies ausliefern zu können.
Auf Anhieb hatte ich die Idee mit der Subdomain, beim herumstöbern fand ich aber eine Seite einer größeren Agentur die eigentlich elend langsam ist (~ 3 Sek.) und trotzdem Spitzenwerte bekommt. Mit auf der positiv-Liste ist eben dass die static Content ohne Cookies liefern.
Nur, dieser Content liegt auch bei denen unter /root/wp-assets

Ich hab daher schnell gecheckt, dass die WP einsetzen und hab dann eben diese mysteriöse Einstellung ergoogelt (https://xparkmedia.com/blog/set-cookieless-domain/), so kam das alles zustande.
Vorher hab ich geschaut ob ich in der htaccess was einstellen kann, kam aber über zwanzig Beiträge auf stackoverflow & Co. darauf, dass beim Aufruf von "/" gewöhnlich ein Cookie gesetzt wird und der Client diesen bei jedem Aufruf sowieso an den Server schickt. Eben das verlangsamt das Prozedere.

Dieses für "/" gesetzte Cookie
a) gilt also für die gesamte Domain, ohne Subdomains, aber inkl. Unterordnern der TLD
b) wird vom Client vor Abruf der weiteren Daten in den Unterordnern ohne Rückfrage an den Server gesandt - ein verbieten im Unterordner mittels zweiter htaccess würde also gar nichts bringen, da der Traffic bereits vom Client her entstand.

Wenn ich also den Cookie-Hinweis weiter einsetzen wollte und dafür ein Cookie brauche um zu checken ob der User den "Bedingungen" zugestimmt hat oder ich weiterhin nerven muss, würde es keine Rolle spielen ob CMS selbst welche platziert oder nicht. Der Client wird dann doch eh das Cookie bei jedem Aufruf senden, nicht?

Ergebnisorientiert gesagt:
Ich würde nur, soweit möglich, vermeiden wollen
a) unnötigen Traffic auf meiner Domain zu verursachen, durch Kundentraffic (sieht auch vom Datenschutz her dämlich aus)
b) unnötig Wildcard-SSL-Zertifikate anzuschaffen nur um durch cookieless assets via cookieless subdomains den PageSpeed zu bekommen den ich gern hätte

Darum hab ich gehofft, es gäbe analog eine passende Einstellung im CMSms.
Ob ich das mit WordPress aus dieser Website oben richtig verstanden hatte, ist mir auch nicht ganz klar ... ich hatte einfach mal gehofft... big_smile

NaN · 05. März 2018 15:48

Also Du kannst nur versuchen, das vom CMS automatisch gesetzte Session-Cookie zu unterbinden.

Hab mich mal gemäß den Vorschlägen im verlinkten Beitrag an CMSms 2.0 versucht. Folgende Schritte, um Cookies im Frontend komplett abzuschalten...

in der Datei /lib/misc.functions.php in Zeile 1276:

Hier klicken, um den Code zum Kopieren zu markieren

if(!@session_id()) session_start();

ändern in:

Hier klicken, um den Code zum Kopieren zu markieren

    $config = cmsms()->GetConfig();
    if(!session_id() && (isset($CMS_ADMIN_PAGE) || isset($CMS_INSTALL_PAGE) || $config['frontend_session']))
	session_start();

Damit wird nur im Backend oder beim Update ein Session-Cookie gesetzt (letzteres hab ich noch nicht getestet, ob das tatsächlich funktioniert). Hat allerdings noch einen kleinen Nachteil: einmal im Backend gewesen, schleppt man das Cookie auch im Frontend für immer mit sich herum. Sollte aber den normalen Webseitenbesucher - und auch Google - nicht interessieren.

Wenn man Sessions auch im Frontend benötigt, dann in der config.php einfach diesen Wert hinzufügen:

Hier klicken, um den Code zum Kopieren zu markieren

$config['frontend_session'] = true;

D.h. also in Deinem Fall, es würde von CMSms im Frontend überhaupt kein Cookie gesetzt werden. Demzufolge bräuchtest Du auch diese CCS nicht (Cookie Consent Scheiße).

Wenn Du aber sonst noch Techniken einsetzt, die Cookies verwenden - Module, Plugins, Smarty, Drittanbieter, Tracking, Analyse etc. - dann ist die Frage wie diese Cookies gesetzt werden und inwiefern man darauf Einfluss nehmen kann.

Anderenfalls wird Dir nichts anderes übrig bleiben, als einer Deiner beiden Lösungen oder eben auf diesen PageSpeed-Punkt zu verzichten.

Diese .htaccess-Geschichte endet bei mir z.Z. in einem 500er. Muss ich erstmal testen, was ich da alles einstellen muss, damit ich das testen kann ... roll

PS: bisher habe ich einfach eine subdomain beim kunden eingerichtet und über diese dann statische inhalte ausgeliefert, aber seitdem HTTPS quasi Pflicht ist, wird's mir langsam auch etwas zu umständlich.

Wie sieht's eigentlich mit CDN aus? Wäre das eine Lösung?

Andynium · 02. April 2018 10:19

NaN schrieb:

in der Datei /lib/misc.functions.php in Zeile 1276:
Hier klicken, um den Code zum Kopieren zu markieren
if(!@session_id()) session_start();
ändern in:
Hier klicken, um den Code zum Kopieren zu markieren
    $config = cmsms()->GetConfig();
    if(!session_id() && (isset($CMS_ADMIN_PAGE) || isset($CMS_INSTALL_PAGE) || $config['frontend_session']))
	session_start();
Damit wird nur im Backend oder beim Update ein Session-Cookie gesetzt (letzteres hab ich noch nicht getestet, ob das tatsächlich funktioniert). Hat allerdings noch einen kleinen Nachteil: einmal im Backend gewesen, schleppt man das Cookie auch im Frontend für immer mit sich herum. Sollte aber den normalen Webseitenbesucher - und auch Google - nicht interessieren.
Wenn man Sessions auch im Frontend benötigt, dann in der config.php einfach diesen Wert hinzufügen:
Hier klicken, um den Code zum Kopieren zu markieren
$config['frontend_session'] = true;

Danke für's Snippet - kann ich für Manta gut gebrauchen wink .

Forum für CMS/made simple

#1 05. März 2018 10:49

Static content - cookieless

#2 05. März 2018 13:36

Re: Static content - cookieless

#3 05. März 2018 15:00

Re: Static content - cookieless

#4 05. März 2018 15:48

Re: Static content - cookieless

#5 02. April 2018 10:19

Re: Static content - cookieless

Fußzeile des Forums