WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Diskussion rund um JQ, JS und alles Mögliche

(1/11) > >>

Yetiie:

--- Quote ---Versucht, möglichst alles JS (vor allem JQ) nach unten ans Ende des Body zu schieben (frontend_body.js).

...

Es wird sofort im Multitasking das HTML übertragen und auch sofort angezeigt. Dann erst kümmert sich der Browser um das langsamere JS. Eine etwas umfangreichere Seite mit viel JS wird dadurch optisch deutlich schneller aufgebaut.

--- End quote ---



Naja, das Thema ist so alt wie JS/JQ und Konsorten selbst und sollte eigentlich bekannt sein. Übrigens: trotzdem packen immer noch viele auch große Seiten JS-Dateien immer noch an den Anfang ... und ich glaube das tun die meisten Module hier in WB auch. Das mag einerseits an der 'bequemen' Code-Organisation liegen wie aber aber auch an der fehlenden Bekanntheit von frontend_body.js ;-)

Was zu dem Thema dazu gehört (und sich noch nicht unbedingt überall rumgesprochen hat glaube ich) ist, dass das CSS eines Moduls vor der JQ eines Moduls geladen sein sollte ...



Andererseits:
---------------------------------

Schaue ich mir die großen Templates im Modern-Webdesign an   ...
... spielt das zukünftig wohl eine immer kleinere bis gar keine Rolle mehr.

Da soll HTML ohn JQ-Bearbeitung gar nicht angezeigt werden und sieht auch gar nicht aus ... keiner mag sehen, wie sich das HTML verändert oder es nicht wie gewünscht zucken kann. Entsprechend wird diese Anzeige in extremen Fällen in den Tempaltes dann auch gezielt durch Sandglass-Signs ersetzt. Wobei die langen Ladezeiten auch aber nicht nur durch die JS/JQ-Scripte geschuldet sind sondern auch durch die großen Background-Images ...

Ganz wichtig um Missverständnissen vorzubeugen: Das gilt natürlich nicht für alle ... aber diese Form der Templates nimmt zu und stellt sicher so was wie die Zukunft dar. Mag man es mögen oder nicht.




Some points for optimzing:
---------------------------------------------

Bei der Beschleunigung der Ladezeiten spielt übrigens nicht mehr unbedingt die Größe der Dateien (sofern es nicht die Mega-Background-Images sind) die entscheidende Rolle sondern die Anzahl der Dateien (HTTP-Requests) bzw. das Browser-Caching:

(A)
So macht es durchaus Sinn die JQ-Bibliotheken u.ä. von Google zu beziehen statt von der eigenen Seite, weil die oft schon von vorhergehenden Besuchen auf anderen Seiten im Browsercache vorhanden sind ... und dann gar nicht mehr geladen werden müsen. Man mag Google mögen oder nicht ... ich bin Nicht-Möger ... aber der Vorteil ist tatsächlich nicht unbeachtenswert und das Nutzen macht druchaus Sinn.

(B)
Ebenfalls macht es Sinn, die CSS-Dateien und JS-Dateien einer Seite in jeweils einer Datei zusammen zu fassen und in eienr Datei einzubinden anstatt für jede einzelne Seite zu optimieren. Das reduziert die Anzahl der Requests und ist schon auf auf einer Einzelseite mit individuell zusammen gestellten Scripten deutlich schneller.

(C)
Kombiniert man A+B baut kann man die CSS- bzw. JS-Dateien für ein Gesamtprojekt zusammenfassen anstatt die Einzeldateien pro Seite (je nachdem welcher Codeschnipsel für die spezielle Seite benötigt wird) zu optimieren. Ab dem zweiten Seitenaufruf steht es dann im Cache zur Verfügung ... was ein Laden wiederrum unnötig macht ... die Sanduhr wird dann im Zweifel nur beim ersten mal geschüttelt, - wenn durch die reduzierten Requests überhaupt.

Punkt C ist für mich der Grund, warum ich register-modfiles kaum benutze.




Anregung: Was kann WB für uns tun:
-----------------------------------------------------------------

Für WB würden sich daraus zwei Anregungen zur Optimierung der register_frontend_m odfiles() ergeben:


(1)

Die Funktion erweitern und anbieten, die großen Frameworks anstatt vom eigenen Server von den Google-Libraries zu laden, ... natürlich nur von dem der möchte.

Das könnte man realisieren indem man die Funktion 'register_frontend_m odfiles('jquery')' um einen optionalen Parameter 'register_frontend_m odfiles('jquery', 'google') erweitert.

Klasse wäre es auch, wenn man dann dort eine Liste anlegt, so dass man nicht 'jQuery' sondern auch die Version zur Auswahl stellt. Muss sich ja nicht nur auf jQuery beziehen ... ;-)

Der Aufwand für diese Lösung wäre übrigens wahrscheinlich noch recht übersichtlich, da ja nur die Links hinterlegt werden müssten ... und der Aufwand für die Einrichtung neuer Frameworks oder der Pflege oder Diskussion 'warum ist die nicht drin' entfiele in großen Teilen.

(BTW.: Was mir fehlt oder nicht weiß wie es ginge ist, in der WB-Installation eine eigene Bibliothek zu hinterlegen, die dann mit register_frontend_m odfiles() geladen werden könnte ... so könnte jeder selbst die JQ-Version aufrüsten oder gezielt andere Frameworks nachschieben die er braucht ...


(2)

Die Dateien, die Mod-Dateien, die von WB geladen werden könnten automatisch (jeweils CSS und JS zusammen) zusammengefasst und dann als eine Datei geladen werden. Im Prinzip Präprozessing wie bei SASS.

Ein Beispielscript dazu gibt es hier (habe aber keine Erfahrung damit): http://www.ejeliot.com/blog/72

Das könnte unterteilt werden: Große Frameworks separat (die müssen ja teilweise anders behandelt werden), alles andere wir zusammengeschoben ;-)

