Contao für Google Page Speed optimieren

[xchs]

Übrigens, falls es jemanden interessiert: Das Umschreiben der Pfadangaben für statische Ressourcen ("tl_files"-Verzeichnis, Plugins, Framework, Module) lässt sich auch mit der Erweiterung [cdn] von Andreas Schempp bewerkstelligen - beschränkt allerdings auf nur eine URL. Diese CDN-URL kann dann entweder auf ein "richtiges" Content-Delivery-Network zeigen (für die Deluxe-Variante) oder aber auch nur als Subdomain der eigenen Webseite eingerichtet sein ("Poor Man's CDN")

[FloB]

Ich habe diesen Lösungsansatz nur nicht als Standard empfohlen, weil auf Windows-Servern soweit ich weiß keine Symlinks existieren und auch nicht jedes FTP-Programm das Anlegen derselben unterstützt.

AFAIK gibt es seit Windows 7, womöglich schon Vista, Symlinks. Der Einwand mit den Symlinks ist zwar berechtigt, trotzdem würde ich in dem Artikel die alternative Methode ebenfalls nennen, sozusagen die "Advanced" Variante.

[leo]

Jepp, laden tut er es wohl korrekt...aber er meckert es nach wie vor an!?

Nach dem Ändern der Servereinstellungen muss man natürlich den Browsercache leeren und anschließen den Page Speed Score neu berechnen lassen.

[ways2web]

wunderhübsche anleitung !!!

ich hab mein pagespeed von 88 auf 94 angehoben... das ist doch mal was..
und dabei hab ich noch nicht mal meine stylesheets zusammengefasst...

danke community !

[redbecks]

Es gibt für solche Fälle noch einen alternativen Ansatz, der auf allen Unix-Servern funktionieren sollte. Man erstellt sich ein Unterverzeichnis namens "static" in seiner Contao-Installation und legt dort drei Symlinks auf "tl_files", "system" und "plugins" an. Anschließend routet man die Subdomains auf dieses Verzeichnis.

Danke für die Alternative, lokal funktioniert mal wieder alles super, doch online kann ich leider keine Symlinks anlegen. Vermutlich fehlen mir als kleiner Kunde bei 1und1 dazu einfach mal wieder die Rechte.

[Kahmoon]

Nach dem Ändern der Servereinstellungen muss man natürlich den Browsercache leeren und anschließen den Page Speed Score neu berechnen lassen.

Hab ich schon gemacht...is schon Standard bei Seitenreload . War aber nicht weg...

Kann mir noch jemand die Frage bezüglich den Google Bildindex sagen? Und ob man die Subdomains beim Direktaufruf auf die Hauptdomain umbiegen sollte?

Gruß

[xchs]

Wo findet man denn eigentlich die Empfehlung von Google, statische Ressourcen für die Dauer von einer Woche zu cachen? In den "Performance Best Practices" von Google Page Speed steht diesbezüglich u.a.

Set caching headers aggressively for all static resources. [...] Set Expires to a minimum of one month, and preferably up to one year, in the future.

Und bezüglich "Vary Header":

Set the Vary header correctly for Internet Explorer.
Internet Explorer does not cache any resources that are served with the Vary header and any fields but Accept-Encoding and User-Agent. To ensure these resources are cached by IE, make sure to strip out any other fields from the Vary header, or remove the Vary header altogether if possible.

Müsste man demzufolge dann nicht in der ".htaccess.default" anstelle von

Header append Vary Accept-Encoding 

den "Vary Header" neu setzen

Header set Vary Accept-Encoding 

[Merlin]

haloechen ...

nur mal so anfragen

- Leverage browser caching
- Serve static content from a cookieless domain

was muss ich denn noch einstellen damit das funzt, habe das modul, und die subdomains angelegt die htaccess editiert. seite lauft auch aber diese beiden sachen bekomm ich nicht hin

[aibiman]

Hallo zusammen,

ich denke es würde sich evtl. anbieten das Thema "Frontend Performance" ganzheitlich zu betrachten und in einem eigenen Contao-Modul/Abschnitt zu vereinen.

Die Empfehlungen der Firebug-Tools Pagespeed (Google) und YSlow (Yahoo) beruhen hauptsächlich auf Thesen von Steve Souders der erst bei Yahoo und dann bei Google angeheuert hat.

Bekannte Bücher von Steve Souders zu diesem Thema sind "High Perfromance Web Sites" und "Even Faster Web Sites".
Weitere Tipps sind auch auf http://stevesouders.com/ zu finden.

Nachfolgend die wichtigsten Punkte (ich habe diese in unterschiedliche Themengebiete eingeteilt) die für eine gute Performance verantwortlich sind:


HTTP-Requests:

• Reduzierung HTTP-Requests
• Nutzen von Domain sharding/CDN
• Vermeiden von Redirects

Transfer-Volumen:

• GZip-Komprimierung
• Minfiying von JS/CSS-Dateien
• Optimierung Bilder

Browser-Caching

• Verwendung von Expires-Header
• Verwendung von ETags

CSS/JS

• CSS im <head>
• JS am Ende des <body>
• JS und CSS in Dateien auslagern
• Vermeiden von CSS-Expressions

