Google drängt Webmaster zur Eile (Seite 3)

Raptor schrieb:

joerg schrieb:

Apache 2 müsste ich haben wenn ich das richtig sehe aber die Lösung über die htaccess kenne ich nicht!

Kennst du das?

Ach ja, falls es dazu eine bessere Lösung gibt, würd\' ich das gerne wissen.

Auch wenn der Raptor manchmal seine Zähne zeigt, der Flo kann was. Ist ein sehr schönes Beispiel danke, werde auch einen Link drauf setzen.

Ich hätte da noch ein Beispiel für HTML, XML, CSS und JavaScript , wobei ich die Qualität der Seite mangels Erfahrung nicht beurteilen kann:
Schnellere Webseiten und höhere Conversion durch Komprimierung

hansen

hansen schrieb:

Ich hätte da noch ein Beispiel für HTML, XML, CSS und JavaScript , wobei ich die Qualität der Seite mangels Erfahrung nicht beurteilen kann:
Schnellere Webseiten und höhere Conversion durch Komprimierung

Das finde ich jetzt nicht gerade ein gutes Beispiel. Da wird der User-Agent geprüft, doch müsste man das Accept-Encoding prüfen, weil das so manchmal zu unerwünschten Ergebnissen kommen kann.
Könnte man vielleicht entsprechend überarbeiten.
Ãœbrigens funktioniert mein Beispiel bei HTML, CSS, etc. genauso.

joerg schrieb:

Das Problem ist das Google es als Bewertungskriterium heranzieht! Bei den anderen Suchmaschinen weiss ich nicht ob die das werten wollen!

Bisher noch nicht (außer bei Timeouts). Siehe dazu auch:

www.selbstaendig-im-netz.de/2009/12/08/google/google-im-geschwindigkeitsrausch-4-speed-neuerungen-bei-google/

joerg schrieb:

Erst mal ist sowieso die Frage zu klären inwieweit Seitenreport im Stande es die Gzip Komprimierung zu prüfen.

Warum sollte Seitenreport es nicht sein?

raptor schrieb:

Moment mal, ich hab\' nicht wirklich das Gefühl, dass Seitenreport gzip erkennt..

Jedenfalls wird es wie richtig von Flo erkannt (noch) nicht ausgegeben. Die komplette Erkennung dagegen ist schon integriert, die Daten sind derzeit aber nicht öffentlich (und fließen auch nicht ins Ranking ein). (Ein Punkt, den ich nun wohl aus den nur für Premium-Mitglieder angedachten Punkten herausnehmen muss, Mist! :wink.

Zur GZIP Komprimierung:
Die GZIP Komprimierung sollte nicht erst zur Laufzeit erstellt werden, da sie den Server unnötig stark belastet (bei hohen Besucherzahlen kann sich da der GZIP Zeitgewinn wieder komplett auflösen durch den Zeitverlust der serverseitigen Komprimierung).
Sinnvoller ist es, die Dateien vorab zu komprimieren (als eigene .gz Dateien) und in der .htaccess die entsprechenden Anweisungen einzufügen:


# Erstellen der GZIP Datei (.gz) per SSH (Konsole)
cd /www/htdocs/[domain]/css # Wechseln in das Domain-Verzeichnis auf dem Server (Domain und Verz. css entsprechend anpassen)
gzip format.css > format.css.gz # GZIP Datei erstellen



# .htaccess
RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
RewriteRule css/format.css css/format.css.gz [L]

Eine weitere bedeutende Geschwindigkeitsoptimierung kann man über den Browser-Cache erzielen, wenn man die Caching-Dauer von Bildern, CSS und JS hochsetzt (Vorsicht: wenn man z.B. die JS jeden Tag ändert, darf die Caching-Dauer natürlich nicht so hoch liegen!):


# .htaccess
<FilesMatch "\\.(ico|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
</FilesMatch>


seitenreport schrieb:

Die GZIP Komprimierung sollte nicht erst zur Laufzeit erstellt werden, da sie den Server unnötig stark belastet (bei hohen Besucherzahlen kann sich da der GZIP Zeitgewinn wieder komplett auflösen durch den Zeitverlust der serverseitigen Komprimierung).

Aus diesem (und vielleicht auch anderem) Grund ist es bei einigen Hostern (noch) nicht möglich GZIP zu nutzen, z.B Domainfactory - wo die Techniker es strikt ablehnen.

Gérard

gerard schrieb:


Aus diesem (und vielleicht auch anderem) Grund ist es bei einigen Hostern (noch) nicht möglich GZIP zu nutzen, z.B Domainfactory - wo die Techniker es strikt ablehnen.

Gérard

Ich nutze aber bei domainfactory die gzip Komprimierung. Da ich noch nicht allzuviele Besucher habe, brauche ich wegen der Severlast noch keine Bedenken haben.

Robert

RobbyMe schrieb:

Ich nutze aber bei domainfactory die gzip Komprimierung. Da ich noch nicht allzuviele Besucher habe, brauche ich wegen der Severlast noch keine Bedenken haben.

Dann verrat mir mal wie du das machst. Der Support behauptet, dass es nicht geht.

Gérard

gerard schrieb:

RobbyMe schrieb:

Ich nutze aber bei domainfactory die gzip Komprimierung. Da ich noch nicht allzuviele Besucher habe, brauche ich wegen der Severlast noch keine Bedenken haben.

Dann verrat mir mal wie du das machst. Der Support behauptet, dass es nicht geht.

Gérard

Hallo Gerad,

vorneweg ich bin kein Programmierer und PHP-Spezialist.
Meine Seite ist mit Joomla unterwegs und vor ca. 2 Wochen prüfte ich, ob die Gzip Komprimierung durch das Backend läuft. Der Test viel gut aus.

Vor ca. 3 Tagen habe ich Smartoptimizer, der mit unter auch gzip komprimiert installiert. Die Anleitung und der Link zum Download der Dateien findest Du unter folgendem Link.

www.kubik-rubik.de/joomla-hilfe/gzip-komprimierung-mit-smartoptimizer-bei-joomla

RobbyMe schrieb:

Vor ca. 3 Tagen habe ich Smartoptimizer, der mit unter auch gzip komprimiert installiert. Die Anleitung und der Link zum Download der Dateien findest Du unter folgendem Link.

www.kubik-rubik.de/joomla-hilfe/gzip-komprimierung-mit-smartoptimizer-bei-joomla

Alles klar - via PHP geht es natürlich, aber via .htaccess geht es nicht, da dazu das Apache Modul installiert sein muss, was aber bei domainfacory nicht ist und nicht sein soll (mal sehen wie lange noch). Ich wollte aus meinen statischen Seiten nicht unbedingt PHP-Seiten machen.

Gérard

Funktion von SmartO
1. führt die unter joomla schlecht gemachten header() aus in dem er nicht jedesmal alles übers netz verschickt.(stichpunkt browserchache)
2. trimmt javascript und css und legt diese als cache auf dem Server an.

und so weiter.