Schwieriger wäre Optimierung hinischtlich Punkt (C): Alle CSS/JS-Dateien der verschiedenen Einzelseiten zusammen zu fassen um sie in einer Datei zu laden. Da müssten wahrscheinlich die JS/CSS-Dateien aller installierten Module zusammengefasst werden ... wäre für mich aber zunächst eine nachfolgende Ausbaustufe und ich kann aktuell nicht abschätzen, ob das wirklich sinnvoll wäre.

jacobi22:

--- Quote ---aber auch an der fehlenden Bekanntheit von frontend_body.js
--- End quote ---
gibs aber schon seit WB 2.7.0  bzw seit 2009, steht im changelog und ist auch im Forum in diversen Threads zu finden

zum Rest: ich ahne schon, das das jezt wieder einer der sinnlosen Framework-Diskussionen wird und klink mich hier mal aus.
Nochmals mein Dank an euch für euren Einsatz

Yetiie:
Danke für den Hinweis zur Framework-Diskussion :-)

Ne, darüber (Frameworks) bitte nicht diskutieren. Es geht hier um Möglichkeiten der Optimierung zur Seiten-Ladegeschwindigkeit nicht um den Einsatz von Frameworks. Eine Bitte um Aufnahme spezieller Frameworks in das WB-Standard-Paket ist in diesem Thread außerdem NICHT gefallen ;-)

...

So: Es waren lediglich Anregungen zur (ggf. automatisierten) Ladezeiten-Optimierung.
Nicht mehr. Nicht weniger. Und auch das sollte nicht als 'Muss' verstanden werden ;-)

Die Idee der vereinfachten Einbindung von der Google-Librarie hat aber sicher einen Charme.
Auch wenn man den Link ganz einfach selbst setzen kann bzw. setzt ...

Und es ist (naja bei WB muss man sagen: wäre ...) mit überschaubarem Aufwand außerdem wieder etwas für's Marketing:
WB --> nutzt Google Libraries --> Google modern --> WB modern --> Journalisten und Blogs wollen Futter haben *g

Selbiges gilt auch für das ganz anders leider wohl nicht unaufwendige Präprozessing.
Das(!) wäre wirklich eine dolle Sache denke ich. Denn das ist ein Trend ...

DarkViper:

--- Quote from: Yetiie on November 17, 2014, 04:40:46 PM ---Ne, darüber (Frameworks) bitte nicht diskutieren. Es geht hier um Möglichkeiten der Optimierung zur Seiten-Ladegeschwindigkeit nicht um den Einsatz von Frameworks. Eine Bitte um Aufnahme spezieller Frameworks in das WB-Standard-Paket ist in diesem Thread außerdem NICHT gefallen ;-)
--- End quote ---
Es gibt auch für Frameworks keinerlei Diskussionsgrundlag e. Wir sind dabei, bei WB auf eine 100% komplette Trennung von Code und Anzeige hin zu arbeiten. Sobald wir diesen Punkt erreicht haben, interessieren uns keine Frameworks und keine optischen Trends mehr, da dieses dann einzig und vollkommen den Designern der Anzeigeschicht überlassen bleibt. X-beliebige Optik...  ohne auch nur eine Zeile des eigentlichen Quellcodes ändern zu müssen. Das ist unser Ziel.
Inwieweit hier die Addons (bis auf die Standardaddons) mitziehen werden, das liegt leider nicht in unserer Hand.

Manuela

PS:  Lokale JS- und CSS-Dateien jeweils zusammenzufassen ist kein Problem.. und auch bereits auf der ToDo. Beides in eine einzige Datei gibt Probleme, da dann 2 völlig verschiedene Mime-Typen in einer Datei vereinigt werden müssten... und DAS ist nicht trivial und überfordert die Browser, da diese Daten anhand des Mime-Typs bzw. des zu einer Datei gesendeten Mime-Headers einer Datei erkennen.
(binde einfach mal eine JS oder CSS Datei ohne Dateierweiterung ein... wirst sehen, dass das problemlos funktioniert)

jacobi22:

--- Quote from: Yetiie on November 17, 2014, 04:40:46 PM ---Und es ist (naja bei WB muss man sagen: wäre ...) mit überschaubarem Aufwand außerdem wieder etwas für's Marketing:
WB --> nutzt Google Libraries --> Google modern --> WB modern --> Journalisten und Blogs wollen Futter haben *g

--- End quote ---
Hatten wir gestern schon mal...
was für den einen ein Non-Plus-Ultra ist, ist für den anderen Murks. Es gibt im Forum gefühlte 100 Beiträge, in denen erklärt wurde, warum genau das (Google Lib) nicht angewendet wurde und wohl auch nicht wird. Ich bin mir z.b. sicher, das es auf Schlag hunderte Postings geben wird, das dieses oder jenes Plugin nicht mehr läuft. Der große Teil der aktiven Leute hier wird das handhaben können, aber die, die wirklich nur ein einfaches CMS bedienen wollen, die schon seit zig Jahren eine WB 2.6.5 laufen haben, stehen nachher eben hilflos da

Navigation

[0] Message Index

[#] Next page