Pagespeed Erhöhung

[mausi]

Hallo zusammen!

Mit Erstaunen musste ich feststellen, dass der Begriff "Pagespeed" noch nie im Forum erwähnt wurde. Habe gestern versucht einem Portal auf webEdition Basis (http://www.niederrhein-kult.de) etwas auf die Beine zu helfen, da der Pagespeed einer Seite ja immer mehr eine Rolle spielen (soll). Neben den normalen .htaccess Dingen wie

- Komprimierung für alles außer Grafiken
- Cache-Time Einstellungen

habe ich 2 weitere Subdomains angelegt und deren Root auf den Root der Hauptdomain geleitet. Via .htaccess lasse ich dann alle Bildformate von der einen und alle JavaScripte und CSS-Dateien von der anderen Domain einlesen. Das klappt soweit hervorragend und der Pagespeed der Startseite z.B. hat sich von 86 auf 93 erhöht. Die Seite baut sich wirklich viel schneller auf (wegen Anzahl paralleler Zugriffe auf eine Domain).

Problem jetzt noch: Da alle diese Dateien via Rewrite umgelenkt werden, ist das nur suboptimal. Besser wäre natürlich, wenn man direkt auf die Dateien auf den Subdomains zugreifen würde. Ein HTML-Base lenkt leider ja alle Dateien um. D.h. Dazu müsste man all diese Aufrufe ändern und könnte nicht mehr mit den we:tags arbeiten. Meine Idee: Ein zusätzlicher Parameter z.B. DOMAIN bei den IMG oder JS/CSS-Tags oder, noch besser, wenn man das zentral irgendwo angeben könnte.

Wie seht ihr das?

gm

[WBTMagnum]

Solche Überlegungen in webEdition einfließen zu lassen erachte ich persönlich auch als wichtig. Die Unterstützung von CDNs als sinnvolle Erweiterung. Mach doch bitte einen Feature Request in der Bugbase.

Man kann das ganze natürlich auch noch weiter denken:
* Automatisches Zusammenführen und Verkleinern von JS-/CSS-Dateien.
* Unnötigen Whitespace aus den pre-parsed Dokumenten entfernen.
* etc.

Andere Baustellen sind hier vom meinem Gefühl her aber wichtiger.


Just my 2 cents,
Sascha

[mausi]

... ich meine das schon einmal in der Bugbase hinterlegt zu haben (ich schaue mal nach). Mein Vorschlag für die SEO-Optimierung bei der Ausgabe bei Listview-Navigation etc. wurde ja bereits in der 6.3 berücksichtigt. Ich hoffe das die Optimierungen für das Backend (z.B. bei Blöcken) sich evtl. auch auf die Webseiten selber auswirken.
Sobald man in webEdition kompliziertere Dinge umsetzt, geht leider oft die Performance flöten oder man setzt die Dinge direkt in PHP um, was ich aber aus Update-Gründen immer versuche zu vermeiden. Cachen kann man ja leider auch nicht überall, weil Content immer mehr vom User beeinflussbar sein muss ...

[mokraemer]

Meiner Erfahrung nach bringt eine serverseitige Komprimierung mehr, als ein paar Whitespaces rauszufiltern. Auf den Parser des Browsers hat das ohnehin kaum Einfluß. Für den Browser und dessen Cache ist es da wichtiger, dass sich die Dateien nicht ändern, er also die lokalen Skripte verwenden kann - je nachdem wie schlau der Browser ist/oder sein wird, hat er css/js in seinem Cache ja bereits vorverarbeitet liegen.
Nach meinen Tests sollten die Blockoptimierungen einiges bringen. Der we interne Cache hingegen schluckt eher Performance, weshalb er zunächst entfernt wird. Sollte sich herausstellen, dass ein neuer Cache besser funktioniert, werden wir diesen ggfs. einbauen.
Meine Hoffungen liegen jedoch eher in Richtung des zentralen Einsprungpunktes, der dann frequentierte Seiten als statische Dokumente alle x Minuten neu speichern könnte - aber das muß erst noch gebaut werden

[ThomasGoebe]

Hi zusammen,

ich habe gerade im aktuellen webstandards magazin etwas zu dem Theman Optimierung gelesen und doch das eine oder andere neue erfahren.

Ich denke, so was wie JS/CSS Kollektor könnte wirklich sinnvoll sein, um die Requests zu verringern.

Ich kann mir folgendes vorstellen:
<we:css id="x" collect="NameDerKollektion" />
<we:css id="y" collect="NameDerKollektion" />

<we:js id="x" collect="NameDerKollektion" />
<we:js id="y" collect="NameDerKollektion" />


<we:collector type="css" name="NameDerKollektion" />
<we:collector type="js" name="NameDerKollektion" />

Damit werden die eigentlichen js und css Inhalte gesammelt ausgeben.
Das könnte dann auch gleich Minmieren etc. und sicher auch cachen.

Bleibt natürlich die Frage zu klären, ob dann wirklich eine neue Datei angelegt wird (neuer Dateityp Kollektor z.B., der ähnlich we:include die Daten bekommt, nur eben irgendwie dynamisch, so dass man nicht manuell die IDs der Dateien reinschreiben muss und idealerweise natürlich auch Pfade in den Dateien mit geändert werden, wenn nötig.

Muss sicher noch durchdacht werden, aber die Richtung finde ich interessant.

[mokraemer]

? wieviele CSS/JS Dateien verlinkt ihr so?
Bei mir kann der Browser 16 Zugriffe pro Server parallel machen. Was doch eigentlich lange dauert ist der Zugriff auf Skripte: hier muß der Server arbeiten.
Ansonsten hilft es dem Browser wenn man beherzigt ihm zuerst alle CSS infos zu geben, dann ggfs. die Seite aufbaut und ganz unten dann die Skripte lädt, sonst hält das Parsen der Skripte ggfs. den Seitenaufbau auf (meine das mal als Tipp irgendwo gelesen zu haben - habs aber nicht überprüft).

[WBTMagnum]

@kollektor:
die idee trage ich auch schon die längste zeit mit mir herum und unterstütze sie somit vollinhaltlich. hinweis: damit es mit dem caching keine probleme gibt, muss sichergestellt werden, dass neu generierte "kollektions" einen neuen url/identifier bekommen, sonst dauert es ggf. "ewig und noch länger" bis änderungen bei den clients ankommen.

@whitespace:
klar bringt das jetzt nicht die welt, für seiten mit hohem traffic rechnet sich das aber schon wieder.

@js am pageende:
ja, dass bringts durchaus. ist halt etwas gewöhnungsbedürftig .


lg,
sascha

[ThomasGoebe]

All die Tipps waren im Webstandards Magazin und auch eine kleine Einschätzung, was es bringt. Angeblich sind 80% - 90% der Ladezeit vom Frontend (Browser) verursacht. Das lässt sich eben deutlich beschleunigen.

Ich denke auch, dass wir in der Zukunft da noch mal nachschauen sollten. Ich kann den Artikel empfehlen und interessanterweise auch das Magazin (habs mir zum ersten Mal gekauft).

Ich glaube, alle Artikel, die älter als drei Monate sind, gibts auf der Webseite kostenlos. Also einfach warten