Google pagespeed und caching

Andynium · 15. September 2015 19:15

Hab das Beispiel auch nur fix (=ungetestet) von der Podcast Seite genommen.

Ich kann mich dazu auch erinnern, dass Mr. P dies in seinem Projekt mit verarbeitet hatte. Und da sollte es schon Hand und Fuß haben.

Sicherlich haben beide Techniken ihre Berechtigungen.

Nein, ein Beispiel habe ich gerade nicht. Ist ja auch insgesamt ein bißchen tricky. Hatte es mal hier im Forum eingebaut, ist aber mittlerweile wieder raus.

Und bezüglich deiner einschlägigen Suche - keine Ahnung, warum das so ist, aber nur wenige sind bereit, ihr Wissen und Tricks hier zu teilen (nein, ich meine NICHT dich, Alex big_smile ), wenn ich mir das fast verwaiste HowTo Board anschaue.

Praktisch stelle ich es mir so vor, Rolfs Anleitung für die .appcache Liste zu adaptieren. Die Seite hält sich ja dann quasi selbst aktuell. Sobald da ein neuer Eintrag darin auftaucht, wird neu geladen. Dann die Seite noch durch Verzeichnislisten ergänzen, deren Inhalte auf der Webseite angezeigt werden sollen. Zudem lassen sich ja explizit auch Seiten definieren, die immer live geladen werden (Suche/Datenbankabfragen)

Von der Webapp Sjabloon gibt es ja mittlerweile 4 Versionen, lässt sich mit Google Translator und der Übersetzung von @Chandra einigermaßen gut lesen.

faglork · 15. September 2015 20:20

Hab noch ne schöne Seite zum Thema "Optimierung" gefunden:

https://developers.google.com/web/fundamentals/

Da steht eigentlich alles was man so braucht ...

und speziell zum Thema prefetch etc.:

https://docs.google.com/presentation/d/ … ide=id.p19

EDIT: recommended reading!! http://alistapart.com/article/applicati … -douchebag

Money Quote: "Do you have two sets of design images? Is one of them much smaller and lighter for people viewing on mobile devices? Do you use media queries to decide which of these to display? Well, ApplicationCache hates you and your family." lol

Servus,
Alex

Beitrag geändert von faglork (15. September 2015 21:47)

Andynium · 17. September 2015 16:02

Janl schrieb:

Kompression möchte ich ohne CMSMS klar haben.

Dazu hatte ich letztens einen interessanten Twitter-Beitrag in meinem Feed (kann ihn gerade nur nicht finden), der da meinte, dass sich die browserseitige Skalierung durchaus sinnvoll nutzen lassen würde.

Sinngemäß so, dass es sich unter Umständen lohnt, Bilder in einer hohen Auflösung sehr stark zu komprimieren - also, wenn das Zielbild 250 x 200 px groß sein soll, das Primär-Bild mit einer Größe von 1000 x 800 px auf 5-10% zu komprimieren und zu speichern, und dann den Browser auf die Zielgröße runterrechnen zu lassen. Würde wohl optisch keinen Unterschied machen bzw. zum Teil noch besser rüber kommen und zudem performanceseitig Punkte bringen roll ...

Hatte bislang jedoch noch keine Zeit, dies mal zu überprüfen.

faglork · 17. September 2015 16:15

cyberman schrieb:

Janl schrieb:
Kompression möchte ich ohne CMSMS klar haben.
Dazu hatte ich letztens einen interessanten Twitter-Beitrag in meinem Feed (kann ihn gerade nur nicht finden), der da meinte, dass sich die browserseitige Skalierung durchaus sinnvoll nutzen lassen würde.
Sinngemäß so, dass es sich unter Umständen lohnt, Bilder in einer hohen Auflösung sehr stark zu komprimieren - also, wenn das Zielbild 250 x 200 px groß sein soll, das Primär-Bild mit einer Größe von 1000 x 800 px auf 5-10% zu komprimieren und zu speichern, und dann den Browser auf die Zielgröße runterrechnen zu lassen. Würde wohl optisch keinen Unterschied machen bzw. zum Teil noch besser rüber kommen und zudem performanceseitig Punkte bringen ...
Hatte bislang jedoch noch keine Zeit, dies mal zu überprüfen.

Das funktioniert sogar sehr gut, auch bei größeren Bildmaßen. Siehe http://tinyurl.com/ozfry4g
Das Bild im Hintergrund (2000x1500) ist in Photoshop auf 0% Qualität herunterkomprimiert. 0!! Das ergibt 126 kb. Wird in meinem Browserfenster auf knapp 1600x1200 skaliert. Sieht IMO gut aus.
(für mobile wird natürlich was anderes ausgegeben)

Servus,
Alex

Janl · 17. September 2015 16:46

Hätte ich schon erwartet.

Korrigieren von Bilder mache ich auf höchste Resolution, erst dann verkleinern für eine Webseite.
Wenn ich etwas Zeit habe mache ich ein Beispiel.

MfG
Jan

Janl · 18. September 2015 23:02

Habe mal Zeit genommen.
In Gimp geht Kompression 0 gar nicht, alles verpixelt.

Was geht ist:
bei gute Qualität Foto,
Qualität 40 und Optimieren, Progressiv, Vorschau speichern alle Häckchen geben
Zwischenschritte "Höchste Qualität" und DCT-Methode - Ganz Zahlen
Größe schrumpft von 2,5 Mb bei 100% bis 195 Kb bei 40% (1800/1200px)

