Typo3 Komprimierung NGINX

M4ND0

Hallo,

ich bin leider kein Server-Techniker und habe bisher auch noch nie mit NGINX gearbeitet und hoffe hier ein wenig Hilfe zu diesem Thema zu finden.
Ich versuche eine Typo3 Komprimierung zum Laufen zu bekommen. Aber sobald ich die berühmten vier Zeilen aktiviere, dann zerschießt es mir das FrontEnd, auch wenn ich die EXT:min installiere, dann interessieren die komprimierten CSS und JS Dateien nicht.

Gibt es eine Möglichkeit dies bei NGINX zu aktivieren/kontrollieren/etc...

Vielen Dank
LG Silvio

pno

Hi Silvio,

ich hatte am Freitag tatsächlich das selbe Problem. Redest du nur von der gzip-Komprimierung, oder auch von Minifizierung? Das sind am Ende zwei paar Schuhe. Ich habe gzip jetzt folgendermaßen in meine nginx Config gelöst:

    # GZIP compression
    gzip on;
    gzip_types
        application/javascript
        image/svg+xml
        text/css;
    gzip_min_length 100;

    # cache headers
    location ~* .min.(?:css|js)$ {
        expires 1y;
        add_header Cache-Control "public";
    }

Der obere Teil aktiviert die gzip-Komprimierung für nginx. Der untere Teil setzt die Cache-Header für alle minifizierten CSS und JS Dateien. Das Minifizieren löse ich in einem Build-Step in der CI-Pipeline.

M4ND0

pno Hi,

Danke für Deine Antwort, wahrscheinlich liegt es dann ggf. eher an der Minifizierung - das könnte ich mal probieren, wenn ich diese erstmal weglasse, ob es dann funktioniert. Danke für den Tipp...

Das mit der Pipeline habe ich bisher immer "weggelassen" - wie realisierst Du so etwas?

pno

Die Pipeline realisiere ich mit GitLab CI. Geht aber genauso gut mit GitHub Actions o.ä. Vom Prinzip her ist das eigentlich relativ simpel. Die CI fährt einen Docker Container hoch und checkt für dich den aktuellen Stand des gewünschten branches aus (in dem Fall dann vermutlich main). Danach übernimmst du quasi und kannst beliebige Befehle in dem Container abfeuern. Was genau du da machst hängt dann sehr von deinem Setup ab. Bei uns sieht das in etwa so aus:

composer install --no-dev
npm install im sitepackage
npm build im sitepackage

Der letzte Step ist am Ende auch nur eine Sammlung von Skripten die verschiedene Nodejs Programme auf der Kommandozeile aufrufen, um JS und CSS zu bundlen, ggf. Optimierungen drüber laufen lass (autoprefixer bspw.) und am Ende in eine einzige minifizierte Datei schreiben die dann im sitepackage eingebunden wird. Das Minifizieren von CSS mache ich dabei mit cssnano und JS mit esbuild.

Wenn das durch ist, wird der ganze Krempel gezipt und dann per scp auf den Zielserver geschoben, per Konsole Datenbank Migrationen angestoßen und anschließend ebenfalls über Konsole der Cache geleert. Ist jetzt natürlich sehr stark vereinfacht, aber das Prinzip ist immer gleich.
Die CI brauchst du dafür auch nicht zwingend, bei meinem alten Arbeitgeber haben wir das einfach in Shell-Skripten abgebildet. Lohnt sich aber definitiv sich damit mal zu beschäftigen. Insbesondere, weil man so eine schöne Historie über alle Deployments hat und auch nicht jeder den Prozess verstehen muss. Wenn man neu in das Projekt kommt, reicht erstmal zu wissen, dass push auf main bedeutet der Code geht anschließend direkt live.

Wenn du in Sachen Deployment bisher noch nichts automatisiert hast, würde ich empfehlen erstmal mit einem lokalen Skript anzufangen das die Minifizierung übernimmt und das Ergebnis im Zweifel händisch zu deployen.

Den ganzen CI Krempel für TYPO3 habe ich auch erst letzte Woche aufgesetzt, weil wir lange keine Projekte mit TYPO hatten. Habe schon überlegt, ob es sich lohnt den ganzen Prozess mal in Schrift- oder Videoform zu dokumentieren und zu veröffentlichen. Lasst mich gerne wissen, wenn das Content ist an dem Interesse besteht. Bin mit bei solchen Themen immer sehr unsicher, weil ich oft das Gefühl habe, dass da irgendwie jeder anders ran geht. Wenn ich Projekte von anderen Agenturen sehe, gibt es da entweder schon einen Prozess der extrem opinionated ist, oder einfach gar nichts :-D

M4ND0

