Die Performance einer Website ist ein extrem wichtiges Merkmal. Je langsamer der Seitenaufbau, desto eher verliert der Besucher die Geduld und verlässt die Seite wieder. Das ist auch einer der Beweggründe, warum Google seit geraumer Zeit auch den Pagespeed in die Bewertung einer Seite miteinfließen lässt. Eine Maßnahme, mit der sich die Geschwindigkeit erheblich steigern lässt, ist das Parallelisieren von Downloads.
Wozu parallele Downloads?
Da eine Webseite nicht als ein ganzes Stück ausgeliefert wird, sondern der Browser jede Ressource einzeln nachfragen muss (HTML-Seite selbst, jedes einzelne Bild, jedes JavaScript-File, jedes CSS-File, etc), ergeben sich mit jedem Seitenaufruf, den man tätigt, gleich mehrere Verbindungen zum Webserver. Da aber ein Browser nur eine begrenzte Anzahl von gleichzeitigen Verbindungen zu einer einzigen Domain aufnehmen kann, erfolgt der Download der einzelnen Ressourcen großteils nacheinander und nicht gleichzeitig. Ältere Browser laden zwei Ressourcen gleichzeitig, moderne Browser bis zu sechs.
Werden die Ressourcen jedoch nicht alle über die gleiche Domain ausgeliefert, sondern auf mehrere Domains verteilt, dann erfolgen diese Downloads gleichzeitig. Das müssen zum Glück auch keine eigenständigen Domains sein, es reichen auch Subdomains.
Parallele Downloads in Drupal einrichten
Das Parellel Modul für Drupal ermöglicht die Angabe 3 zusätzlicher Domains - je eine für CSS, Javascript und Bilder - mit der die Ressourcen ausgeliefert werden. Diese 3 Subdomains müssen zuerst in der Domainverwaltung konfiguriert werden. In unserem Fall sind dies: cdn1.agoradesign.at, cdn2.agoradesign.at und cdn3.agoradesign.at. Die Subdomains müssen dabei alle auf das Rootverzeichnis von Drupal zeigen!
In der Drupal Administration müssen im Menü Konfiguration > Leistung (admin/settings/performance) nur noch die Subdomains eingetragen wserden und Parallel aktiviert werden. Achten Sie darauf, dass Sie - wie bei den Beispielen angegeben - den Subdomains ein "//" voranstellen, also zB '//cdn1.agoradesign.at'. Die Konfiguration ist damit im Prinzip fertig. Jedoch kann man noch ein paar Feinschliffe vornehmen:
.htaccess Einstellungen
Im Contao-Blog wird beschrieben, wie mam per .htaccess sicherstellt, dass keine PHP und HTML Dateien über unsere neu erstellten Subdomains ausgeliefert werden, und dass im Fehlerfall, dass die Datei nicht gefunden wurde, kein Redirect auf die Startseite gemacht wird:
## # Explicitly send a 404 header if a file on cdn[0-9].agoradesign.at is not # found. This will prevent the start page (empty URL) from being loaded. ## RewriteCond %{HTTP_HOST} ^cdn[[0-9]\.agoradesign\.at [NC] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule .* - [R=404,L] ## # Do not dispatch dynamic resources via cdn[0-9].agoradesign.at. ## RewriteCond %{HTTP_HOST} ^cdn[0-9]\.agoradesign\.at [NC] RewriteCond %{REQUEST_FILENAME} \.(php|html)$ RewriteRule .* - [R=404,L]
UPDATE: Im Zusammenhang mit dem Imagecache Modul kann es jedoch zu Problemen kommen, wenn man den 404 Fehler explizit sendet, weil das Bild so beim ersten Aufruf nicht erzeugt wurde. Besser ist es daher, statt den 404-Status zu senden, auf die www-Domain umzuleiten. Das ist auch aus anderen Überlegungen heraus durchaus sinnvoll. Daher kann man beide RewriteRules durch diese hier ersetzen
RewriteRule ^(.*)$ http://www.agoradesign.at/$1 [L]
Firefox und die "Same Origin Policy" bei @font-face austricksen
Falls Schriftarten über @font-face ausgeliefert werden, kann es passieren, dass Firefox diese nicht mehr lädt, nachdem auf die Paralleliserung umgestellt wurde. Dann muss man den HTTP-Header per .htaccess anpassen:
<FilesMatch "\.(ttf|otf|eot|woff)$"> <IfModule mod_headers.c> Header set Access-Control-Allow-Origin "*" </IfModule> </FilesMatch>
Mehr dazu können Sie in unserem Blogeintrag Cross-domain Verwendung von @font-face im Firefox ermöglichen nachlesen!
Serve static content from a cookieless domain
Ein weiterer Trick, der die Ladezeit einer Website verbessern kann, ist, dass statischer Content wie zB Bilder, ohne Cookies ausgeliefert werden sollen. Diese Maßnahme geht eigentlich Hand in Hand mit der Umstellung auf die Parallelisierung. Denn unsere eben eingerichteten Subdomains liefern ohnehin nur statischen Content aus. Deshalb haben wir sie ja eingerichtet. Das einzige, was wir noch machen müssen, ist sicherstellen, dass auch tatsächlich keine Cookies ausgeliefert werden. Dazu sind zwei Kleinigkeiten zu beachten:
In der settings.php die Zeile mit dem Eintrag mit folgendem Inhalt suchen
# $cookie_domain = 'example.com';
und durch folgenden Wert ersetzen:
$cookie_domain = '.www.DOMAINNAME.at';
Zuvor sollte man natürlich per .htaccess sicherstellen, dass alle Seitenaufrufe ohne den 'www.' prefix per Redirect an den www-Prefix weitergeleitet werden, sonst haben wir ein Problem mit den Cookies. Diese Einstellung findet sich standardmäßig in der mit Drupal ausgelieferte .htaccess. Sie muss nur einkommentiert werden und an die eigene Domain angepasst werden.
Zu guter letzt muss noch der Google Analytics Tracking Code angepasst werden (natürlich nur, falls Google Analytics verwendet wird ;)). Und zwar muss per 'setDomainName' Befehl sichergestellt werden, dass die Cookie-Domain der GA-Cookies ebenfalls auf die www-Domain beschränkt werden:
_gaq.push(['_setDomainName', 'www.agoradesign.at']);
Fertig! Wenn Sie alle Schritte richtig ausgeführt haben, werden die statischen Ressourcen Ihrer Drupal-Website jetzt parallel und ohne Cookies ausgeliefert und Sie sollten eine Performance-Verbesserung spüren. Zur Überprüfung empfehle ich Ihnen, den PageSpeed durch die gleichnamige Firebug-Erweiterung von Google messen zu lassen. Die beiden Maßnahmen "Serve static content from a cookieless domain" und "Parallelize downloads across hostnames" sollten nun großtels erfüllt sein :-)
Hallo,
ich finde den Artikel sehr interressant! Allerdings habe ich eine Frage. Und zwar würde ich gerne wissen wollen wo ich die .htaccess ablegen soll? Auf dem Server der Website? (Dann kann ich ja auch gleich die Schriften dort platzieren???) Oder auf dem "externen"-Server wo die Schriften bzw. die .eot, .svg usw. liegen.
Ich hoffe ihr könnt mir helfen.
Gruß Mirko
Hallo Jan!
Erstmals sorry für die verspätete Antwort. Ich habe Deinen Kommentar leider übersehen (Schande über mich!).
Das www stehen zu lassen ist in Deinem Fall sicher falsch, wenn Du die Seiten ohne www vorne auslieferst. Ich vermute aber, dass Du dann den Nachteil hast, dass die Dateien, die Du über die Subdomains auslieferst, erst recht wieder mit dem Session-Cookie ausgeliefert werden, da der dann auch automatisch für die Subdomains gilt, wenn Du das www weglässt.
Hast Du es in der Zwischenzeit schon ausprobiert? Würd mich interessieren...
Hab mir jetzt noch einmal die HTTP Header von unserer Seite angesehen. Die Session Cookies von Drupal werden über die CDN-Domains brav ausgelassen, aber jetzt zeigt es mir wieder die Google Analytics Cookies an.. Scheinbar klappt das mit dem setDomainname doch nicht (mehr).
Genau das habe ich eigentlich auch vermutet... Dafür kann man dann auf der neuen Domain mit Subdomains arbeiten, um mehr als eine Domain als CDN verwenden zu können.
Hi amayr,
dein Beitrag ist zwar schon älter, aber ers hat mich auf den richtigen Weg gebracht. Daher für alle Interessierten ein kleines informelles Update. Denn in der Zwischenzeit gibt es ein neues Modul zu diesem Thema: CDN (Content Delivery Network) http://drupal.org/project/cdn
VG