Bei unscharfe Hintergrundbilder kann 30 und kleinste Dateigröße gewählt werden,
schrumpft von 1,3 Mb nach 70 Kb (1950 x 1130 Px)
jetzt mal sehen was Google davon hält.

Du hast recht Alex, als Profi steckt man Zeit in solche Tuning, aber es ist ebenso eine Sache
des Geldes, wer nur wenig bezahlen will, kann das alles nicht erwarten.

MfG
Jan

Andynium · 24. September 2015 11:03

cyberman schrieb:

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" ...

Vielleicht findet sich auch "jemand", der das Modul für TinyPNG anpasst tongue ...

Janl · 24. September 2015 12:47

Ich habe jetzt mit immo-cz.info mal alle gute Rat gefolgt.
Neue .htaccess, komprimiert nach Google-Vorlagen.
Ladezeit 21 Millisekunden.

Es bleibt aber etwas nervig dass gerade diese Gallery die so gut responsive ist, sich nur im head laden lässt aber damit kann ich leben.

MfG
Jan

@Cyberman, schaue mich mal tinyPNG in Detail an, ist vielversprechend.

faglork · 24. September 2015 14:33

Janl schrieb:

Es bleibt aber etwas nervig dass gerade diese Gallery die so gut responsive ist, sich nur im head laden lässt aber damit kann ich leben.

Naja, solange die Initialisierung direkt in der Seite stattfindet kann das ja nicht funktionieren: die Scripte werden ja erst nachher geladen (wenn diese vor dem </body> deklariert sind).

Die $(document).ready(function() ... Anweisung muss natürlich ebenfalls ans Ende, *nach* dem Aufruf der Scripte.
Sonst wird das ausgeführt obwohl das script noch gar nicht da ist.

Falls du das schon probiert hast, sorry, ignorier den Post ...

Servus,
Alex

Beitrag geändert von faglork (24. September 2015 14:33)

Andynium · 28. September 2015 00:38

Janl schrieb:

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

Pfff, gerade wieder etwas "überraschendes" zu diesem Thema entdeckt - damit die CSS asynchron geladen wird und das Laden der Seite nicht blockiert, einfach den Link auf die CSS in den <body> verschieben

http://codepen.io/Tigt/blog/async-css-w … javascript

Kaum zu glauben, dass es so einfach geht ops ...

faglork · 28. September 2015 10:08

cyberman schrieb:

Janl schrieb:
Weiteres Punkt ist "above the fold" CSS kann man nicht laden "below the fold", doch.
Pfff, gerade wieder etwas "überraschendes" zu diesem Thema entdeckt - damit die CSS asynchron geladen wird und das Laden der Seite nicht blockiert, einfach den Link auf die CSS in den <body> verschieben

http://codepen.io/Tigt/blog/async-css-w … javascript
Kaum zu glauben, dass es so einfach geht ...

Was aber nur Sinn ergibt wen das "critical css" inline im HEAD vorliegt.
Und man kann das CSS als "subressource" deklarieren.

Servus,
Alex

Andynium · 28. September 2015 14:07

Hmm, kann ich aus dem Beispiel aber so nicht entnehmen

Hier klicken, um den Code zum Kopieren zu markieren

<head>
  <!--[if IE]>
    <link rel="stylesheet" href="style.css"> <!-- blocking, but what else can ya do? -->
  <![endif]-->
</head>
<body>
    <!--[if !IE]> -->
        <link rel="stylesheet" href="style.css" lazyload>
  <!-- <![endif]-->
</body>

faglork · 28. September 2015 14:46

cyberman schrieb:

Hmm, kann ich aus dem Beispiel aber so nicht entnehmen

Hier klicken, um den Code zum Kopieren zu markieren

<head>
  <!--[if IE]>
    <link rel="stylesheet" href="style.css"> <!-- blocking, but what else can ya do? -->
  <![endif]-->
</head>
<body>
    <!--[if !IE]> -->
        <link rel="stylesheet" href="style.css" lazyload>
  <!-- <![endif]-->
</body>

google pagespeed ... die Diskussion hatten wir doch erst.

Servus,
Alex

Andynium · 29. September 2015 08:57

Hmm, möglicherweise habe ich da etwas falsch verstanden (oder verpasst) roll ...

Forum für CMS/made simple

#26 15. September 2015 19:15

Re: Google pagespeed und caching

#27 15. September 2015 20:20

Re: Google pagespeed und caching

#28 17. September 2015 16:02

Re: Google pagespeed und caching

#29 17. September 2015 16:15

Re: Google pagespeed und caching

#30 17. September 2015 16:46

Re: Google pagespeed und caching

#31 18. September 2015 23:02

Re: Google pagespeed und caching

#32 24. September 2015 11:03

Re: Google pagespeed und caching

#33 24. September 2015 12:47

Re: Google pagespeed und caching

#34 24. September 2015 14:33

Re: Google pagespeed und caching

#35 28. September 2015 00:38

Re: Google pagespeed und caching

#36 28. September 2015 10:08

Re: Google pagespeed und caching

#37 28. September 2015 14:07

Re: Google pagespeed und caching

#38 28. September 2015 14:46

Re: Google pagespeed und caching

#39 29. September 2015 08:57

Re: Google pagespeed und caching

Fußzeile des Forums