Bisher habe ich immer nur mit Mittwald Servern gearbeitet und da funktionierte die Komprimierung und das GZIP immer, mit ein paar zusätzlichen Einstellungen in der .htaccess. Nun haben wir uns für eine Server bei Timme Hosting entschieden, dieser ist nur NGINX und kein APACHE mehr - wenn ich die standardmäßige Komprimierung via Typo3 einstelle, funktioniert dies nun leider doch nicht mehr wie gewohnt. Deswegen fehlt mir hier auch noch der komplette Lösungsansatz mit einer GitHub Action und der Komprimierung außerhalb von Typo3. Deshalb dachte ich, man kann es auch einfach über 4 - 6 Zeilen in der NGINX Direktive lösen, scheint wohl aber nicht so der Fall zu sein.

Markus Hofmann

Wenn ihr die CSS und JS schon in der Pipeline baut, dann hab ich hier noch einen Tipp: Lasst in der Pipeline auch gleich die gz-Komprimierung mit laufen.
Mit folgendem Command liefert ihr mit den Artifacts sowohl die Originale als auch die gzipped mit aus:
gzip -9 -k packages/sitepackage/Resources/Public/Css/*
gzip -9 -k packages/sitepackage/Resources/Public/JavaScript/*
gzip => Komprimierung
-9 => Höchste Kompzimierung
-k => keep Original File, also behalte die Originaldateien

nginx:

# Enable gzip compression
gzip  on;

# Set the response header Vary: Accept-Encoding. 
# Some proxies have a bug in that they serve compressed content to browsers that don't support it.
# By setting the Vary: Accept-Encoding header, you instruct proxies to store both a compressed and 
# uncompressed version of the content.
gzip_vary on;

# Enables or disables gzipping of responses for proxied requests depending on the request and response.
gzip_proxied any;

# This tells nginx what file types to compress (text/html is always compressed)
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

# Add mime-type for compressed js files.
location ~ \.js\.gz {
# gzip off and add_header only, if you gzip in Pipeline
  add_header Content-Encoding gzip;
  gzip off;
  types {
    text/javascript gzip;
  }
}

# Add mime-type for compressed css files.
location ~ \.css\.gz {
# gzip off and add_header only, if you gzip in Pipeline
  add_header Content-Encoding gzip;
  gzip off;
  types {
    text/css gzip;
  }
}

M4ND0

Die CSS und JS baue ich nicht in einer Pipeline zusammen oder nutze (noch kein) grunt oder gulp. Ich verwende die Komprimierung von Typo3, damit ich nur das jeweilige CSS und JS, wie von Google gewünscht, ausspielen kann. Wenn ich dies aber verwende, wird die CSS oder JS fehlerhaft ausgespielt, somit ist auch das FeontEnd nicht korrekt. Wir sind bei Timme Hosting und der Support kann mir leider auch kein erwünschtes Ergebnis liefern.

Markus Hofmann

M4ND0
Welche TYPO3 Version ist das denn? Standardmäßig verwenden die älteren TYPO3-Versionen als gz Kürzel *.gzip, offiziell sollte aber *.gz verwendet werden. Es war in 11 noch gzip und erst seit 12 ist es gz.
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Configuration/Typo3ConfVars/FE.html#confval-typo3-conf-vars-fe-compressionlevel

Markus Hofmann

Sollte es eine v11 sein, dann hilft das Snippet für den nginx eventuell:

# Add mime-type for compressed js files.
location ~ \.js\.gzip {
# gzip off and add_header only, if you gzip in Pipeline or by TYPO3 compression
  add_header Content-Encoding gzip;
  gzip off;
  types {
    text/javascript gzip;
  }
}

# Add mime-type for compressed css files.
location ~ \.css\.gzip {
# gzip off and add_header only, if you gzip in Pipeline or by TYPO3 compression
  add_header Content-Encoding gzip;
  gzip off;
  types {
    text/css gzip;
  }
}

pno

@Markus Hofmann interessanter Gedanke schon während des builds zu gzippen, das schaue ich mir eventuell ab. Ich nehme an der Vorteil ist, dass nginx dann nicht jeden requested neu gzippen muss? Der Overhead ist vermutlich minimal, aber könnte eine nette Optimierung sein.

Markus Hofmann

@pno Das ist richtig. Damit muss nginx das nicht tun, sondern kann das schon als gz vorliegende File einfach mit den richtigen Headern ausliefern.

M4ND0

Hallo,

sehe ich das also richtig, dass Ihr immer das komplette CSS und JS auf jeder Seite ausliefert? Egal ob es genutzt wird oder nicht?

Markus Hofmann

Jein. Was das CSS betrifft, ja. Beim JS nein. Da arbeite ich viel mit <f:asset.script>, um nur einzubinden, was notwendig ist. Aber auch da hilft es, vorher zu kompilieren und gzippen, um die Daten schon gzipped auszuliefern. Das liegt aber auch daran, dass ich bei JS den Ansatz verfolge: So wenig wie möglich, so viel wie nötig.
Bei CSS ist es so, dass das komplett gerenderte File mit entsprechend korrekt eingestelltem Server-Caching im Client einmal geladen wird und danach nur noch aus dem Browsercache gezogen wird, statt bei jedem neuen Aufruf das jeweils angepasste CSS laden zu müssen. Das heißt effektiv, dass ab dem 2. Seitenaufruf nur noch HTML, Javascript (zusätzliches) und Mediendateien geladen werden müssen, CSS ist schon da.

M4ND0

Was sagt Google Page Speed dazu? Meist bekomme ich dann den Fehler, dass nicht verwendetes CSS geladen wird.

pno

@M4ND0 IMHO ist das eine Metrik die ich an der Stelle ignorieren würde. Du kannst zwar für jede Seite darauf optimieren, dass nur das CSS geladen wird das du benutzt. Aber dann verlierst du jeglichen Caching-Vorteil. Du müsstest dann für jede Seite ein eigenes Bundle erstellen, was bedeutet du lädst zwar auf Seite 1 nur das verwendete CSS, auf Seite 2 musst du aber ein komplett neues Bundle laden => ergo ein neuer Request den du dir sparst, wenn auf Seite 1 schon ein cachebares Bundle geladen wurde. Wenn du nicht bundelst ist es eigentlich noch schlimmer, weil du dann vermutlich mehrere CSS-Dateien pro Seite lädst, also auch mehrere Requests Overhead hast. Das dürfte performancemäßig mehr ins Gewicht fallen als der Overhead von einer größeren CSS Datei.

Die Metrik macht mehr Sinn, wenn es um SPA-like Seiten geht. NextJS oder Nuxt bspw. liefern das benötigte CSS dann inline aus und laden gar keine CSS-Datei. In unserem Travel-Blog siehst du das z.B. wenn du in den DevTools guckst (https://bucketlist2life.com). Mit den Frameworks hast du aber auch viel mehr Kontrolle darüber was auf die Seite gelangt. In TYPO3 würde ich gar nicht erst versuchen darauf zu optimieren, damit hast du vermutlich am Ende mehr Aufwand als Nutzen.

Ich versuche eigentlich generell hauptsächlich auf gutes Caching und möglichst wenig Requests zu optimieren. Damit kriegt man auch eine TYPO3 Seite richtig flott. Sofern einem dann nicht das Marketing-Team mit dem TagManager dazwischen funkt und 500 Skripte nachlädt, fühlt sich die Navigation dann auch fast instant an :-)

M4ND0

Welche Tools nutzt Ihr dafür? Grunt, Gulp, Vite ... bzw. wie geht Ihr da mit Typo3 genau vor? Lasst Ihr Euch lokal dann eine komprimierte zusammengefasste CSS erstellen und diese wird dann einfach im TypoScript hinterlegt - oder gibt es da auch noch extra Einstellungen, welche beim Server vorgenommen werden müssen, damit dies mit dem Coaching korrekt funktioniert?

Markus Hofmann

M4ND0
Wie ich weiter oben schon geschrieben hatte, bevorzuge ich Minifizierung und Komprimierung in der Pipeline. Welches Tool du dafür verwendest, ist dir überlassen. Die genannten eignen sich alle dafür.
Im TypoScript hinterlege ich schon lange kein CSS mehr, ich regele das alles über die Templates selbst mittels der <f:asset.script> und <f:asset.css>, welche ich in den Templates entweder in der <f:section name="HeaderAssets"/> bzw. <f:section name="FooterAssets"/> einbinde. Brauche ich mehrere Templates für unterschiedliche Seiten, lagere ich die assets in ein Partial aus, welches ich dann in die Template sections rendere.
Die Sections werden in Templates automatisch gerendert und korrekt eingebunden. Das Ganze funktioniert seit TYPO3 8.6: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/8.6/Feature-79409-AutorenderAssetSectionsInFluidTemplateWithController.html

pno

Ganz früher Gulp, in meinem letzten Job SGC (https://www.sgalinski.de/typo3-produkte-webentwicklung/sgc-cli-task-runner) (war anfangs auch gulp-basiert, später selbst geschrieben), inzwischen hab ich ein etwas anderes Setup das direkt cssnano u.ä. auf der CLI anstößt. Ich nutze dafür einen eigenen Task-Runner (in Kürze auch OpenSource), aber im Prinzip kann man das auch einfach per NPM-Scripts regeln. Da führen auf jeden Fall viele Wege nach Rom :-)

Ich erstelle dann in der Regel ein JS und ein CSS file das per TypoScript in site_package geladen wird. Das ist dann quasi die single source of truth. Die Asset-ViewHelper mag ich persönlich nicht so gerne an der Stelle, weil ich lieber einen zentralen Einstiegspunkt habe und gerade das Laden von JS dann lieber im JS selbst über imports regel. Sind aber beides valide Wege imho.

M4ND0

Ich werde mir Gulp noch mal genauer ansehen und damit ein wenig herumtesten, die Komprimierung somit darüber laufen lassen und Typo3 hier außen vor lassen. Vielen Dank für
den ganzen Input derweil.

Nächste Seite »

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS