Seite 1 von 1

Seiten Ausgabe komprimieren

Verfasst: Di 23. Aug 2016, 13:39
von QJan
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

Re: Seiten Ausgabe komprimieren

Verfasst: Di 23. Aug 2016, 13:52
von blickfang
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

Re: Seiten Ausgabe komprimieren

Verfasst: Di 23. Aug 2016, 14:30
von WBTMagnum
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

Re: Seiten Ausgabe komprimieren

Verfasst: Di 23. Aug 2016, 14:57
von blickfang
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

Re: Seiten Ausgabe komprimieren

Verfasst: Mi 24. Aug 2016, 10:59
von jpunktkpunkt
Hallo Jan,
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 ;-)
es gibt im Netz ja einiges an Tipps, wie man mittels ob_gzhandler o. ä. machen kann.

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

Verfasst: Mo 29. Aug 2016, 10:56
von mokraemer
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.

Re: Seiten Ausgabe komprimieren

Verfasst: Di 29. Aug 2017, 10:05
von jpunktkpunktzwo
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

Verfasst: Di 29. Aug 2017, 14:30
von mokraemer
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.

Re: Seiten Ausgabe komprimieren

Verfasst: Di 29. Aug 2017, 23:52
von WBTMagnum
@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.

Re: Seiten Ausgabe komprimieren

Verfasst: Mi 30. Aug 2017, 16:57
von mokraemer
@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....