Ladezeiten-Optimierung

[meltemi]

Und die käme dann wohin?

Die .htaccess gehört ins Wurzelverzeichnis der Website. Die Regeln vererben sich auf Unterverzeichnisse (außer, dort läge eine gesonderte .htaccess mit anderen Regeln).

Ich fänd es sinnvoll, wenn die Angaben nicht für alle Seiten gleich gelten sollen.

Bei Deinen Ansprüchen wäre es sinnvoll, Du würdest Dich näher mit dem Apache-Modul mod_expires beschäftigen
http://httpd.apache.org/docs/2.2/mod/mod_expires.html

edit: cmbs Antwort gar nicht gesehen

[albert]

hab mal was rumgespielt. meine Startseite http://www.natur-und-handgemacht.de/ brauchte 5 - 6 sec. (hab sehr lahmes DSL z.Zt.).
Dann die Anweisungen aus obigem Beispiel (png ergänzt) in die bereits vorhandene .htaccess eingefügt: jetzt ca. 4 - 4,3 sec.. Also immerhin was, vor allem auf smartphone deutlich (meinen Flaschenhals werde ich weiter suchen).

Aber noch zum Verständnis: Wenn ich Text verändere wird das offenbar bemerkt und aktualisiert angezeigt trotz cache, wie ich jetzt gesehen habe. Da bräuchte ich doch also gar nicht bang zu sein, und könnte auch bei text eine lange Cache-Zeit einstellen oder was spricht dagegen?


PS (peinlich): wird das wie käsch ausgesprochen oder wie kaschee?

[cmb]

Aber noch zum Verständnis: Wenn ich Text verändere wird das offenbar bemerkt und aktualisiert angezeigt trotz cache, wie ich jetzt gesehen habe. Da bräuchte ich doch also gar nicht bang zu sein, und könnte auch bei text eine lange Cache-Zeit einstellen oder was spricht dagegen?

Ich vermute, dass der "Text" (also das eigentliche HTML) gar nicht gecachet wird; das ist jedenfalls bei mir so, wenn ich meltemis Anweisungen in die .htaccess schreibe. Bin nicht sicher -- vielleicht liegt das am Query-String.

Würde das Caching per Expires-Header funktionieren, dann würde, soweit ich weiß, der Browser nicht mal beim Server nachfragen, ob's was neues gibt, sondern einfach die Ressource aus dem Cache holen.

hab mal was rumgespielt. meine Startseite http://www.natur-und-handgemacht.de/ brauchte 5 - 6 sec. (hab sehr lahmes DSL z.Zt.).
Dann die Anweisungen aus obigem Beispiel (png ergänzt) in die bereits vorhandene .htaccess eingefügt: jetzt ca. 4 - 4,3 sec.. Also immerhin was, vor allem auf smartphone deutlich (meinen Flaschenhals werde ich weiter suchen).

Das ist ja schon mal was. Aber vergiss nicht: das gilt immer nur dann, wenn Ressourcen bereits gecachet waren. Zum einen muss der Client nicht cachen, zum anderen hilft es nichts, wenn man die Site zum ersten mal besucht.

Und letztlich sind auch 4 sec. viel zu langsam.

wird das wie käsch ausgesprochen oder wie kaschee?

Eher wie ersteres. Im Duden kannst Du es Dir auch anhören.

[meltemi]

Ich vermute, dass der "Text" (also das eigentliche HTML) gar nicht gecachet wird; das ist jedenfalls bei mir so, wenn ich meltemis Anweisungen in die .htaccess schreibe.

Ich habe den gestern genannten Beispielcode in den .htaccess-Dateien mehrerer Websites drin, und da funktioniert das überall. Das sind aber alle keine CMSimple(XH)-Websites.

Ich habe gerade mal alberts angegebene Website getestet. Für die Startseite gibt Rex Swain aus:

Code: Select all

Expires:·Thu,·19·Nov·1981·08:52:00·GMT(CR)(LF)

Das ist natürlich falsch.

Richtig wäre, wenn sechs Stunden eingetragen sind (wie für eine meiner Seiten):

Code: Select all

Expires:·Thu,·25·Sep·2014·21:45:21·GMT(CR)(LF)

Wenn man alberts Seite mit YSlow untersucht, sieht man das auch: unter EXPIRES (Y/M/D) steht für TYPE doc 1981/11/19. Bei den anderen TYPE klappt es aber: css 2014/10/3, image 2014/12/24, favicon 2015/3/24. (1)

Daß das Cachen des TYPE doc nicht funktioniert, scheint an den CMSimple(XH)-Besonderheiten zu liegen, und da kann ich jetzt leider nicht weiterhelfen. (Mein CMSimple-Projekt ist leider immer noch nicht im Netz.)

(1) Ausnahme: Crazystat image: 1997/7/26

[meltemi]

Ich trage mal die Links der genannten Werkzeuge nach:

http://www.rexswain.com/httpview.html (Online-Prüfung)
http://yslow.org/ (Browser-Erweiterung für fast alle Browser)

[cmb]

Daß das Cachen des TYPE doc nicht funktioniert, scheint an den CMSimple(XH)-Besonderheiten zu liegen, und da kann ich jetzt leider nicht weiterhelfen.

Zunächst mal liegt das wohl an PHP im allgemeinen. Dieses setzt bereits Expires Header, und die werden dann von mod_expire zurecht nicht überschrieben.

Ich hatte aber "gestern" schon mal ein paar Experimente gemacht, und auch wenn ich per PHP einen Expires Header in der Zukunft setze, scheint das den Browser (Google, Firefox) nicht zu interessieren. Es könnte sein, dass der Browser nicht cachet, wenn ein Query-String (?...) vorhanden ist. U.U. bräuchte man dann noch clean URLs.

