Hallo,
wäre es nicht schön, wenn webEdition die HTML/PHP Seiten komprimiert ausgeben würde?
Das sollte doch relativ "einfach" zu realisieren sein? Google würde das freuen
Gruß
Jan
Seiten Ausgabe komprimieren
Forumsregeln
Bitte achtet hier besonders darauf, nicht abzuschweifen.
Wir werden hier verstärkt moderieren und ggf. Dinge in andere Foren (Smalltalk etc.) auslagern.
Bitte achtet hier besonders darauf, nicht abzuschweifen.
Wir werden hier verstärkt moderieren und ggf. Dinge in andere Foren (Smalltalk etc.) auslagern.
Re: Seiten Ausgabe komprimieren
Hallo Jan,
Du kannst doch mit gzip und anderen serverseitigen Optimierungen schon einiges machen. Wo meinst Du sollte webEdition noch komprimieren?
Viele Grüße
Timo
Du kannst doch mit gzip und anderen serverseitigen Optimierungen schon einiges machen. Wo meinst Du sollte webEdition noch komprimieren?
Viele Grüße
Timo
webEdition Partner - https://www.blickfang-media.com
Ehemals im Vorstand des webEdition e.V.
Ehemals im Vorstand des webEdition e.V.
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Seiten Ausgabe komprimieren
Hey Timo,
In den geparsten Templates könnte man z.B. einiges an Whitespace raus schmeißen.
Grundsätzlich erachte ich das aber als nicht soooo wichtig. Viele Optimierungen können auch effizient durch den Webserver erfolgen (Stichwort mod_pagespeed).
Cheers,
Sascha
In den geparsten Templates könnte man z.B. einiges an Whitespace raus schmeißen.
Grundsätzlich erachte ich das aber als nicht soooo wichtig. Viele Optimierungen können auch effizient durch den Webserver erfolgen (Stichwort mod_pagespeed).
Cheers,
Sascha
Re: Seiten Ausgabe komprimieren
Hi Sascha,
bei statischen Seiten könnte man das ggf. sogar über einen Hook selber machen. Bei dynamischen Seiten wird das schon eher schwierig werden...
Das shrinken der geparsten Templates ist aber auch meiner Ansicht nach schon ein sehr feines Rädchen zur Optimierung des pageSpeeds und ich denke webEdition ist hier schon auf einem sehr guten Niveau.
Ciao
Timo
bei statischen Seiten könnte man das ggf. sogar über einen Hook selber machen. Bei dynamischen Seiten wird das schon eher schwierig werden...
Das shrinken der geparsten Templates ist aber auch meiner Ansicht nach schon ein sehr feines Rädchen zur Optimierung des pageSpeeds und ich denke webEdition ist hier schon auf einem sehr guten Niveau.
Ciao
Timo
webEdition Partner - https://www.blickfang-media.com
Ehemals im Vorstand des webEdition e.V.
Ehemals im Vorstand des webEdition e.V.
-
- Junior Member
- Beiträge: 9
- Registriert: Fr 5. Aug 2016, 11:41
Re: Seiten Ausgabe komprimieren
Hallo Jan,
Allerdings wirst du effektiv dann doch in die Hölle der output-buffering-Verschachtelung geraten.
Ich hatte das nämlich mit Modifikationen an php.ini und webEdition/we/include/we_showDocument.inc.php
auch schon mal probiert. Du musst den OB-Puffer dann quasi deaktivieren, damit gzip auch
wirklich den gesamten Output zum Gzippen übergeben bekommt. Ansonsten kommen dabei
in Kombination mit Apache gerne nicht-integre HTTP-Antworten zustande.
Außerdem macht PHP das sicher deutlich langsamer als der Apache es nativ gzippen/deflaten kann.
Weiterhin geht auch die TTFB (time to first byte) hoch, weil der ob_gzhandler erst dann loslegen kann
wenn er die komplette Seite vom PHP bekommen hat.
Fazit: Lass das lieber den Apache machen.
Grüße
JK
es gibt im Netz ja einiges an Tipps, wie man mittels ob_gzhandler o. ä. machen kann.QJan hat geschrieben:wäre es nicht schön, wenn webEdition die HTML/PHP Seiten komprimiert ausgeben würde?
Das sollte doch relativ "einfach" zu realisieren sein? Google würde das freuen
Allerdings wirst du effektiv dann doch in die Hölle der output-buffering-Verschachtelung geraten.
Ich hatte das nämlich mit Modifikationen an php.ini und webEdition/we/include/we_showDocument.inc.php
auch schon mal probiert. Du musst den OB-Puffer dann quasi deaktivieren, damit gzip auch
wirklich den gesamten Output zum Gzippen übergeben bekommt. Ansonsten kommen dabei
in Kombination mit Apache gerne nicht-integre HTTP-Antworten zustande.
Außerdem macht PHP das sicher deutlich langsamer als der Apache es nativ gzippen/deflaten kann.
Weiterhin geht auch die TTFB (time to first byte) hoch, weil der ob_gzhandler erst dann loslegen kann
wenn er die komplette Seite vom PHP bekommen hat.
Fazit: Lass das lieber den Apache machen.
Grüße
JK
Re: Seiten Ausgabe komprimieren
Exakt. Das ist eine Aufgabe die der Apache tun sollte, der kann auch gleich JS/CSS und einige Grafiken komprimieren.
Die paar whitespaces kosten dabei nix.
Ein ganz ehrlich gemeinter Tipp: wenn ihr mal optimieren wollt, dann schraubt die Zahl der JS-Libs und Teile der Grafiken zurück. Ich war jetzt grad wieder mit dem Handy/Laptop über Edge (mehr gab es nicht) unterwegs - wenn da dann erst mal 2MB JS Zeug für die erste Fancy-Box geladen werden muß, ist vielleicht die Google Pagespeed toll, aber mein Nutzererlebnis eher mangelhaft. Und solange auch der tolle Ausbau der Bahnstrecken nicht besser ist, macht da auch das surfen auf solchen Seiten keinen Spaß.
Was mir mittlerweile sehr missfällt, daß keiner sich mehr den Gesamt-Footprint der Seite anschaut. Dank der tollen Werbung von Kabel-Deutschland >100MBit daheim ist mein Internet daheim abends mittlerweile mit Edge vergleichbar - und wie ich gehört habe ist das in LU/MA noch schlimmer.
Die paar whitespaces kosten dabei nix.
Ein ganz ehrlich gemeinter Tipp: wenn ihr mal optimieren wollt, dann schraubt die Zahl der JS-Libs und Teile der Grafiken zurück. Ich war jetzt grad wieder mit dem Handy/Laptop über Edge (mehr gab es nicht) unterwegs - wenn da dann erst mal 2MB JS Zeug für die erste Fancy-Box geladen werden muß, ist vielleicht die Google Pagespeed toll, aber mein Nutzererlebnis eher mangelhaft. Und solange auch der tolle Ausbau der Bahnstrecken nicht besser ist, macht da auch das surfen auf solchen Seiten keinen Spaß.
Was mir mittlerweile sehr missfällt, daß keiner sich mehr den Gesamt-Footprint der Seite anschaut. Dank der tollen Werbung von Kabel-Deutschland >100MBit daheim ist mein Internet daheim abends mittlerweile mit Edge vergleichbar - und wie ich gehört habe ist das in LU/MA noch schlimmer.
webEdition-Kern-Entwickler
-
- Junior Member
- Beiträge: 27
- Registriert: Mo 10. Okt 2016, 12:59
Re: Seiten Ausgabe komprimieren
Ich habe das neulich folgendermaßen gelöst:
- Der Hook weCustomHook_save behandelt CSS- (nach der LESS-Verarbeitung) und JS-Dateien beim Speichern.
- Sie werden dann 1-malig gzip-komprimiert und das als dateiname.ext.gz neben der Originaldatei dateiname.ext auf der WebServer-Festplatte abgelegt.
- Der Apache wiederum hat Rewrite-Regeln bekommen, dass er, wenn eine dateiname.ext.gz neben dateiname.ext existiert und der Client signalisiert hat, dass er gzip akzeptiert, bevorzugt die gz-Datei mit veränderten HTTP-Response-Headern ausspielen soll.
- So entsteht der ganze Komprimierungsaufwand für die CPU nur 1x. Vor allem bei den Dateien, die sich nicht häufig oder dynamisch ändern, aber bei jedem Website-Besuch schnell gebraucht werden, JS und CSS.
- Der Hook weCustomHook_delete löscht die .gz-Dateien für CSS und JS natürlich auch wieder mit von der Festplatte.
Code: Alles auswählen
<VirtualHost *:80>
(…)
<DirectoryMatch "/assets/">
<IfModule mod_rewrite.c>
<IfModule mod_headers.c>
RewriteEngine On
# Serve some files gzip-compressed if they already co-exist compressed
# beside the original and and the client accepts gzip.
# This reduces traffic as well as server load since it doesn't need
# mod_deflate to compress every file again on every request
# .css files
RewriteCond "%{HTTP:Accept-encoding}" gzip
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
# .js files
RewriteCond "%{HTTP:Accept-encoding}" gzip
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch "\.(css|js)\.gz$">
# Serve correct encoding type.
Header append Content-Encoding gzip
# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
</IfModule>
</DirectoryMatch>
</VirtualHost>
Re: Seiten Ausgabe komprimieren
Kannst du so machen, bringt dir bei dyn. Dokumenten gar nix.
http/2 ist von sich aus komprimiert und ssl verschlüsselt. Viele Sachen hier sind dann eh irrelevant (whitespace/Namensoptimierungen - alles totaler Unsinn). Sinnvoller wäre es das Protokoll mehr zu pushen und die Provider dazu zu bringen es anzubieten.
http/2 ist von sich aus komprimiert und ssl verschlüsselt. Viele Sachen hier sind dann eh irrelevant (whitespace/Namensoptimierungen - alles totaler Unsinn). Sinnvoller wäre es das Protokoll mehr zu pushen und die Provider dazu zu bringen es anzubieten.
webEdition-Kern-Entwickler
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Seiten Ausgabe komprimieren
@JK: Interessanter Ansatz. Danke für's posten.
@Marc: Ich denke bei der Lösung geht es primär um die JS & CSS Dateien. Die ändern sich nicht so oft und für gewisse Use Cases / Setups wird das wohl auch noch einige Zeit Sinn machen.
@Marc: Ich denke bei der Lösung geht es primär um die JS & CSS Dateien. Die ändern sich nicht so oft und für gewisse Use Cases / Setups wird das wohl auch noch einige Zeit Sinn machen.
Re: Seiten Ausgabe komprimieren
@Sascha: auch bei JS/CSS sollte man eigentlich nicht komprimieren. Bei CSS kann man teilweise noch streiten weil hier die Anzeige davon abhängt und man bei nicht zusammengefaßten CSS mehrere Requests benötigt. wichtiger wäre es manche CSS mal Inhaltlich zu hinterfragen. Es wird halt vielfach einfach immer mehr css/js auf die Seiten gepackt und die Gesamtgröße davon ist dann >1MB, wenn dann noch webfonts und Grafiken dazu kommen...
Auf der anderen Seite wird der Cache ausgehebelt für die ganzen sich nicht ändernden Teile, nur weil evtl. die Hintergrundfarbe getauscht wurde... Da ist es vielleicht bei dem einmaligen Surfer etwas schneller, der so blöd war wieder zu kommen ärgert sich über den großen Download....
Auf der anderen Seite wird der Cache ausgehebelt für die ganzen sich nicht ändernden Teile, nur weil evtl. die Hintergrundfarbe getauscht wurde... Da ist es vielleicht bei dem einmaligen Surfer etwas schneller, der so blöd war wieder zu kommen ärgert sich über den großen Download....
webEdition-Kern-Entwickler
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast