mod_pagespeed

[daiv]

Hallo Forum,

hat einer von euch Erfahrungen mit mod_pagespeed gesammelt?

Bin über diesen Artikel

http://googledevelopers.blogspot.de/2012/10/make-web-faster-with-modpagespeed-now.html

darauf aufmerksam geworden. Bringt es etwas? Hat es irgendwelche Nachteile?

Vielen Dank

David

 

[unull]

Hallo Forum,

hat einer von euch Erfahrungen mit mod_pagespeed gesammelt?

Bin über diesen Artikel

http://googledevelopers.blogspot.de/2012/10/make-web-faster-with-modpagespeed-now.html

darauf aufmerksam geworden. Bringt es etwas? Hat es irgendwelche Nachteile?

Vorweg sei angemerkt, dass ich das Teil noch nicht ausprobiert habe.

Wenn Du dir die Liste der Filter mal ansiehst, dann wirst Du merken, dass jede vernuenftige Webseite das ganze sowieso schon tut. Assets (CSS/CoffeeScript etc.) wird ueblicherweise sowieso minified, Bilder sollten auch optimiert werden. Asset-Hosts mit einem anderen Hostnamen als die Anwendung (erlaubt paralleles Laden), ggf. mit gzip-Komprimierung, und sinnvollem Caching sind eigentlich State-Of-The-Art.

tl;dr

Das Modul ist nicht dark-magic, sondern versucht Best-Practices zu automatisieren. Ich halte es schlichtweg fuer ueberfluessig.

 

[SolarCatcher]

Wenn Du dir die Liste der Filter mal ansiehst, dann wirst Du merken, dass jede vernuenftige Webseite das ganze sowieso schon tut.

... "tun sollte", müsste es wohl korrekt heißen. Man braucht sich ja nur unter www.webpagetest.org einige größere Seiten anzuschauen. Dann sieht man, dass das Komprimieren von Bilddateien, ja manchmal nicht einmal das gzippen von HTML, CSS etc. standard ist, gleiches gilt fürs Minifizieren etc.

Schauen wir doch mal die Tests einiger größerer Firmen an (interessant ist v.a. der "Performance Review"), z.B.

• Daimler
• BMW
• Siemens
• ZDF
• ein bisschen besser Heise
• auch die IT'ler wie das OpenBSD Projekt komprimieren das HTML nicht

Webagenturen achten üblicherweise nicht auf sowas, weil es die allermeisten Kunden nicht nachfragen. Die meisten bekommen es nicht einmal mit.

Persönlich würde ich auch empfehlen, die Optimierungen manuell vorzunehmen, statt sie einem Modul anzuvertrauen. Für 99% der Seitenbetreiber dürfte sowas aber ein Segen sein und damit auch den Internetnutzern zugute kommen, besonders solchen, die nicht über Breitbandanschluss verfügen (z.B. Mobilgeräte).

 

[SolarCatcher]

Hab auch nochmal einen Test von freebsd.org angestoßen - der sieht nicht schlecht aus.

Beim nochmaligen Anschauen der o.g. Tests sträuben sich einem ja z.T. echt die Haare - Daimler, BMW und ZDF könnten je mehr als 500kB Datenübertragung einsparen, wenn Sie konsequent Javascripte und CSS gzippen würden... unglaublich! Also diese Seiten würden von mod_pagespeed vermutlich ganz gut profitieren!

 

[Azazyel]

Persönlich würde ich auch empfehlen, die Optimierungen manuell vorzunehmen, statt sie einem Modul anzuvertrauen.

Das mag für einen kleinen, handgeschriebenen und relativ statischen Webauftritt noch machbar sein.

Wie viele Mannjahre braucht man wohl für einen riesigen Webauftritt mit Komponenten aus diversen Quellen/Abteilungen/etc., um den

• existierenden Content einmalig und
• neuen Content fortlaufend

zu optimieren? Wer würde so ein Projekt finanzieren wollen?

Wie sieht es mit der riesigen Anzahl CMS in freier Wildbahn aus, die suboptimalen Output produzieren?
Welche realistische Chance hat ein Webmaster, sowas von Hand zu optimieren?

Das Modul ist nicht dark-magic, sondern versucht Best-Practices zu automatisieren. Ich halte es schlichtweg fuer ueberfluessig.

Das Modul ist brilliant. Als Gegenleistung für ein wenig Rechenleistung - und wir wissen alle, wie rotzbillig die inzwischen ist - spart man sich die manuelle Optimierung der ganzen existierenden und neu entstehenden Seiten.

Hinzu kommt: für alle weiteren möglichen Verbesserungen, die sich in Zusammenspiel mit neuen Technologien und Techniken ergeben, muss man mit mod_pagespeed nur ein Apache-Modul aktualisieren.
Bei der handoptimierten Variante bedeutet das jedesmal wieder viel manuellen Aufwand.

Die Diskussion erinnert mich ein bisschen an Diskussion

• manuelles Speichermanagement vs. Garbage Collection und
• handgeschriebener Assemblercode vs. Compiler

in der Vergangenheit.

 

[foobarflu]

