Komprimierung, Caching usw.

Sniqi · 3. Februar 2012

Tagchen,

ich bräuchte etwas Unterstützung bei der Optimierung meine Webseite. Dazu benutze ich das Plugin "Page Speed". Das nennt mir ein paar Optimierungen die ich gerne umsetzen würde, wo ich aber - auch nach lesen von Tutorials - keine genau Ahnung habe wie das ganze Funktioniert. CMS ist Wordpress. Hier zeige ich euch die genannten Optimierungen:

-Komprimierung
-Browser-Caching
-Java-Scirpt später parsen

Ich weis von jedem was es ist, aber eben nicht wie es angewendet wird.
Ich bedanke mich für jede Hilfe.

mfg

andy_0 · 3. Februar 2012

Komprimierung geht auf die CPU. Würde ich nur aktivieren, wenn du Traffic sparen musst. Das Caching des Browsers kannst du gar nicht verhindern. Dazu können Websysteme aber teilweise Content auf der HDD des Servers oder in einer SQL Datenbank cachen. Das reduziert den Workload der CPU, ist also für hoch frequentierte Webseiten sehr gut, dafür werden Änderungen an den Seiten evtl. erst Minuten/Stunden später dargestellt (da der Cache noch nicht aktualisiert wurde).

Das mit Javascript sagt mehr jetzt nichts direkt. Vermutlich einfach eine Funktion, wo der Javascript Code erst nach Aufbau der eigentlichen Webseite gestartet wird.

Daaron · 3. Februar 2012

andy_0 schrieb:
Komprimierung geht auf die CPU. Würde ich nur aktivieren, wenn du Traffic sparen musst.

Denkst du wirklich, so nem Webserver tut es irgend etwas, ob er die Seiten jetzt gzip-komprimiert rausschickt oder unkomprimiert? Einige clevere CMS bieten die Inhalte eh vorkomprimiert an und komprimieren nicht erst, wenn eine Anfrage kommt.
Wenn du serverseitige Kompression nicht aktiviert hast kostet das Page Speed Ranking, was sich wiederum negativ aufs Ranking auswirkt.

Dein Webserver braucht dazu ein passendes Kompressionsmodul und es muss aktiv sein. Die Kompression wird (bei Apache) über die .htaccess im Detail für gewisse Dateien/Dateitypen aktiviert.

Das Caching des Browsers kannst du gar nicht verhindern. Dazu können Websysteme aber teilweise Content auf der HDD des Servers oder in einer SQL Datenbank cachen. Das reduziert den Workload der CPU, ist also für hoch frequentierte Webseiten sehr gut, dafür werden Änderungen an den Seiten evtl. erst Minuten/Stunden später dargestellt (da der Cache noch nicht aktualisiert wurde).

Darum gehts auch nicht (direkt).
Browser cachen, ja... aber sie cachen erst dann KORREKT, wenn der Server die korrekten Cache Validator - Werte sowie die Verfallszeiten im Header schickt. Der Trick ist, eben genau diese Cache-Einstellungen korrekt zu übertragen. Auch das steht in der .htaccess (beim Apache)

SQL-Anfragen werden vom SQL-Server eh immer gecached. Ob Anfragen an dynamische Seiten (bzw. das HTML-Ergebnis der Anfragen) jetzt serverseitig gecached werden hängt vom Programm ab. Anständige CMS sollten sowas können.

Das mit Javascript sagt mehr jetzt nichts direkt. Vermutlich einfach eine Funktion, wo der Javascript Code erst nach Aufbau der eigentlichen Webseite gestartet wird.

Nicht nur. Es geht auch darum, wo in der Seite Scripts (egal ob Inline oder verlinkt) eingebunden werden. Es macht Sinn, gewisse Scripte nicht im <head> sondern am Ende vom <body> einzubinden. Gibt bei Endkunden mit langsamen Geräten (z.B. Smartphones) ein etwas schnelleres Rendering der Seite.

andy_0 · 3. Februar 2012

@ Daaron
Bei großen Webseiten kann es durchaus einen nennenswerten Unterschied machen. Bei hunderten Zugriffen die Sekunde überlegt man es sich schon, ob man den Inhalt komprimiert. Ich denke außerdem nicht, das eine Webseite ohne Kompression langsamer sein muss, als eine mit. Das hängt sehr stark vom Inhalt (vor allem der Kompressionsfähigkeit) und der Bandbreite ab.

Das Datenbanken caching Features anwenden ist klar. Das jeweilige System (CMS, Forum, ...) kann jedoch noch einmal extra Daten in der Datenbank cachen. Dies kann jedoch auch deaktiviert werden. Natürlich ändert dies nichts an der Funktionalität der jeweiligen Datenbank.

Stimmt, die jeweiligen Webseiten müssen natürlich einen Header führen, der angibt wie lange die Datei gecached werden soll/darf.

Daaron · 3. Februar 2012

Ohne Kompression isses sicher langsamer bzw. einfach deutlich mehr Traffic. HTML, CSS und JS eigenen sich wunderbar für Kompression, vor allem die Teile, die nicht bereits über irgend n Kompressor (YUI für JS, Tidy für HTML,...) entsprechend platzsparend geschrieben wurden. Wenn man wirklich so viele Hits hat, dass die Kompression pro Hit einen zu großen Einfluss auf die Serverlast hat, dann kann man seine Skripte durchaus auch so schreiben, dass zumindest Elemente, die sich nicht oder nur selten ändern, bereits als komprimierte Version vorliegen. Der Webserver kümmert sich dann darum, dass wahlweise die html/css/js... oder deren gz-Äquivalent verschickt wird. Diese Herangehensweise ist sogar schneller als die fertig erstellen Seiten in der Datenbank zu cachen. Statt "suche nach Cache -> lies Cache aus DB -> parse Cache" machste einfach "suche nach Cache -> parse cache.html"
Und wie schon gesagt: gz-Kompression ist ein sehr wichtiger Punkt für PageSpeed, und so wie ich die Beschreibungen verstehe geht PS eben zu einem gewissen Grad in die Suchstatistik bei Google mit ein. Abgeschaltete Kompression kostet durchaus mal 15 Punkte oder sowas.

P.S.: The page ComputerBase got an overall Page Speed Score of 77 (out of 100). Und das, obwohl Kompression aktiv ist. Hier sind die nicht genutzten CSS Sprites und die schlecht konfigurierten Werbeanbieter schuld.

ice-breaker · 3. Februar 2012

Für mobile Endgeräte über UMTS ist Kompression auch ein sehr wichtiger Punkt, umso weniger übertragen werden muss umso weniger stört die hohe Latenz durch die Funkübertragung.

Also auch bei hunderten Zugriffen die Sekunde sollte man noch genug CPU-Leistung für gzip übrig haben, es sind ja immer nur wenige KB die komprimeirt werden und gzip1 ist ja vollkommen ausreichend, natürlich ist gzip9 kleiner, aber der Unterschied ist so marginal...

gzip-Compression Benchmark auf einem i7-3930k: leider ist das Kompressionslevel nicht angegeben, aber 200MB die Sekunde sind durchaus nicht zu verachten, das muss man erstmal durch seine Leitung durchbekommen.

Suche

Komprimierung, Caching usw.

Sniqi

Lt. Junior Grade

andy_0

Admiral

Daaron

Fleet Admiral

andy_0

Admiral

Daaron

Fleet Admiral

ice-breaker

Commodore

Ähnliche Themen