Ankündigung

Einklappen
Keine Ankündigung bisher.

Problemchen für .gzip comprimierte css/js Dateien in .htaccess

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Problemchen für .gzip comprimierte css/js Dateien in .htaccess

    Haoo Forum,

    Ich habe die letzten 2 Tage damit verbracht mein CMS an 2 Baustellen weiter zu entwickeln.
    Nun habe ich es soweit fertig das css und js Dateien minfied und zu .gz verarbeitet werden (ich habe immer gerne alle Dateien in leserlicher Form vorhanden so das später das CMS die Komprimierung übernimmt (einmalig)).
    Leider klappt es aber nicht so recht mit der .htaccess, unter der eigentlichen Domain wenn es direkt im Hauptverzeichnis liegt wird es wohl klappen aber ich würds gern jetzt schon mal testen

    Code:
    RewriteEngine On
    
    #Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
    
    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    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,E=is_gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1,E=is_gzip:1]
    Header set Content-Encoding "gzip" env=is_gzip
    
    #-- Base rules
    Alias "/owp" "/var/www/vhosts/mydomain.de/httpdocs/devplace/"
    RewriteRule ^/owp/app/(.*)$ /devplace/app/$1
    RewriteRule ^/owp/fw/(.*)$ /devplace/fw/$1
    RewriteRule ^/owp/(.*).php$ /devplace/$1.php
    
    #-- fetch half-seo sites
    RewriteRule ^/admin/(.*)/(.*)$ /devplace/adminMaster.php/$1/$2
    RewriteRule ^/mod/(.*)/(.*)$ /devplace/adminMods.php/$1/$2
    RewriteRule ^/owp/(.*)/(.*)$ /devplace/index.php/$1/$2
    
    #-- home for logged in users (redirect to it after login)
    #RewriteRule ^/owp/$ /devplace/index.php/dashboard/view
    
    #-- fetch defined sites btw. routes
    RewriteRule ^/owp/Abmelden.html$ /devplace/index.php/auth/logout
    RewriteRule ^/owp/Passwortanfordern.html$ /devplace/index.php/auth/newpassword
    RewriteRule ^/owp/Kostenfrei-anmelden.html$ /devplace/index.php/auth/register
    RewriteRule ^/owp/meine-Campagnen.html$ /devplace/index.php/creator/campagnes
    RewriteRule ^/owp/meine-Kreationen.html$ /devplace/index.php/creator/creations
    RewriteRule ^/owp/Kreation-details-(.*)$ /devplace/index.php/creator/viewDetails?creation=$1
    RewriteRule ^/owp/Bald-online.html$ /devplace/index.php/maintenance/development
    RewriteRule ^/owp/Wartung.html$ /devplace/index.php/maintenance/maintenance
    
    # u.s.w.
    Ich hatte es damals mit Alias umgesetzt wenn das Script in einem Unterordner lag, es gab da div. Gründe und so war es am einfachsten.
    Die Dateien werden zur Zeit ohne den alias 'owp' eingebunden, es wird der reale Ordner bzw. Pfad genutzt 'devplace/pfad/zur/datei.css' könnte dass, das Problem sein?

    Wie ich die Anweisungen verstehe, wird doch lediglich geschaut ob eine .css oder .js Datei aufgerufen wird und alles vor dem Punkt wird doch beibehalten, ggf. lediglich das .gz dran gehangen.

    Hmm, vllt. hat ja Jemand eine Idee, wäre echt super !!!

    MfG: Paykoman

  • #2
    Warum überlässt du die Komprimierung nicht einfach dem Webserver? Ich sehe diese Aufgabe nicht bei einem CMS.

    Kommentar


    • #3
      Zitat von hellbringer Beitrag anzeigen
      Warum überlässt du die Komprimierung nicht einfach dem Webserver? Ich sehe diese Aufgabe nicht bei einem CMS.
      Eine Übersicht bei Wikipedia findest Du hier:
      https://en.wikipedia.org/wiki/HTTP_compression

      Nun habe ich es soweit fertig das css und js Dateien minfied und zu .gz verarbeitet werden
      Minified (Uglyfied) werden diese Daten üblicherweise im Deployment Prozess.

      Kommentar


      • #4
        Das Thema ist das die Auslieferung in .gzip nicht funktioniert.
        Was natürlich sehr ärgerlich ist weil solange die Auslieferung nicht klappt war es viel Mühe für Nichts.

        Eine Übersicht und weitere Informationen findet man auch hier:

        https://www.askingbox.de/tutorial/we...ten-verkuerzen

        und hier

        http://www.tfonfara.de/javascript-un...rimieren.xhtml

        aber wie schon erwähnt und wie der Beitrag ganz oben verdeutlicht funktioniert es nicht =(
        Darum hatte ich um Hilfe bei der .htaccess gebeten.

        Kommentar


        • #5
          Zitat von Paykoman Beitrag anzeigen
          Das Thema ist das die Auslieferung in .gzip nicht funktioniert.
          der erste von dir verlinkte Artikel ist von 2011 und in meinen Augen nicht "state of the art", der zweite läd erst garnicht.
          es macht in meinen Augen Sinn, das den Webserver mache zu lasssen:
          https://css-tricks.com/the-differenc...-and-gzipping/

          Kommentar


          • #6
            @Tom: ich verstehe nicht ganz wie man so aneinander vorbei reden kann... Anhand deines letzten Links denke ich sind wir uns einige das minified Dateien und gzip komprimierte Dateien definitiv genutzt werden sollten.
            Nun genau an diesem Punkt bin ich doch!!! Ich habe sowohl die .min-Dateien als auch die mit .gz (die gleichnamig am selben Ort liegen) das Problem ist das die .gz-Dateien nicht ausgeliefert werden.

            Dazu muss eben die .htaccess Datei angepasst werden, die .htaccess prüft bzw.soll prüfen ob der client gzip kompression fähig ist und dann die gzip Dateien statt die normalen .min Dateien ausliefern.
            Genau das war der Grund warum ich diesen Post erstellt habe, denn meine .htaccess Anweisung funktioniert nicht, es werden immer die .min-Dateien ausgeliefert aber leider nicht die .gz-Dateien (die gz.-Dateien werden falsch verlinkt und sind dann nicht erreichbar vom Browser, weil iwas falsch läuft in der .hataccess denn die Pfade sind 100% identisch).

            Deshalb habe ich hier meine .htaccess gepostet damit wir zusammen den Fehler finden können warum die .gz Dateien nicht ausgeliefert werden!

            Kommentar


            • #7
              So in der Zwischenzeit habe ich mal etwas rum gedocktert...

              Code:
              RewriteEngine On
              
              #-- Base rules
              Alias "/owp" "/var/www/vhosts/mydomain.de/httpdocs/devplace/"
              
              # AddEncoding allows you to have certain browsers uncompress information on the fly.
              AddEncoding gzip .gz
              
              #Serve gzip compressed CSS files if they exist and the client accepts gzip.
              #RewriteCond %{HTTP:Accept-encoding} gzip
              #RewriteCond %{REQUEST_FILENAME}\.gz -s
              #RewriteRule ^/owp/(.*)\.css $1\.css\.gz [QSA]
              RewriteRule ^/owp/(.*).css$ /devplace/$1.css.gz
              
              # Serve correct content types, and prevent mod_deflate double gzip.
              RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1,E=is_gzip:1]
              Header set Content-Encoding "gzip" env=is_gzip
              Zur Fehlerbehebung habe ich mich mal auf .css konzentriert.
              Die RewriteRule habe ich etwas angepasst so das wenn ich die css Datei manuell im Browser aufrufe die .gz Datei ausgeliefert werden soll, funktioniert!
              Aber sollte die .gz Datei aufgrund der Anweisung nicht leserlich sein? Denn leider sieht man nur den quellcode der .gz

              Wenn ich die anderen Lines wieder rein mache bin ich beim besagten Problem, das eben einfach immer die unkomprimierte Datei ausgeliefert wird

              Kommentar


              • #8
                Du musst gar keine gzip-Dateien erzeugen. Überlasse die Komprimierung dem Webserver.

                Kommentar


                • #9
                  Hä? Dort wird nichts erzeugt oder Komprimiert !!!
                  Der Webserver liefert .css Dateien an den Browser genau so aus wie sie auf dem Server vorhanden sind.
                  Genau das ist ja der Knackpunkt, für eine schnellere Übertragung und Reduzierung des Traffics können css und js Dateien als .gzip Dateien an den Browser geliefert werden.
                  Natürlich nur wenn diese als .gz bereits auf dem Webspace liegen.

                  Alle gängigen Browser wissen diese .gz Dateien zu entpacken, dies geschieht auf dem Client nicht auf dem Server.
                  Die Voraussetzung dafür ist, das der Webserver dem Browser mitteilt wie er mit dieser .gz Dateien zu verfahren hat und genau das ist was über die .htaccess geregelt wird (keine Erzeugung).

                  /pfad/zur/datei.min.css
                  /pfad/zur/datei.min.css.gz

                  Wie oben schon erklärt, prüft die .htacces ob der Browser gzip kompatibel ist wenn ja wird die .gz Datei ausgeliefert anstelle der datei.min.css. hier wird also gewiss nicht jedes mal etwas komprimiert oder erzeugt wenn ein request stattfindet.

                  Das bedeutet natürlich das die Dateien wie bisher ganznormal als datei.min.css im quellcode verlinkt sind, die .htaccess hängt im Grunde nur ein .gz an den Pfad dran, so das eben die Komprimierte Datei ausgeliefert wird (ABER nur wenn der Client gzip kompatibel ist).

                  Aber das ich das hier 10 mal erklären muss, bedeutet eigentlich das keiner auch nur ansatzweise auf die .htaccess geschaut hat, denn dann hätte man eben genau dieses erkannt.
                  Es würde mich sehr freuen, würden wir jetzt endlich herausfinden warum die .htaccess nicht so arbeitet wie es gewünscht ist.

                  Letzter stand der Dinge in Beitrag #7

                  Kommentar


                  • #10
                    Zitat von Paykoman Beitrag anzeigen
                    Hä? Dort wird nichts erzeugt oder Komprimiert !!!
                    Der Webserver liefert .css Dateien an den Browser genau so aus wie sie auf dem Server vorhanden sind.
                    Genau das ist ja der Knackpunkt, für eine schnellere Übertragung und Reduzierung des Traffics können css und js Dateien als .gzip Dateien an den Browser geliefert werden.
                    Natürlich nur wenn diese als .gz bereits auf dem Webspace liegen.
                    Das stimmt nicht. Der Webserver kann „on the fly“ komprimieren.

                    https://varvy.com/pagespeed/enable-compression.html

                    Kommentar


                    • #11
                      Zitat von hellbringer Beitrag anzeigen

                      Das stimmt nicht. Der Webserver kann „on the fly“ komprimieren.

                      https://varvy.com/pagespeed/enable-compression.html
                      Ist dies aber nicht serverlastiger als wenn man einfach eine bereits vorhandene .gz sendet?
                      So muss der Webserver bei jedem Request die Komprimierung vollziehen, in meiner Variante wären die Dateien ja schon vorhanden und der Webserver hat weniger zur arbeiten.

                      ::EDIT::
                      habe es mal fix in meinem nginx rein gemacht und es erspart mir gerade mal 0,2MB so das immer noch 1,3mb von 1,5mb ausgeliefert werden, bei meinen vorgezippten Dateien liefere ich nur noch 688KB aus.
                      Demnach würde ich meine Variante vorziehen, zusätzlich zur unnötigen Serverlast die eingespart wird.

                      Kommentar


                      • #12
                        Du optimierst an den falschen Stellen.

                        Was denkst du ist besser, 2 requests für 2 CSS Dateien mit deflate(.gz) komprimiert zu übertragen oder
                        1 CSS Datei evtl unkomprimiert?
                        Gleiche Frage und Antwort gilt auch für Javascript-Dateien, da solltest du ansetzen.

                        Das Format gz ist schon optimiert auf den Stream.
                        Was kommt als nächstes, willst du die beteiligten Router auch minimieren?

                        Wie oben schon erklärt, prüft die .htacces ob der Browser gzip kompatibel ist wenn ja wird die .gz Datei ausgeliefert
                        Das geschieht schon auf einer anderen Ebene im Protokoll, das musst du nicht implementieren.
                        Investiere deine wertvolle Arbeitszeit lieber in andere Dinge, dieses Problem ist längst gelöst.

                        Kommentar


                        • #13
                          Zitat von protestix Beitrag anzeigen
                          Was denkst du ist besser, 2 requests für 2 CSS Dateien mit deflate(.gz) komprimiert zu übertragen oder
                          1 CSS Datei evtl unkomprimiert?.
                          Wieso 2 Request für 2 Dateien? Es wird doch nur die datei.min.css angefragt ggf. aber nicht ausgeliefert sondern die datei.min.css.gz, es werden ja nicht beide Dateien ausgeliefert (entspricht doch einer Anfrage und einer Auslieferung) !?!?
                          Und wie schon erwähnt, ist das Komprimierungslevel von ngix äußerst gering, selbst gezipte Dateien haben eine viel höhere Kompression.
                          gzip_comp_level 2; hoch zusetzten hatte irgendwie keine Auswirkung, in php geht es ja von (keine) 0-9 (max) wenn die Kompression höher wäre könnte ich damit ja leben dann muss man halt aussreichend Ressourcen zur Verfügung stellen aber so ist es witzlos.

                          Es könnte natürlich sein das Die Dateien auf dem Webserver dann gecacht werden und das erhöhen von 2 auf 9 deshalb keine Auswirkung hatte.

                          ::EDIT::
                          So ich habe mal etwas gegoogelt und es ist wie ich schon sagte, der Webserver muss bei jedem Request die Dateien Komprimieren bevor er sie ausliefert !
                          Genau das frisst viel CPU mein CMS stellt die Dateien aber statisch bereit (immer vorhanden keine ewig erneute Komprimierung je Anfrage).
                          Aber es gibt dafür auch eine Lösung unter ngix

                          Code:
                          gzip_static  on;
                          gzip_proxied expired no-cache no-store private auth;
                          Dies regelt genau das, was ich zuvor mit .htaccess versucht habe, wenn eine .gz-Datei für die angefragte Datei vorhanden ist liefert er diese aus anstelle der nicht .gz-Datei!

                          Etwas verwunderlich finde ich die no-cache Angaben, bin da aber auch nicht sehr bewandert, jedenfalls werden die Dateien nach dem ersten Laden stehts aus dem memmory cache des clienten geladen (toll).

                          Eine wirkliche Laufzeit-verbesserung kann ich jedoch nicht feststellen aber immerhin ist der Traffic reduziert!

                          Kommentar


                          • #14
                            Zitat von Paykoman Beitrag anzeigen
                            So ich habe mal etwas gegoogelt und es ist wie ich schon sagte, der Webserver muss bei jedem Request die Dateien Komprimieren bevor er sie ausliefert !
                            Müssen tut er nicht. Genauso wie er auch nicht bei jedem Request die Datei neu lesen muss. Ich kenn die genauen Implementierungen nicht, aber mich würde es doch stark wundern, wenn die Entwickler kein Caching bedacht hätten.

                            Kommentar


                            • #15
                              Zitat von Paykoman Beitrag anzeigen
                              Dies regelt genau das, was ich zuvor mit .htaccess versucht habe, wenn eine .gz-Datei für die angefragte Datei vorhanden ist liefert er diese aus anstelle der nicht .gz-Datei!
                              mich würde interssieren ob sich das Verhalten ändert, löscht Du die "peäparierte" .gz Datei, müsste es ja.
                              Da Du Dich fragtest, was das ganze macht, ich habe zufällig eine Seeite gefunden, wo genau Deine directives erklärt werden:

                              https://www.nginx.com/resources/admi...decompression/

                              Kommentar

                              Lädt...
                              X