Google pagespeed und caching

Janl · 02. September 2015 23:56

ich bekomme folgende Bemerkung
"Browser-Caching nutzen"

in mein .htaccess steht aber

Hier klicken, um den Code zum Kopieren zu markieren

[== htaccess ==]
##EXPIRES CACHING##
<ifmodule mod_expires.c="">
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType text/css "access 1 year"
ExpiresDefault "access plus 2 days"
</ifmodule>

irgend wie ist es als ob Google es nicht lesen will mod rewrite um mit und ohne www auf eine der Beide um zu lenken funktioniert aber.

Hat jemandem eine Idee warum Google das nicht nimmt?

MfG
Jan

Beitrag geändert von Janl (02. September 2015 23:58)

Klenkes · 02. September 2015 08:00

Google erwartet natürlich auch Dinge wie:

Hier klicken, um den Code zum Kopieren zu markieren

<IfModule mod_headers.c>
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=31536000, public"
</FilesMatch>

<FilesMatch "\.(js|xml|txt)$">
Header set Cache-Control "max-age=2678400, private"
</FilesMatch>

Henk1060 · 02. September 2015 11:25

mal eine frage zu "max-age=31536000,
was für einen zeitwert entspricht das? Sekunden minuten ...

NaN · 02. September 2015 12:11

Sekunden.

Andynium · 02. September 2015 16:32

Hast du mal geschaut, welche Dateien noch gecacht werden sollen?

Hatte schon den Fall, dass der Analytics Code angemeckert wurde, bei dem ein Caching dem gedachten Einsatzzweck zuwider liefe...

Janl · 03. September 2015 23:33

Habe noch keine Zeit gehabt.
Es betrifft ein Vserver, aber ich habe gefunden dass Caching nicht gestartet ist. Dann kann man im htacces schreiben was man will, passiert nichts oder?
Erst mal andere Arbeiten beenden, dann weiter (ver)suchen.
MfG Jan

faglork · 03. September 2015 10:39

Servus Jan!

Janl schrieb:

Habe noch keine Zeit gehabt.
Es betrifft ein Vserver, aber ich habe gefunden dass Caching nicht gestartet ist.

mod_expires / mod_headers ist nicht geladen? Wäre eher unüblich.

Ja, in dem Fall wären Cache-Anweisungen natürlich sinnlos ...

BTW, hier mal ne htacces zur Orientierung:
https://gist.github.com/davatron5000/427761

Servus,
Alex

Beitrag geändert von faglork (03. September 2015 10:42)

Janl · 03. September 2015 11:17

Danke Alex,

in Paralells hat man ein Userinterface für Apache, da hat es bei "Cache" kein Häckchen gegeben.
Ich schau das mal in Detail an, direkt in Configfiles aber momentan muss ich andere Sachen zur Ende machen. Auf diesem Vserver dreht noch so wenig, dass ich etwa 5% Diskspace nutze und in Durchschnitt 2 % CPU-Belastung habe.

Jedenfalls habe ich diese htaccess geladen und versuche es erst einmal so drinnen zu kopieren.

MfG
Jan

Janl · 11. September 2015 17:18

Das war super Alex,

jetzt hat es geklappt.
Da hatte ich mit kopieren auch noch etwas vergessen.

Was ich mich aber noch frage ist welche Kompressionsgrad Google eigentlich erwartet für Bilder (jpg). Google meckert nämlich immer, aber wenn man zu viel komprimiert leidet doch der Qualität.

Weiteres Punkt ist "above the fold" CSS kann man nicht laden "below the fold", doch.
Entweder ich verstehe Google nicht oder W3schools nicht.

MfG
Jan

PS jetzt kann ich alle htaccess-Dateien noch mal kontrollieren und in Ordnung bringen aber das tue ich gerne.

Andynium · 14. September 2015 18:07

Janl schrieb:

Was ich mich aber noch frage ist welche Kompressionsgrad Google eigentlich erwartet für Bilder (jpg). Google meckert nämlich immer, aber wenn man zu viel komprimiert leidet doch der Qualität.

Die online pagespeed info bietet doch den Download von nach Googles Meinung optimierten Bildern an. Lässt sich da nicht heraus bekommen, was sich Google darunter vorstellt?

http://www.gimpforum.de/showthread.php?t=13964

Oder werden bei den Vorschlägen "nur" die Meta-Daten rausgeschmissen?

faglork · 14. September 2015 20:36