azazyel: man könnte halt beim Upload/Deployment optimieren. Das ist ja statisch und braucht nicht zur Laufzeit gemacht zu werden. Aber ja, da müssten die Leute sowas wie ein System haben, um ihre Seiten zu deployen das technologisch fortschrittlicher ist als ein FTP-Client (-:

 

[Azazyel]

azazyel: man könnte halt beim Upload/Deployment optimieren. Das ist ja statisch und braucht nicht zur Laufzeit gemacht zu werden. Aber ja, da müssten die Leute sowas wie ein System haben, um ihre Seiten zu deployen das technologisch fortschrittlicher ist als ein FTP-Client (-:

Das funktioniert nur bei simplen, rein statischen Seiten. Komplexe Webauftritte haben das Hochladen-per-FTP-und-fertig-Stadium doch längst hinter sich gelassen. Zumal du für Optimierungen beim Upload jedes einzelne System anpassen müsstest, was in vielen Fällen überhaupt nicht möglich bzw. selbst bei Open Source unrealistisch ist (wer möchte schon seinen eigenen Fork pflegen), vom benötigten Aufwand (Zeit/Geld) dafür mal ganz zu schweigen.

Um nur drei Beispiele zu nennen, Funktionalität wie

• inline_images (Einbetten von kleinen Bildern ins HTML)
• combine_css (Zusammenfügen von mehreren CSS-Dateien zu einer einzigen)
• move_css_to_head (sämtliche CSS-Anweisungen im Header unterbringen)

kann man bei dynamischen Inhalten gar nicht beim Upload/Deployment machen

Der Witz an der Sache ist doch, dass man mod_pagespeed vorschaltet und alle Inhalte - statisch wie dynamisch - in den Genuss der Optimierungen kommen.

 

[unull]

Welche realistische Chance hat ein Webmaster, sowas von Hand zu optimieren?

Da muss bei einschlaegigen Frameworks auch nichts "von Hand" gemacht werden. Sprockets (Teil von Rails) macht das out-of-the-box schon groesstenteils.

Fuer den Rest machen das in der Firma eine Handvoll kleiner Skripte. Abgesehen davon, ist das Modul ohnehin nur fuer den Apache vorhanden.

 

[unull]

• inline_images (Einbetten von kleinen Bildern ins HTML)
• combine_css (Zusammenfügen von mehreren CSS-Dateien zu einer einzigen)
• move_css_to_head (sämtliche CSS-Anweisungen im Header unterbringen)

kann man bei dynamischen Inhalten gar nicht beim Upload/Deployment machen

Wieso nicht? Das muss man sogar beim Deployment erledigen, wenn man separate Asset-Hosts verwendet.

 

[Azazyel]

Da muss bei einschlaegigen Frameworks auch nichts "von Hand" gemacht werden. Sprockets (Teil von Rails) macht das out-of-the-box schon groesstenteils.

Damit löst du das Problem der Optimierung eines existierenden Webauftritts wie?
Gar nicht.

Von den Nachteilen von Ruby (on Rails) für komplexe, heterogene Umgebungen mal ganz zu schweigen (das wäre aber offtopic; wenn du darüber diskutieren möchtest, gerne in einem neuen Thread).

Fuer den Rest machen das in der Firma eine Handvoll kleiner Skripte.

Ich fürchte, jeder der obigen Webauftritte hat allein dafür mehr Admins als ihr in der Firma dafür Skripte.

Abgesehen davon, ist das Modul ohnehin nur fuer den Apache vorhanden.

Korrekt; aber erstens ist Apache der wohl am meisten eingesetze Reverse Proxy (und bei einem Webauftritt in der Größe kommt man kaum um einen herum) und zweitens hast du in deinem Posting als Alternative eine Reimplementierung in einer wenig verbreiteten Programmiersprache nahegelegt, was ein paar Zehnerpotenzen teurer sein dürfte.

Wieso nicht? Das muss man sogar beim Deployment erledigen, wenn man separate Asset-Hosts verwendet.

Was wiederum statische Inhalte impliziert, die man z.B. bei Portlets kaum hat. Es ist durchaus üblich, dass bei Portlets Inhalte mit eigenen CSS eingebunden werden - zur Laufzeit. Das kann man nicht mehr beim Deployment abhandeln.

 

[SolarCatcher]

Das mag für einen kleinen, handgeschriebenen und relativ statischen Webauftritt noch machbar sein.

Wie viele Mannjahre braucht man wohl für einen riesigen Webauftritt mit Komponenten aus diversen Quellen/Abteilungen/etc., um den

• existierenden Content einmalig und
• neuen Content fortlaufend

zu optimieren? Wer würde so ein Projekt finanzieren wollen?

Da gebe ich Dir recht - ich habe einfach für meine eigenen Projekte geantwortet und da ist der Content überschaubar und ich kann bei einzelnen Resourcen besser als mod_pagespeed beurteilen, wie damit umzugehen ist (z.B. darf Bild verlustbehaftet komprimiert werden, darf eine bestimmte Bilddatei in ein anderes Format umgewandelt werden usw.). Gerade auch um das browserseitige Caching zu verbessern, ist es hilfreich, wenn ich selbst beurteile, ob und wie oft sich eine Datei vermutlich verändert und wie ein entsprechender Expires-Header aussehen soll.

Aber generell: Ja, jeder mit einer größeren Seite oder nicht genügend Ahnung bzw. Kapazität sollte die Optimierung einfach einem Tool wie mod_pagespeed überlassen. Es kann eine imense Verbesserung bringen, ohne Mehraufwand für Webentwickler oder Server-Admins.

 

[lockdoc]

auch die IT'ler wie das OpenBSD Projekt komprimieren das HTML nicht

Weil das eben auch gegen SEO Kriterien verstossen wuerde (wenn man denn daran glaubt)