Sonstige

• DNS Lookups vermeiden
• Entfernen von doppelten Daten
• Caching von AJAX-Requests
• Weniger DOM-Elemente

Nachfolgend die aus meiner Sicht relativ "einfach" integrierbare Punkte in Contao und was dafür
getan werden müsste:

- Reduzierung HTTP-Requests
- Minfiying von JS/CSS-Dateien
Contao:
Zusammenfassung von CSS- und JS-Dateien

• Möglichkeit zur Definition von CSS- und JS-Dateien die zu jeweils einer Datei zusammengefasst werden.
• Möglichkeit zur Auswahl, ob diese Datei "geminifyed" werden soll
• Per Knopfdruck Generierung dieser Datei

- Nutzen von Domain sharding/CDN
Contao:

• Möglichkeit in Contao der Definition von Urls die genutzt werden soll z. B. static.mydomain.de, media.mydomain.de
• Zuweisung von Urls zu bestimmten Dateitypen z. B. css/js > static.mydomain.de, img/cache > media.mydomain.de

- GZip-Komprimierung
- Verwendung von Expires-Header
- Verwendung von ETags
- Nutzen von Domain sharding/CDN
Contao:

• Möglichkeit in Contao enstpr. Einstellungen zu definieren
• Per Knopfdruck Generierung der entspr. .htaccess-Codeschnipsel oder gleich der .htaccess-Datei

Bei Verwendung der Expire-Headers ergibt sich folgendes Problem:
Wird eine Datei vor Ablaufdatum geändert, wird sie nicht vom Client aktualisiert.

Diesem Verhalten kann man mit einem sogenannten "Cache-Buster" begegnen:

Cache-Buster: zwei Varianten:

1. Versionsnummer als GET-Parameter

http://www.mydomain/js/base.js?v=R.05.2010

> Einige Web-Proxys (z. B. Squid) cachen dies nicht

2. Versionsnummer im Verzeichnisnamen

http://www.mydomain/js/R.05.2010/base.js

> .htaccess
RewriteRule js\/.*\/(.*)\.js /js/$1\.js [L]

Contao:

• Möglichkeit in Conato zum setzen einer Release-Namens z. B. <frei wählbarer Name> + <Contao-Version>
• Der Release-Name müsste dann an allen betroffenen Stellen (CSS/JS, Systemgrafiken, etc.) in den Url's eingebunden werden
• Bei einer Änderung würde dann einfach der Release-Name geändert werden und somit würde der Expire-Header ungültig, da die "alten" Dateien auf einen anderen Pfad zeigen würden.

Ich denke mit den obengenannten Vorschlägen hätte Contao ein wichtiges Feature integriert, welches den meisten Konkurrenten fehlt.


Viele Grüße
Steffen

[leo]

von meinen 0,4* Sekunden wächst die Zeit auf 0,6 Sekunden an. Was genau die Gründe sind kann ich leider noch nicht sagen

Ich tippe vielmehr auf den Apache. Zum Verständnis: HTTP/1.1 legt fest, dass der Browser maximal 2 Verbindungen pro Hostname erlauben soll (bei vielen modernen Browsern sind es inzwischen mehr). Bei einer Seite mit 20 Dokumenten würden also 10 Mal hintereinander 2 Dokumente angefragt. Der Trick mit den Subdomains soll diese "Sperre" umgehen, indem er 4 x 2 Verbindungen ermöglicht. Bei 20 Dokumenten würden also 2,5 Mal hintereinander 8 Dokumente angefragt.

Soweit die Theorie im Browser. Für den Apache bedeuten 8 gleichzeitige Verbindungen natürlich eine andere Last als 2 (Stichwort "MaxClients"). Je nachdem wie der Server konfiguriert ist und wie gut er ausgelastet ist, hat er unter Umständen gar keine 8 Prozesse mehr frei und ein Teil der Anfragen landet in der Queue. In diesem Fall bringt der "Hack" gar nichts, sondern kostet nur zusätzlichen Verbindungsaufbau und DNS-Lookups. Die Folge ist logischerweise eine höhere Ladezeit.

Man darf also nicht nur blind den Code kopieren und einfügen, sondern man muss die Zusammenhänge verstehen und die Systemkomponenten optimal aufeinander abstimmen. Deswegen habe ich ja auch extra am Anfang des Artikels darauf hingewiesen, dass nicht alle Empfehlungen des Page Speed Plugins in der Praxis sinnvoll sind.

[leo]

So, noch mehr Infos dazu: http://code.google.com/intl/de-DE/sp...elizeDownloads

using multiple concurrent connections can cause increased CPU usage on the client, and introduces additional round-trip time for each new TCP connection setup, as well as DNS lookup latency for clients with empty caches. Therefore, beyond a certain number of connections, this technique can actually degrade performance. […] We recommend this technique for any page that serves more than 10 resources from a single host. (For pages that serve fewer resources than this, it's overkill.)

Und hier eine Übersicht, wie viele gleichzeitige Verbindungen pro Browser möglich sind:

http://www.browserscope.org/?category=network

Google sagt ganz klar, dass diese Technik a) nicht für alle Seiten geeignet ist und b) es einen Break-Even-Punkt gibt, ab dem sich der Spaß lohnt. Unterhalb dieses Punkts kann die Performance sogar negativ beeinflusst werden. Googles Paradebeispiel ist Google Maps -> viele einzelne Bilder werden geladen -> eindeutig mehr als 10 Ressourcen