Janl schrieb:

Weiteres Punkt ist "above the fold" CSS kann man nicht laden "below the fold", doch.

doch doch, das geht.

https://jonassebastianohlsson.com/criti … generator/
--> damit kannst du den Teil des css generieren, der im head *inline* eingefügt wird.
--> den rest lädst du dann erst vor dem </body>

guggst du hier:
http://tinyurl.com/qytzev7

Janl schrieb:

Entweder ich verstehe Google nicht oder W3schools nicht.

W3schools ist nicht immer korrekt.

Servus,
Alex

faglork · 14. September 2015 20:39

cyberman schrieb:

Janl schrieb:
Was ich mich aber noch frage ist welche Kompressionsgrad Google eigentlich erwartet für Bilder (jpg). Google meckert nämlich immer, aber wenn man zu viel komprimiert leidet doch der Qualität.
Die online pagespeed info bietet doch den Download von nach Googles Meinung optimierten Bildern an. Lässt sich da nicht heraus bekommen, was sich Google darunter vorstellt?

Ja, es wird halt ein bisschen meht komprimiert. Woran Google die Grenze festmacht ist völlig unklar. Ist eh nicht praktikabel, wenn meine Kunden Bilder hochladen dann ist das eh wurscht ;-)

cyberman schrieb:

Oder werden bei den Vorschlägen "nur" die Meta-Daten rausgeschmissen?

Nein.
https://developers.google.com/speed/pag … mizeImages

Servus,
Alex

Beitrag geändert von faglork (14. September 2015 20:42)

Janl · 14. September 2015 21:50

Da hab ich doch noch eine Gewissensfrage.

Wenn man dann seine Bildchen komprimiert hat zum $%#$-Qualität und
nur kritische CSS "above the fold" ladet dann ist so eine Webseite
sicher 0.33 Sekunde schneller.

Macht das eigentlich Sinn?

MfG
Jan

Andynium · 15. September 2015 22:08

Die Performance von Webseiten ist ein wichtiger Ranking-Faktor - von daher macht es schon Sinn.

Und ausgehend davon, dass Webseiten in diesem Zusammenhang in unter 1 Sekunde "fertig" sein sollten, könnte eine Verbesserung um 0,33 Sekunden zum Beispiel eine Erhöhung der Performance um 50% bedeuten.

Ist ja auch kein reiner Selbstzweck ... wer eher fertig ist, kann sich schneller der nächsten Aufgabe (=Webseiten-Besucher) zuwenden.

Janl · 15. September 2015 22:19

Ich soll mich schämen, das hätte ich selber bedenken müssen!
"nächsten Aufgabe (=Webseiten-Besucher)"

Momentan teste ich bessere Einstellungen für "Speed" aber mache es mit Seiten/Domains die ohnehin sehr wenig Besucher haben und nur für unsere eigene Angelegenheiten sind.

Ich versuche diese Komprimierungseinstellunegn mal in einer Test (900x600px), mal sehen ab wann Google ncht mehr plappert!

MfG
Jan

faglork · 15. September 2015 22:34

Was mich wirklich wundert ist dass Google kein prefetching einfordert, obwohl gerade Chrome sowas von Haus aus verwendet.

Siehe
https://medium.com/@luisvieira_gmr/html … 54f6dda15d
http://w3c.github.io/resource-hints/

Das funktioniert wirklich gut, man kann es sehr schön in den Wasserfall-Diagrammen sehen.

Servus,
Alex

Andynium · 15. September 2015 23:17

Janl schrieb:

Ich soll mich schämen, das hätte ich selber bedenken müssen!

Nee, musst du nicht wink .

Performance muss man einfach "denken" - sprich alte Vorgehensweisen komplett aus seinem Gehirn streichen.

Und das hat nicht einmal das Dev-Team in der V2 hinbekommen, obwohl es ihr Job ist und wir hier massive Hilfestellung gegeben haben.

Janl schrieb:

Ich versuche diese Komprimierungseinstellunegn mal in einer Test (900x600px), mal sehen ab wann Google ncht mehr plappert!

Hast du schon den ImageCompressor gecheckt?

http://dev.cmsmadesimple.org/projects/imagecompressor

Dockt an die SmushIt API an, und da sollten in etwa die Werte dabei heraus kommen, die Google sich "wünscht" ...

faglork schrieb:

Was mich wirklich wundert ist dass Google kein prefetching einfordert, obwohl gerade Chrome sowas von Haus aus verwendet.

