{"id":430,"date":"2010-12-10T12:35:32","date_gmt":"2010-12-10T11:35:32","guid":{"rendered":"https:\/\/d-mueller.de\/blog\/?p=430"},"modified":"2011-08-29T10:19:36","modified_gmt":"2011-08-29T08:19:36","slug":"der-einfluss-von-cookies-auf-die-performance-einer-webseite","status":"publish","type":"post","link":"https:\/\/d-mueller.de\/blog\/der-einfluss-von-cookies-auf-die-performance-einer-webseite\/","title":{"rendered":"Der Einfluss von Cookies auf die Performance einer Webseite"},"content":{"rendered":"

Cookies werden oft missachtet, wenn es um die Optimierung einer Webseite hinsichtlich Performance geht – zu unrecht! Das wunderbare YSlow<\/a> von Yahoo zum Beispiel hat einen Test eingebaut, der genau darauf abzielt. In den Performance Grunds\u00e4tzen<\/a> dazu hei\u00dft die Leitregel Use Cookie-free Domains for Components<\/i>.<\/p>\n

Das Problem<\/h2>\n

Cookies k\u00f6nnen erstmal in beliebiger Anzahl und ziemlicher Gr\u00f6\u00dfe auf Clientseite abgelegt werden. Das Setzen von Cookies geht sowohl mittels Javascript wie auch von der Serverseite aus, bspw. mit PHP. Womit der Cookie gesetzt wird, ist letztendlich egal. Der Effekt auf das Ladeverhalten der Webseite ist in jedem Fall, dass bei jedem HTTP-Request vom Client aus alle Cookies im Anfrage-Header mit \u00fcbermittelt<\/b> werden. Hei\u00dft konkret: MeineWebseite.com<\/i> verpasst euch beim ersten Besuch 5 Cookies, jeder 600 Byte gro\u00df. Jetzt besteht die Seite aus 30 Images, 5 Javascripts und 8 CSS-Files – garkein un\u00fcbliches Setup. Das Dokument selbst noch hinzugerechnet haben wir also 1+30+5+8 = 44 HTTP-Requests. (Update:<\/b> Danke f\u00fcr das Aufdecken des Rechenfehlers<\/a>)<\/p>\n

Damit w\u00fcrde diese imagin\u00e4re Seite sogar noch im „Normalbereich“ liegen, verglichen etwa mit mashable.com<\/a> mit 451 HTTP Requests (!!!<\/b>). So, zur\u00fcck auf unser Beispiel. Bei jedem HTTP-Request werden alle Cookies (5 St\u00fcck \u00e0 600 Byte ~ 3KB) vom Client an den Server \u00fcbertragen, also bei 44 HTTP-Requests macht das 44*3KB = 132KB zus\u00e4tzlichen Upload. Das ist schon ’ne Hausnummer. Wenn ich jetzt mal an Leute auf dem Land mit DSL Lite 768 und 128Kbit (16KB\/sec) Upload denke, m\u00fcssten die allein schonmal mehr als 8 Sekunden cookiebedingte Wartezeit in Kauf nehmen – unn\u00fctz! Denn wozu brauchen statische Elemente wie Bilder oder CSS-Dateien Zugriff auf die Cookies?<\/p>\n

Beispiel-Setup<\/h2>\n
\r\n<?php\r\n\tsetcookie("PHP-Cookie", "I was set by PHP", time()+3*86400);\r\n?>\r\n\r\n<!DOCTYPE html>\r\n<html>\r\n<head>\r\n\t<link rel="stylesheet" href="css\/style.css" \/>\r\n\t\t\r\n\t<script>\r\n\tfunction setCookie(cookiename,value,expiredays)\r\n\t{\r\n\t\tvar expires=new Date();\r\n\t\texpires.setDate(expires.getDate()+expiredays);\r\n\t\texpires = expires.toUTCString();\r\n\t\t\r\n\t\tdocument.cookie=cookiename+"="+escape(value)+";expires="+expires;\r\n\t}\r\n\t\r\n\tsetCookie("Javascript-Cookie","I was set by Javascript",3);\r\n\t<\/script>\r\n\t\r\n<\/head>\r\n<body>\r\n\t<img src="images\/image.png" \/>\r\n<\/body>\r\n<\/html>\r\n<\/pre>\n
Wir setzen also einen PHP-Cookie und einen Javascript-Cookie (jeweils f\u00fcr 3 Tage, aber das hat f\u00fcr dieses Beispiel keine Bedeutung). <\/p>\n
Damit haben wir folgendes Szenario:<\/p>\n
\r\nRequest: http:\/\/cookietest.de\/index.php\r\nImages:  http:\/\/cookietest.de\/images\/image.png\r\nStyles:  http:\/\/cookietest.de\/css\/style.css\r\n<\/pre>\n
Im Firebug betrachtet sieht das so aus:<\/b><\/p>\n
\"\"<\/a><\/p>\n
Der PHP und der Javascript-Cookie wird mit dem Bild (wie mit den anderen beiden Requests auch) mitgeschickt, obwohl weder das Bild, noch die CSS was damit angefangen kann.<\/p>\n
Der Cookie-Editor verr\u00e4t:<\/b><\/p>\n
\"\"<\/a>
\n\"\"<\/a><\/p>\n
Damit sind beide Cookies f\u00fcr die ganze Domain g\u00fcltig, somit also auch f\u00fcr das Bild und die CSS-Datei.<\/p>\n
L\u00f6sungsm\u00f6glichkeiten<\/h2>\n
1) Den Content in ein Subdirectory packen und die Cookies auf dieses limitieren<\/h3>\n
\r\nRequest: http:\/\/cookietest.de\/content\/index.php\r\nImages:  http:\/\/cookietest.de\/images\/image.png\r\nStyles:  http:\/\/cookietest.de\/css\/style.css\r\n<\/pre>\n
Nur die Content-Dateien (PHP-Files) haben in der Regel mit den Cookies zu tun. Wenn wir also die G\u00fcltigkeit der Cookies auf dieses Verzeichnis beschr\u00e4nken, bleiben die statischen Ressourcen davon unbehelligt. Damit ver\u00e4ndert sich der PHP-setcookie-Befehl wie folgt:<\/p>\n
\r\nsetcookie("PHP-Cookie", "I was set by PHP", time()+3*86400, "\/content\/");\r\n<\/pre>\n
F\u00fcr Javascript gilt:<\/p>\n
\r\nfunction setCookie(cookiename,value,expiredays,path)\r\n{\r\n\tvar expires=new Date();\r\n\texpires.setDate(expires.getDate()+expiredays);\r\n\texpires = expires.toUTCString();\r\n\t\r\n\tdocument.cookie=cookiename+"="+escape(value)+";expires="+expires+";path="+path;\r\n}\r\n\r\nsetCookie("Javascript-Cookie","I was set by Javascript",3,"\/content\/");\r\n<\/pre>\n
Damit werden nur noch f\u00fcr die Dateien im \/content\/* – Unterverzeichnis Cookies \u00fcbertragen und nicht mehr f\u00fcr Bilder und CSS-Dateien. Nur ist es oft (unter anderem aus SEO-Gr\u00fcnden) nicht sinnvoll, den ganzen Inhalt in einen Unterordner zu verfrachten.<\/b><\/p>\n
2) Eine Subdomain f\u00fcr alle statischen Inhalte anlegen<\/h3>\n
\r\nRequest: http:\/\/cookietest.de\/index.php\r\nImages:  http:\/\/static.cookietest.de\/images\/image.png\r\nStyles:  http:\/\/static.cookietest.de\/css\/style.css\r\n<\/pre>\n
Wenn wir jetzt den Code also so umbauen, dass alle statischen Ressourcen von dieser Subdomain geladen werden, k\u00f6nnten wir es wie folgt aufbauen:<\/p>\n
\r\n<?php\r\nsetcookie("PHP-Cookie", "I was set by PHP", time()+3*86400, "\/", "cookietest.de");\r\n?>\r\n\r\n<!DOCTYPE html>\r\n<html>\r\n<head>\r\n\t<link rel="stylesheet" href="http:\/\/static.cookietest.de\/css\/style.css" \/>\r\n\t\t\r\n\t<script>\r\n\tfunction setCookie(cookiename,value,expiredays,path, domain)\r\n\t{\r\n\t\tvar expires=new Date();\r\n\t\texpires.setDate(expires.getDate()+expiredays);\r\n\t\texpires = expires.toUTCString();\r\n\t\t\r\n\t\tdocument.cookie=cookiename+"="+escape(value)+";expires="+expires+";path="+path+";domain="+domain;\r\n\t}\r\n\r\n\tsetCookie("Javascript-Cookie","I was set by Javascript",3,"\/", "cookietest.de");\r\n\t<\/script>\r\n\t\r\n<\/head>\r\n<body>\r\n\t<img src="http:\/\/static.cookietest.de\/images\/image.png" \/>\r\n<\/body>\r\n<\/html>\r\n<\/pre>\n
Wenn wir uns jetzt aber den Firebug betrachten, sehen wir allerdings auch wieder bei den statischen Elementen<\/p>\n
\r\nCookie\tPHP-Cookie=I+was+set+by+PHP; Javascript-Cookie=I%20was%20set%20by%20Javascript\r\n<\/pre>\n
Wie kommt das?
\n\"\"<\/a>
\n\"\"<\/a><\/p>\n
Der aufmerksame Beobachter sieht sofort: Als Domain ist <\/p>\n
.cookietest.de<\/pre>\n
 eingetragen, was bedeutet, dass die Subdomains ebenfalls davon betroffen sind – Also hilft uns diese L\u00f6sung in der Form noch nicht weiter<\/b>, weil die statischen Dateien trotz Subdomain die Cookies angehangen bekommen.<\/p>\n
Die L\u00f6sung hei\u00dft www.<\/h3>\n
Wenn wir also nur noch www.<\/i>-Aufrufe f\u00fcr die Webseite zulassen, k\u00f6nnen wir die Cookies auch auf www.cookietest.de<\/i> beschr\u00e4nken. Damit bleibt die Subdomain unbehelligt.<\/p>\n
Damit:<\/b><\/p>\n
\r\nRequest: http:\/\/www.cookietest.de\/index.php\r\nImages:  http:\/\/static.cookietest.de\/images\/image.png\r\nStyles:  http:\/\/static.cookietest.de\/css\/style.css\r\n<\/pre>\n
PHP:<\/p>\n
\r\nsetcookie("PHP-Cookie", "I was set by PHP", time()+3*86400, "\/", "www.cookietest.de");\r\n<\/pre>\n
Javascript:<\/p>\n
\r\nsetCookie("Javascript-Cookie","I was set by Javascript",3,"\/", "www.cookietest.de");\r\n<\/pre>\n
Wenn wir nun noch in der .htacess mittels<\/p>\n
\r\n#force www.\r\nRewriteCond %{HTTP_HOST} ^cookietest.de$ [NC]\r\nRewriteRule ^(.*) http:\/\/www.cookietest.de\/$1 [L,R=301]\r\n<\/pre>\n
erzwingen, dass die Seite blo\u00df mit www. aufgerufen kann, haben wir gewonnen<\/b>.<\/p>\n
3) Komplett andere Domain f\u00fcr statische Inhalte verwenden<\/h3>\n
Wir k\u00f6nnen es uns noch einfacher machen, wenn wir eine komplett andere Domain f\u00fcr statische Inhalte verwenden, etwa cookietest-static.de<\/i>. Damit brauchen wir uns um nichts mehr zu k\u00fcmmern, brauchen keine Cookies einschr\u00e4nken oder mit Subdomains herumexperimentieren. Ist halt eine Kostenfrage.<\/p>\n
Aber Vorsicht!<\/h2>\n
Im hier gezeigen Beispiel mit 3 HTTP-Requests w\u00e4re der getriebene Aufwand Overkill, da es kaum merkliche Unterschiede in der Seitengeschwindigkeit geben w\u00fcrde. Auch zu beachten ist, dass durch das Auslagern statischer Inhalte auf eine andere Domain ein zus\u00e4tzlicher DNS-Lookup<\/i> n\u00f6tig wird, um cookietest-static.de<\/i> zu einer IP aufzul\u00f6sen. Ma\u00dfgabe ist also, genau abzuw\u00e4gen wann es sich lohnt, den obigen Aufwand zu treiben.<\/p>\n
Zukunftsaussicht<\/h2>\n
Es wird gerade eifrig diskutiert, ob in Browsern der Zusatz rel=“anonymous“<\/i> bei statischen Elementen eingef\u00fchrt werden sollte. Diese sollen dann keine Cookie-Daten mitgeschickt bekommen. W\u00e4re an sich eine super Sache, nur sind dann trotzdem noch genug Leute mit alten Browsern unterwegs und f\u00fcr per CSS geladene Bilder w\u00fcrde das wohl auch nicht greifen – Mal sehen, wohin die Reise geht.<\/p>\n
Bonus: Google Analytics auf eine Domain beschr\u00e4nken<\/h2>\n
Google Analytics setzt selbst auch einen Cookie mit einer ID, die dann zum Tracking des Benutzers verwendet wird. Mit den Anweisungen _setDomainName<\/i> und _setCookiePath<\/i> l\u00e4sst sich dieser aber auch auf die relevanten Content-Seiten beschr\u00e4nken, um eben zu verhindern, dass auch bei statischen Ressourcen immer der Cookie mit \u00fcbertragen wird. Bei mir sieht das jetzt so aus:<\/p>\n
\r\nvar _gaq = _gaq || [];\r\n_gaq.push(['_setAccount','UA-2935194-4']);\r\n_gaq.push(['_setDomainName', 'www.d-mueller.de']); \r\n_gaq.push(['_setCookiePath', '\/blog\/']);\r\n_gaq.push(['_trackPageview']);\r\n(function() {\r\n\tvar ga = document.createElement('script'); ga.type = 'text\/javascript'; ga.async = true;\r\n\tga.src = ('https:' == document.location.protocol ? 'https:\/\/ssl' : 'http:\/\/www') + '.google-analytics.com\/ga.js';\r\n\tvar s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);\r\n})();\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Cookies werden oft missachtet, wenn es um die Optimierung einer Webseite hinsichtlich Performance geht – zu unrecht! Das wunderbare YSlow von Yahoo zum Beispiel hat einen Test eingebaut, der genau darauf abzielt. In den Performance Grunds\u00e4tzen dazu hei\u00dft die Leitregel … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,12,10,3],"tags":[],"class_list":["post-430","post","type-post","status-publish","format-standard","hentry","category-php","category-javascript","category-performance","category-webdev"],"_links":{"self":[{"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/posts\/430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/comments?post=430"}],"version-history":[{"count":0,"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/posts\/430\/revisions"}],"wp:attachment":[{"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/media?parent=430"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/categories?post=430"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/d-mueller.de\/blog\/wp-json\/wp\/v2\/tags?post=430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}