Auf contao.org ist der Unterschied in der Tat nur marginal. Es gibt teilweise sogar Seiten, die ohne den "Hack" ein paar Zehntelsekunden schneller laden. Andere wie z.B. die Seiten zum Usertreffen mit vielen Fotos, laden mit dem "Hack" ein wenig schneller. Insgesamt liegen die Unterschiede aber nur im Zehntelsekundenbereich.

Ziel des Workshops war es, den Page Speed Score so hoch wie möglich zu bekommen. Ich habe aber schon eingangs betont, dass ein optimaler Page Speed Score nicht automatisch auch die sinnvollste und beste Lösung ist. Das muss man immer im Einzelfall entscheiden.

[xchs]

Ziel des Workshops war es, den Page Speed Score so hoch wie möglich zu bekommen.

Für die betreffende Seite des Workshops erhalte ich sogar einen Google Page Speed Score von 97/100!

Was mir noch aufgefallen ist: Wie in den Google Performance Best Practices nachzulesen ist (und auch aibiman schon angedeutet hat) könnten einige (alte?) Proxy-Server Probleme mit Query Strings in der URL haben, wenn es darum geht, statische Ressourcen geeignet zu cachen.

Don't include a query string in the URL for static resources.
Most proxies, most notably Squid up through version 3.0, do not cache resources with a "?" in their URL even if a Cache-control: public header is present in the response. To enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves.

Was die MooTools-Templates betrifft, könnte man dazu in Contao die Versionierung der Ressourcen direkt in die URL mit einbauen, beispielsweise so:

<?php

// Add mediabox style sheet
$GLOBALS['TL_CSS'][] = 'plugins/mediabox/css/mediabox-'. MEDIABOX .'.css|screen';

?>

<script type="text/javascript" src="plugins/mediabox/js/mediabox-<?php echo MEDIABOX; ?>.js"></script>

Über eine entsprechende RewriteRule müsste dann allerdings die URL mit dem Versionsfragment wieder so umgeschrieben werden, dass der Server die dort vorhandenen Ressourcen auch wieder findet.

Auch die URL zur Library für das MooTools-Framework auf googleapis.com enthält die Versionsnummer als Fragment der URL selbst:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/mootools/1.2.4/mootools-yui-compressed.js"></script>

Für alle anderen von Contao mit einer Versionsnummer versehenen Ressourcen (mootools-more.js, Stylesheets usw.) müsste man hingegen weitreichende Änderungen im Core selbst durchführen...

Weiters empfiehlt Google in seinen Performance-Regeln, einen "Cache-control: public" Header mitzusenden, damit statische Ressourcen auch von öffentlichen Proxy-Servern (ISPs) gecached werden können:

Header append Cache-Control "public"

bzw. falls man zusätzlich auch noch die Cache-Zeit getrennt nach Dateityp festlegen möchte z.B.

<FilesMatch "\.(ico|jpg|jpeg|png|gif|swf)$">
  Header set Cache-Control "public, max-age=2592000"
</FilesMatch>
<FilesMatch "\.(css|js)$">
  Header set Cache-Control "public, max-age=604800"
</FilesMatch>

@aibiman:

Verwendung von ETags

Richtigerweise müsste es eher heißen "Konfigurieren von ETags" und zwar so, dass die serverspezifische ID ("INode") aus dem Tag entfernt wird:

FileETag MTime Size

bzw. vielleicht besser

FileETag -INode MTime Size

Möchte man hingegen ganz auf die Verwendung von ETags verzichten (und stattdessen den Last-Modified Header verwenden) dann könnte man die ETags auch gleich ganz deaktivieren

FileETag None

und ggf. auch aus dem HTTP-Header entfernen

Header unset ETag

So spart man sich zusätzlich noch ein paar "wertvolle" Bytes im Header.

[Mynyx]

Hallo,

die Geschwindigkeit einer Website ist definitiv kein Kriterium für den PageRank, dieser wird ausschließlich aus den Links berechnet. Gemeint ist das Ranking in Google, allerdings hat das Umschreiben von URLs auch darauf im Prinzip keine Auswirkung, aber keinesfalls eine erhebliche. (Insbesondere da die URLs bereits in der Standardform ohne Parameter auskommen und aber auch das sowie die gesamte Gestaltung der URL hinsichtlich Keywords keine Auswirkung haben soll (Siehe SISTRIX))

Viele Grüße
Mynyn

[stefan-at-work]

die Geschwindigkeit einer Website ist definitiv kein Kriterium für den PageRank, dieser wird ausschließlich aus den Links berechnet.

na denn irrt Google wohl:

You may have heard that here at Google we're obsessed with speed, in our products and on the web. As part of that effort, today we're including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.

Nachzulesen hier

[Mynyx]

search ranking algorithms != PageRank