Kommt vllt noch ... könnte man alternativ ggf. auch über einen Appcache erledigen

http://www.html5rocks.com/de/tutorials/ … /beginner/

Hab jetzt gerade nicht im Fokus, wie es mit der Unterstützung von Prefetching durch andere Browser aussieht.

Janl · 15. September 2015 23:37

Komisch ist, dass bei immo-cz.info mit jquery, gallery-script und gallery-css UNTER "der Fold" genau über <body> diese Gallery nicht mehr funktioniert.

Kompression möchte ich ohne CMSMS klar haben.

MfG
Jan

faglork · 15. September 2015 00:15

Janl schrieb:

Komisch ist, dass bei immo-cz.info mit jquery, gallery-script und gallery-css UNTER "der Fold" genau über <body> diese Gallery nicht mehr funktioniert.

Das funktioniert evtl. nicht mit allen Scripten. Gallery mit Fancybox funzt jedenfalls.

Nicht vergessen auch die "document.ready"-Sachen ans Ende zu packen.

Servus,
Alex

faglork · 15. September 2015 00:24

cyberman schrieb:

Janl schrieb:
Ich versuche diese Komprimierungseinstellunegn mal in einer Test (900x600px), mal sehen ab wann Google ncht mehr plappert!
Hast du schon den ImageCompressor gecheckt?
http://dev.cmsmadesimple.org/projects/imagecompressor
Dockt an die SmushIt API an, und da sollten in etwa die Werte dabei heraus kommen, die Google sich "wünscht" ...

AFAIK gibt es Smushit doch gar nicht mehr ...?
http://www.geekwire.com/2015/web-develo … n-service/

cyberman schrieb:

faglork schrieb:
Was mich wirklich wundert ist dass Google kein prefetching einfordert, obwohl gerade Chrome sowas von Haus aus verwendet.
Kommt vllt noch ... könnte man alternativ ggf. auch über einen Appcache erledigen

Äh. nein ... da gehts nicht ums caching. Caching setzt ja erst ein wenn die Daten schon da sind. Bei dem ganzen "pre-"gerödel gehts um Daten die *noch nicht* da sind.

Hier ist es am Beispiel dns_prefetch sehr schön erklärt:
https://thomas.vanhoutte.be/miniblog/dns-prefetch/
und das Ergebnis ist deutlich und kann anhand der Wasserfall-Diagramme verifiziert werden.

Ich hab das grad mal ausprobiert:
http://tinyurl.com/o2blrhb

Da werden alle beteiligten URLs von Google Fonts und Youtube schonmal vorab aufgelöst per dns_prefetch.
Der Kasus Knacktus ist ja, dass ein guter Teil der Besucher das Video starten wird. Da fallen dann einige DNS-Auflösungen weg, weil längst schon erledigt - parallel(!) zu den "normalen" Anfragen.

Kann man sicherlich noch weiter treiben mit "preconnect" und "subressource", aber das kostet ja erstmal Zeit das alles durchzutesten ...

cyberman schrieb:

Hab jetzt gerade nicht im Fokus, wie es mit der Unterstützung von Prefetching durch andere Browser aussieht.

Gut genug um es einzusetzen:
http://caniuse.com/#feat=link-rel-dns-prefetch

Servus,
Alex

Beitrag geändert von faglork (15. September 2015 00:36)

faglork · 15. September 2015 00:52

Janl schrieb:

Da hab ich doch noch eine Gewissensfrage.
Wenn man dann seine Bildchen komprimiert hat zum $%#$-Qualität und
nur kritische CSS "above the fold" ladet dann ist so eine Webseite
sicher 0.33 Sekunde schneller.
Macht das eigentlich Sinn?

Nun ja. Das kann man auch gewinnbringend einsetzen: "Das ist der Unterschied zwischen einer Website die irgendein 'wäppdesigner' hingeklatscht hat und einer Website die ein Profi installiert hat." Eine Website daraufhin zu optimieren ist nicht grad trivial, und das sollte man auch so vermitteln.

Man kann entweder über "noch mehr Arbeit" klagen oder daraus ein Servicepaket schnüren und den Kunden anbieten.

Als Google heuer im Frühjahr angekündigt hat dass Mobiltauglichkeit zum Ranking-Faktor wird habe ich gleich eine Rundmail mit entsprechendem Angebot versandt. Die Resonanz war sehr gut, vor allem weil das Thema ja gut in den Medien vertreten war.

