Seitenperformance verbessern mit Hilfe des Parallel-Moduls von Drupal

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 :-)