Vielleicht böte sich statt dem Client seitigen cachen des HTML aber auch ein Server seitiges Caching an. Das Thema hatte Winni vor ein paar Wochen angesprochen. So etwas in der Art könnte man vielleicht mit dem alten Makeoffline Plugin erreichen -- kann aber sein, dass das Plugin unter aktuellen CMSimple(_XH) Versionen nicht richtig funktioniert (siehe http://cmsimpleforum.com/viewtopic.php?f=16&t=5534).

[meltemi]

meinen Flaschenhals werde ich weiter suchen

YSlow meldet:

1.

There are 14 images that are scaled down

Diese Bilder sollten in der tatsächlich benötigten Größe auf den Server hochgeladen werden (nicht in größeren Abmessungen).

2.

This page has 3 external stylesheets. Try combining them into one.

Das Problem haben wir an anderer Stelle schon mal diskutiert (sollte vielleicht allgemein gelöst werden mit dem Ziel zweier CSS-Dateien).

3.

This page has 9 external background images. Try combining them with CSS sprites.

Dieses Problem müßtest Du selbst lösen (nimm den gestern genannten Sprite-Generator).


Abgesehen davon: Nach mir vorliegenden Informationen hat Strato auf "Deinen" Server über 1000 (tausend) Websites draufgepackt. Das sind schon arg viele.

[albert]

Danke für deine Mühen.

Nach mir vorliegenden Informationen hat dein Provider auf "Deinen" Server über 1000 (tausend) Websites draufgepackt. Das sind schon arg viele

Den Provider will ich hier lieber nicht beim Namen nennen... Könnte sein, denn ich habe jetzt einiges mit yslow angestellt:
wenn z.B. die ges. Ladezeit 5 sec. ist, (38 Anfragen = 332 KB, davon 315 aus dem Cache)
sind nur drei GET die abgerufen werden, plugins.css 148 ms, stat.php 106 ms und
GET http://www.natur-und-handgemacht.de/ (doc, 9,2 KB)) 3810 ms = warten 3720 ms empfangen 50 ms

( im Antwort-header steht übrigens HTTP/1.1 200 OK Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache)
Abgesehen vom browsercache wird die doc wohl nicht serverseitig gecached (sonst wär nicht 200 ok sondern 304 not modified)

weitere Zeit pro jpg meist ca. 200 - 300 ms (z.B. 12,5 KB ges 224 ms davon blockieren 177 ms, warten 47 ms, empfangen 0 ms)
das erklärt bei 9 Bildern weitere 2 sec.
im Header steht bei allen Bildern u.a. "X-Pad avoid browser bug" - ist das normal?

Browsercache löst das Problem "warten" und "blockieren" ja nicht beim ersten Aufruf

Woran liegts also? ka
claen URLs hab ich nicht, bei mir wimmelt es von Sonderzeichen, z.B. Umlaute in den Seitenüberschriften

Vielleicht böte sich statt dem Client seitigen cachen des HTML aber auch ein Server seitiges Caching an

wie ich unter "304 not modified" gelesen habe ist das das serverseitige cachen, sonst wäre 200 ok, nur klappt das wohl nicht bei "doc".
Oder doch gecached, aber trotzdem ausgeliefert?

Liegts doch am Server?
meine http://www.albert-wilhelm.de braucht auch zu lang (ist ja fast nichts drin) 1,3 sec, davon sehr viel lila (warten)

Eben mailte mir einer, es habe beim ersten Aufruf 23 sec. gedauert, trotz 50 Mbit/s

[cmb]

wie ich unter "304 not modified" gelesen habe ist das das serverseitige cachen, sonst wäre 200 ok, nur klappt das wohl nicht bei "doc".

Mit Server seitigem Caching meinte ich, dass das HTML, das CMSimple generiert, auf dem Server bereits als HTML abgelegt wird; dann kann man sich die weitere Verarbeitung sparen. Das ist aber im Zweifel erst mal Zukunftsmusik.

Eben mailte mir einer, es habe beim ersten Aufruf 23 sec. gedauert, trotz 50 Mbit/s

Ich denke, das ganze hat sehr wenig mit der Bandbreite zu tun. Wie Du ja auch festgestellt hast, ist es die Verarbeitung des PHP, die furchtbar lange braucht. albert-wilhelm.de ist ja eigentlich noch im grünen Bereich -- aber eben nicht natur-und-handgemacht.de. Am Content dürfte es nicht liegen (oder ist content.htm sehr groß?). Allzu viele Plugins hast Du auch nicht. Es könnte an einem Plugin liegen (wie groß ist denn z.B. plugins/wellrad/data/catalogue.php?) Vielleicht liegt es aber auch an mehreren geturl()s (die blockieren die weitere Verarbeitung des Skripts).

Das beste wäre profilen. Dazu müsstest Du Dir eine lokale Testumgebung aufsetzen (XAMPP mit ein paar weiteren Programmen und Einstellungen), und die Website dort hin herunter laden. Und dann könntest Du messen.

[albert]

du meinst also, die lange Wartezeit bei doc liegt an der Verarbeitung des PHP? Wenn das klar wäre, wäre ja immerhin ein Fortschritt!

(oder ist content.htm sehr groß?

ist 540.400 groß? (ich glaube ja)
wellrad-catalog ist 145.200
geturl verwende ich nicht,
nur einmal file_get_contents, wenn ich das rausnehme ist aber gleich.

XAMPP mit ein paar weiteren Programmen und Einstellungen

muss ich wohl, mal sehen ob ich das schaffe

erstmal gute Nacht für heute und DANKE