Combining , merge , aneinanderhängen, concat von JS bzw CSS Files

  • Hallo alle,


    eine neue Site mit JCE + Media Box und sonst keine weiteren Erweiterungen
    macht fast (die Homepage) 50 Serverzugriffe. Unglaublich.
    Darunter 7 Bilder, 10 css, 24 js Files

    Wie kann ich CSS bzw JS - Files automatisch concaten.
    Gibt es eine hauseigene Lösung die alle Code-Files als 2 Files ausgibt? Also eine js und eine css.
    Wenn es das nicht gibt, warum? Gibt es gute Gründe dies nicht zu tun?

    Gäbe es ein Plugin das dies durchführt?

    Beste Grüße
    Daniel

  • Gäbe es ein Plugin das dies durchführt?

    JCH Optimize macht das z.B. und cached die Dateien dann auch (was ich als Vorteil sehe). Ich kann allerdings empfehlen, dass du das Ding minimal konfigurierst, also hinter dem Optionen-Button wirklich nur gewollte Sachen und nicht Kram, der dolle klingt, aber von Joomla eh schon abgewickelt wird.


    Joomla selbst, nein. Aber Joomla verwendet jetzt häufiger modernere Lademethoden, die die Gewichtung "viele Assets = schlimm" relativieren.

  • 1) es ist komplett normal, dass einige Dateien nicht berücksichtigt werden. Das sind dann z.B. welche, die als "module" und/oder "defer" gekennzeichnet sind (siehe Seitenquelltext). Siehe meinen Kommentar:

    Joomla verwendet jetzt häufiger modernere Lademethoden, die die Gewichtung "viele Assets = schlimm" relativieren.

    Wenn es diesbzgl. Features in JCH gibt, vielleicht in der Pro, würde ich sie nicht verwenden.

    2) Die dritte Zeile in deinem Screenshot (leider abgeschnitten) sieht so aus, als wäre das eine der Dateien von JCH. Eben eine gecachte JS-Datei. Keine Ahnung. Siehe aber auch meine beiden letzten Bilder hier.

    3) Ob Dateien berücksichtigt werden, hängt davon ab, wie sie von Erweiterungen eingebunden werden.Es müssen unbedingt Joomla-Methoden verwendet werden

    4) Wenn du im Frontend eingeloggt bist, arbeitet JCH nur, wenn du diese Einstellung auf Nein setzt.Im Normalbetrieb sollte sie aber auf JA stehen


    5)

    Ich kann allerdings empfehlen, dass du das Ding minimal konfigurierst, also hinter dem Optionen-Button wirklich nur gewollte Sachen und nicht Kram, der dolle klingt, aber von Joomla eh schon abgewickelt wird.

    Also eben nicht im Dashboard irgendwas klicken.

    6) Meine einstellungen derzeit auf einer Testseite Joomla 4. Allerdings Screenshots aus Joomla 3.



    GZIP kann, muss aber nicht, problematisch sein.




    7) In meinem Seitenquelltext sehe ich dann 2 Stellen:

    CSS



    JS:


    aber eben auch zahlreiches, was JCH ignoriert.

  • Extra in einem neuen Post:

    - Nicht alle Einstellungen sind für alle Seiten geeignet. Das muss man individuell testen, ob noch alles OK aussieht und funktioniert.

    - Unter Joomla 4 habe ich noch nicht getestet, ob ich JCH weiterhin """empfehlen""" kann. Es macht mir manchmal zu viel. Bspw. verändert es die .htaccess, ohne, dass man was dagegen tun könnte. Mich nervt das extrem, andere vielleicht nicht.


    - UND: Zu meinen Einstellungen oben: Alles andere steht bei mir auf NEIN!

  • Nur ein SEHR kurzer Abriss:


    - Joomla 4 verwendet den Web Asset Manager (WAM) zum Laden von Assets. Erweiterungen (auch oder gerade Templates), die eigene Assets (CSS, JS) laden, sollten eine joomla.asset.json nutzen, da recht filigran konfigurierbar bzw. Core-Assets recht einfach "overridebar". Bspw. Jquery, wenn man es denn noch benötigt auf JQuery-Slim umleiten. Auch um Doppelladungen zu vermeiden, falls Erw. noch veraltete Methoden verwenden.


    Oder auch Bootstrap, wenn andere Versionen zum Template besser passen als die derzeitige aus Joomla (BS5.1).


    Allerdings muss man sich um die Bereitstellung der Alternativen selber kümmern.


    In Joomla 4 finden sich diverse joomla.asset.json, die als Basis für den WAM dienen. Jedwede erweiterung kann eigene hinzufügen. Aber den WAM auch ohne nutzen.


    - Joomla 3 den HTMLHelper bzw. direkter addScript() und ähnliche Methoden etc.


    Unter Joomla 4 verwenden diverse 3rd Erweiterungen immer noch zweiteres, da das halt auch noch funktioniert, aber nicht der Core, zumindest ab Joomla 4.2 dann, wo einige Stellen noch nachgearbeitet wurden.


    Wird beides durcheinander verwendet von Erweiterungen, wirds komplizierter und auch unperformanter, da mehr Code durchlaufen werden muss. Ob wir hier von 1 oder mehr Millisekunden reden, keine Ahnung.


    Weiters sollte jede Erweiterung gz-Dateien (min.css.gz, min.js.gz) bereit stellen. Core tut das. Das ist weitaus effizienter als irgendwelche Tools zu verwenden, die Dateien erst beim Laden "gzippen". Liegt eine solche Datei vor, lädt der WAM die automatisch, falls man denn den WAM nutzt. Muss man sich also nicht drum kümmern.


    Wenn Erweiterungen sich also noch auf "funktioniert ja noch, was soll's" ausruhten und nicht wenigstens für Joomla 3 schon umfassend auf Core-Methoden zurückgriffen, ist eine Umstellung nicht mehr trivial. "Trivial" meint paar Tage Einarbeitung in die WAM-Thematik, um alle möglichen Tricks zu kennen und da gibt es einige...


    Kurz: Zuinstallierte Erweiterungen gehören optimiert oder rausgeschmissen, nicht der Joomla-Core diesbzgl. kaputt-optimiert ;)

  • Liegt eine solche Datei vor, lädt der WAM die automatisch, falls man denn den WAM nutzt. Muss man sich also nicht drum kümmern.

    entschuldigung, bitte! Das ist falsch. Richtig ist:


    - Der WAM lädt immer die .min.css, .min.js, wenn vorhanden, wenn Joomla nicht im Debug-Modus ist. Jede Erweiterung sollte also min-Dateien dabei haben.


    Sagt man dem WAM also, "lade diesdas.css", lädt er diesdas.min.css. Sagt man dem WAM "lade diesdas.min.css" und Joomla ist im Debug-Modus, lädt er diesdas.css.


    - Die Joomla-4-htaccess sorgt schließlich dafür, dass die [.min].css.gz bzw. [.min].js.gz geladen wird, falls vorhanden.

    joomla-cms/htaccess.txt at 4.2.0-rc1 · joomla/joomla-cms
    Home of the Joomla! Content Management System. Contribute to joomla/joomla-cms development by creating an account on GitHub.
    github.com


    oder die css js on-the-fly "gzettet" wird.

  • Danke "Später",

    das ist schonmal eine gute "Zusammenfassung".

    Da muss ich mich in das Thema einarbeiten, anders hat das wenig Sinn.

    Wenn ich hier eine themennahe Frage stelle wird sicher ein neuer Post drauß?!


    Wollt "ihr" mal die Möglichkeit schaffen, dass ganze System in statische Files umzuwandeln.
    Mit einem einfachsten Web-Paket von hosteurope habe ich auch bei einfachen Joomla-Sites teils Time to First Byte von 1 bis 2 Sekunden.
    Das ist deutlich zu lange (Ich weiß, es gibt schnellere Provider)
    Bei neuen, schlanken J4 Projekten teils immer noch 1s.

    Beste Grüße
    Daniel

  • Auch nur eine kurze Stoffsammlung:

    mal die Möglichkeit schaffen, dass ganze System in statische Files umzuwandeln.

    Letztlich kann man jede Web-Site in statisches HTML umwandeln, bspw. mit HTTrack und anfänglich längerer Suche+Tests nach passender Konfiguration je individuelle Web-Site. Man kann dann allerdings nicht erwarten, dass dynamische, interaktive Inhalte wie Formulare und ähnliche noch irgendwas tun.


    Weiters kannst unter Joomla ja auch Cache-Erweiterungen verwenden, die die komplette Einzelseiten ("jeden Link") in je 1 Datei packen, also 1 statische Datei per Link/Url. Gibt ja auch im Joomla-Core das Page-Cache-Plugin, das man dann halt nicht zusammen mit dem Cache aus der Joomla-Konfiguration nutzen sollte. Gibt aber auch andere, bspw. von Kubik-Rubik. Einzelne Seiten/Links kann man vom Caching ausschließen. Als Hinweis: Was viele dabei vergessen: Die in Joomla voreingestellte Cache-Zeit ist viel zu kurz (15 Minuten) als dass die im Produktivsystem wirklich Sinn machen würde.


    ein Tool mit dem man Joomla in eine Basis für vielleicht SSGs wandeln kann oder ähnlich, wie es es bspw. für WordPress gibt (mit Haufen Nacharbeit und Gefluche) ist mir nicht bekannt. Aber das ist ja dann auch schlicht ein Wechsel in ein anderes ""CMS"" wie bspw. das SSG HuGo. Man hat dann Markdown-Dateien, die wiederum von den SSG-Sytemen in HTML-Web-Sites gewandelt werden und lauffähig hochgeladen werden.


    Ich kann nur warnen, per se zu glauben: "less complex to use and maintain", wie bei Ionos gefunden. Da fehlt einfach der Hinweis ", wenn man das System mal so eingerichtet hat, dass Änderungen unbedarfter Nutzer gleich online gehen können, ohne, dass die sich darum kümmern müssen":

    Zitat

    In principle, a static site generator is a software that generates a static website. Compared to content management systems (CMS) such as wie WordPress, Joomla! etc., static site generators are a lot less complex to use and maintain, while maintaining high security. Some SSGs even allow the operation of a content management system as headless CMS

    10 best static site generators
    Static site generators are hugely popular. The tools impress because they’re not so complex to use and generate websites in high quality. Read on to find out…
    www.ionos.com


    Und, bzgl. deiner Frage: Warum dann nicht gleich einen Webseiten-Baukasten verwenden, den ja heutzutage jeder Hoster im Angebot hat? Der von Ionos ist übrigens grauenhaft restriktiv und inhandlich, irgendwie. Ist aber der einizige, den ich je ausführlicher getestet habe. Hängt schlicht von der Seite und den Inhalten ab, ob so ein Baukasten eine Option sein kann.

    Time to First Byte

    Kann ich nichts zu sagen. Ich messe so was nicht, wenn ich nicht soll/muss. Ich verlasse mich darauf, was ich selber sehe und empfinde, in einem nicht cachenden Browser und CMS, dann in einem cachenden...


    Wenn ich hier eine themennahe Frage stelle wird sicher ein neuer Post drauß?!

    Sollte dann schon eher "praxisnah" sein. "Folgende Seite mit folgendem Code, bei dem ich versuche das zu tun, was mir nicht gelingt. Wie könnte das gehen?" Aber das hast du ja in einem deiner anderen Threads schon oft genug gehört ;)


    Da muss ich mich in das Thema einarbeiten, anders hat das wenig Sinn.

    Ich arbeite erst mal auch nur nach dem Schema: Das will ich in der Praxis umsetzen. Wie geht das wohl modern? Habe ich die Lösung, mache ich je nach Zeit, halt nicht weiter oder steige tiefer ein, weil ich bei der Recherche nette Stellen und Tricks gefunden habe, die ich anderstwo gleich nutzen kann.


    Zu WAM findet man im Core-Cassiopopopeia-Template einige Hinweise, wie das grundlegend in der Praxis funktioniert.


    Und manchen ist es ja auch egal, ob sie den Code verstehen, den sie da irgendwo rauskopieren und reinkopieren... Geht ja auch, wenn man nur will, dass was funktioniert ;)


    Oder wechselst halt den Hoster. Weiß hier aber auch nur, dass z.B. fc-hosting ( flotte ) sich um solche Belange zusammen mit dir kümmert, wobei es da keine Gewähr gibt (= nicht im Vertrag explizit so angeboten). Will also nicht zu viel versprechen!!! Halt so Messgeschichten, wo nun wirklich der Flaschenhals in einem System ist.

  • erstmal Danke later,


    viele gute Infos.


    Ich nutze den Joomla Cache, der geht in der Regel auch recht gut.
    Dieses Umwandeln der Sites in Html würde ich bei Kundenprojekten natürlich auch nicht machen.
    Das versteht der Kunde dann am Ende auch nicht. Ausser man baut ein Script, dass dann alles erledigt.
    Ob die Page dann am Ende so viel schneller ist, müsste man auch mal testen.

    ...
    Http2 bietet besagter Provider erst ab eigenem Server an und "größeres" Hosting für Hobbysites muss dann auch nicht sein.
    Dennoch scheinr sich die "Zeit der Auslieferung" bei den Providern stark zu unterscheiden. Daher mache ich auch grade einen Test
    einem beim Provider und vergleiche das dann mal.

    lg daniel


    Also, ich habe das mit dem Backup zu S2 ohne Probleme hinbekommen.

    S1 Hosteuropa

    S2 Allinkl

    Händischer Test ca 15 mal: Firefox neue Version, Browser-Cache immer wieder gelöscht. -> TTFB
    Ergebniss: S1 um 400 ms - S2 um 200ms

    Auch der gtmetrix Vergleich zeigt, S2 ist schneller.

    Meine "erste" Joomla (1.15) Page in neuem Gewand: http://www.saar-wingchun.de

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von saardaniel mit diesem Beitrag zusammengefügt.