Und mit jedem Schnipsel das von einer anderen Domain geholt wird - seien es nun Google Fonts, Youtube-Videos, Facebook-Streams oder Twitter-Nachrichten - wird pre_fetching interessanter. Und jeder kennt die Verzögerung, bis das Zeugs alles da ist. Und da Geschwindigkeit ein Ranking-Faktor ist ...

Servus,
Alex

Andynium · 15. September 2015 09:30

faglork schrieb:

AFAIK gibt es Smushit doch gar nicht mehr ...?

Dann haben die Orks wieder mal gepennt - für so etwas müsste es einen separaten Archiv-Bereich geben hmm ...

Man(n) müsste das Modul mal auf andere Dienste anpassen

https://wordpress.org/plugins/ewww-image-optimizer/
https://optimus.io/

faglork schrieb:

Äh. nein ... da gehts nicht ums caching. Caching setzt ja erst ein wenn die Daten schon da sind. Bei dem ganzen "pre-"gerödel gehts um Daten die *noch nicht* da sind.

Hast du dir die Infos dazu genau durchgelesen tongue ?

Appcache = Application Cache = Cachen einer (kompletten) Applikation/Webseite.

Heisst praktisch, dass du die komplette Webseite (sofern sie nicht dynamisch ist) mit einem Rutsch auf den Rechner des Kunden laden könntest, wo er dann komplett offline darin navigieren könnte ...

Musst nur eine Sitemap und alle sonstigen für die Webseite benötigten Dateien im Manifest listen - fertig big_smile : Schneller geht es nicht. Ist ja auch eine Art Prefetching/Preloading ...

Die Daten dürfen in der Summe nur nicht größer 5 MB sein, ist also gerade für kleinere Seiten predestiniert.

faglork · 15. September 2015 17:05

cyberman schrieb:

faglork schrieb:
Äh. nein ... da gehts nicht ums caching. Caching setzt ja erst ein wenn die Daten schon da sind. Bei dem ganzen "pre-"gerödel gehts um Daten die *noch nicht* da sind.
Hast du dir die Infos dazu genau durchgelesen ?
Appcache = Application Cache = Cachen einer (kompletten) Applikation/Webseite.
Heisst praktisch, dass du die komplette Webseite (sofern sie nicht dynamisch ist) mit einem Rutsch auf den Rechner des Kunden laden könntest, wo er dann komplett offline darin navigieren könnte ...

dns-prefetch und pre_connect beziehen sich nicht auf die Website, sondern auf externe Sites, wie zb. Facebook, Google, Youtube ... Die kannst du doch nicht in einen Appcache laden. Zudem da ja in der Regel noch ein wechselnder Parameter erzeugt wird (quasi wie ne session). Wären daher auch bei Einsatz eines Appcache sinnvoll.

prefetch, prerender und subressource beziehen sich auf 'interne' files, ja.

Servus,
Alex

Andynium · 15. September 2015 17:50

faglork schrieb:

Die kannst du doch nicht in einen Appcache laden.

Kann ich doch ;p.

http://www.webdesign-podcast.de/2014/01/27/html5-appcache-offline-manifest/ schrieb:

CACHE MANIFEST
# 2014-01-26:v1
CACHE:
unterseite1.html
unterseite2.php
//fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,600,700
//html5shiv.googlecode.com/svn/trunk/html5.js
//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min.js
assets/css/bootstrap.min.css
assets/css/mycodestock/jquery-ui-1.10.3.min.css
assets/css/main.css
assets/img/background-berlin_ipad.jpg
assets/img/background-berlin.jpg
assets/img/background-new-york_ipad.jpg
NETWORK:
*
http://*
https://*
FALLBACK:
/index.php /statische-alternative.html
/formular.php /offline.html

Wie soll ich sonst offline durch eine Webseite navigieren können, wenn mir Dateien wie z.Bsp. Google Fonts oder jquery, die ich auf einer Folgeseite brauche, fehlen?

Aber vermutlich haben wir beide unterschiedliche Anwendungs-Szenarien im Kopf ... Analytics oder Like it funktionieren damit natürlich nicht big_smile - aber dafür gibt's ja im Manifest die Sektion Network wink .

faglork · 15. September 2015 18:32

cyberman schrieb:

faglork schrieb:
Die kannst du doch nicht in einen Appcache laden.
Kann ich doch ;p.
http://www.webdesign-podcast.de/2014/01/27/html5-appcache-offline-manifest/ schrieb:

//fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,600,700

Das zieht AFAIK einen Aufruf von
http://clients1.google.com/ocsp
nach sich ... inwieweit der benötig wird, sei jetzt mal dahingestellt.

Letztlich müsste man mal sowas wie ne "best practise" Anleitung für cmsms zusammenstellen. Das Pregefetche für den Desktop, das Webgeappe für die Mobilen. Oder so.

Aber: Wie funktioniert das Webgeappe denn in der Praxis? Ich meine jetzt keine Trivialseiten mit 5 Inhaltseiten der einfachsten Art ... wenn ich hier im Forum nach diesbezüglichen Begriffen suche, kommt nix raus. Also setzt das wohl *niemand* hier ein.

Warum? Das muss doch seine Gründe haben? Wenn es dafür ne brauchbare Anleitung gäbe, dann wär das doch ein dickes Plus? Das man sogar den Kunden anbieten könnte?

Hast du sowas im Einsatz? Kann man das mal sehen? Wie hoch ist denn der Aufwand? Ich wäre da sehr interessiert, das wäre für einige meiner Kunden ziemlich schick. Aber da muss halt dann auch alles funktionieren. News müssen aktuell bleiben, Suchfunktion muss laufen, Datenbanken müssen abfragbar sein, etc. Ich fürchte das ist alles andere als trivial.

Also bevor ich das preloading von wichtigen Elementen "alternativ ggf. auch über einen Appcache erledige" habe ich das mit ein paar Zeilen pre-irgendwas erledigt.

Nachtrag: ich hab mir jetzt mal
http://www.webdesign-podcast.de/2014/01 … -manifest/
durchgelesen und es ist wohl so wie ich vermutet habe: Für Webseiten einfachster Machart ok, aber ansonsten ... alles was dort als "nicht ganz so ideal" bzw. "Problem-Beispiel" bezeichnet wird ist Standard bei den meisten Websites. Zumindest bei mir.

Ich wäre dennoch sehr interessiert ... da gab es mal ein holländisches Projekt, mit dem man eine CMSMS-Website in eine Webapp verwandeln konnte, habe aber leider den Namen vergessen und die Doku war nur holländisch ... aber wir haben ja Janl ;-)

EDIT: http://forum.cmsmadesimple.org/viewtopi … =4&t=70109
bzw. http://pmkmedia.nl/news/5/88/CMSMS-Webapp-Sjabloon-2-0

Servus,
Alex

Beitrag geändert von faglork (15. September 2015 18:40)

Forum für CMS/made simple

#1 02. September 2015 23:56

Google pagespeed und caching

#2 02. September 2015 08:00

Re: Google pagespeed und caching

#3 02. September 2015 11:25

Re: Google pagespeed und caching

#4 02. September 2015 12:11

Re: Google pagespeed und caching

#5 02. September 2015 16:32

Re: Google pagespeed und caching

#6 03. September 2015 23:33

Re: Google pagespeed und caching

#7 03. September 2015 10:39

Re: Google pagespeed und caching

#8 03. September 2015 11:17

Re: Google pagespeed und caching

#9 11. September 2015 17:18

Re: Google pagespeed und caching

#10 14. September 2015 18:07

Re: Google pagespeed und caching

#11 14. September 2015 20:36

Re: Google pagespeed und caching

#12 14. September 2015 20:39

Re: Google pagespeed und caching

#13 14. September 2015 21:50

Re: Google pagespeed und caching

#14 15. September 2015 22:08

Re: Google pagespeed und caching

#15 15. September 2015 22:19

Re: Google pagespeed und caching

#16 15. September 2015 22:34

Re: Google pagespeed und caching

#17 15. September 2015 23:17

Re: Google pagespeed und caching

#18 15. September 2015 23:37

Re: Google pagespeed und caching

#19 15. September 2015 00:15

Re: Google pagespeed und caching

#20 15. September 2015 00:24

Re: Google pagespeed und caching

#21 15. September 2015 00:52

Re: Google pagespeed und caching

#22 15. September 2015 09:30

Re: Google pagespeed und caching

#23 15. September 2015 17:05

Re: Google pagespeed und caching

#24 15. September 2015 17:50

Re: Google pagespeed und caching

#25 15. September 2015 18:32

Re: Google pagespeed und caching

Fußzeile des Forums