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

Diskussion rund um JQ, JS und alles Mögliche

<< < (5/11) > >>

Yetiie:

--- Quote ---Das ist eine etwas akademische Diskussion hier..

--- End quote ---

Naja, das Thema Ladezeitenoptimieru ng ist wohl für die meisten WB-Seiten nicht relevant ... aber die Diskussion ist alles andere als akademisch sodern ist ganz real Umsatzgetrieben wie das Beispiel Amazon zeigt. Leider habe ich die Seite mit den sehr konkreten Testergebnissen der Amazon-Versuche nicht mehr gefunden, aber folgende Seite, die etwas andere Zahlen hat ist dafür sehr interessant und eindrucksvoll und da wird die Disziplin richtig lebensecht:

http://www.onpagedoc.com/blog/ladezeiten-testen-optimieren-100-millisekunden/

Da geht es dann nicht mehr um das Zusammenfassen, Cachen und Minifizieren von Dateien sondern teileise bis in die Laufzeitanalyse einzelner PHP-Funktionen und auch JS-Framework- bzw. JS-Modul-Lösungen. Naja, 0.2 Sekunden schnellerer Seitenaufbau bringen richtig Geld. Von dem so zusätzlich erwirtschafteten Verdienst eines Monats könnten wahrscheinlich viele hier das ganze Jahr oder länger leben :-)

Ob man in seinem Webprojekt von dem Hardware-Rand einer solchen verwendeten Technik profitieren möchte oder es bei dem Projekt nicht erforderlich ist bleibt ja Einzelfallsache. Aber spätestens wenn man mit WB einen sagen wir etwas ambitionierteren Shop aufbauen möchte (wobei WB dafür dann wahrscheinlich doch das falsche System wäre) lohnen sich Gedanken in dieser Richtung schon.




--- Quote ---Zusammenhängen von Dateien:
Auch das im Prinzip richtig. Allerdings muss man da im Auge behalten, dass ich ja nicht auf jeder Seite ALLES habe.
--- End quote ---

Ja, das ist es, was eine WB-Automatik wahrscheinlich etwas komplizierter macht. Günstig wäre daher die CSS- bzw. in separater Datei die JS-Dateien projektweit(!!!) zusammenzufassen (also nicht nach Einzelseiten zu unterscheiden) und immer komplett 'alles' zu laden. Nur dann funktionert der seiteninterne Caching-Effekt.

Dabei hat ein ein oder zweimal gebrauchter Bildwechsler nicht mehr KB als ein kleines Bild wenn überhaupt ... und über den Request hätte er beim Einzelabruf eine längere zusätzliche Ladezeit als die größere Datenmenge beim gemeinsam Laden zusätzlich erzeugt. Das projektweite Zusammenfassen ist übrigens bei vielen großen modernen Webseiten durchaus aktuelle Technik. Die großen Frameworks dann noch separat von Google holen ... und schon hätte man eine kleine WB-Ladezeiten-Optimierung fertig.

Für eine WB-Optimierung würde das dann wahrscheinlich bedeuten, dass die Mod-CSS- und Mod-JS ALLER INSTALLIERTEN Module (bis auf die Frameworks) in (zwei!) Dateien gepackt werden müssten ... ein Kennzeichnungssyste m: 'diese Moduldateien separat laden' würde das wahrscheinlich schon wieder verkomplizieren.

Eine mögliche automatisierte Datei-Minifizierung wie bei SASS würde ich da übrigens rauslassen ... da das in Einzelfällen Probleme mit sich bringen soll soweit ich (allerdings nicht wirklich genau bzw. sicher) weiß. Aber die Dateien können in den Modulen ja schon minifiziert hinterlegt werden.

fischstäbchenbrenner:
Natürlich ist geringe Ladezeit wichtig, wobei man da aber nicht gerade Facebook oder Amazon als Messlatte verwenden sollte. Das ist schon etwas unproportional..
Für den typischen Websitebetreiber spielt es keine Rolle, solange die Ladezeit nicht nervt.

Oft sind es die Latenz-Zeiten beim Provider, die wirklich auftragen. Schnellerer Server = mehr Kosten = naja, eh nicht so wichtig...
Eine "Lösung für alle" wird unterm Strich kaum Einsparungspotentia l bringen, weil es wiederum die Latenzzeit etwas erhöht.

Und jemand der sich wirklich damit befasst, findet auf jeder Website genug individuelles Optimierungspotenti al.
Ich hab zb WebsiteBaker.at auf responsiv gemacht - für gerade mal 5% der Besucher. Nachteil für ALLE: keine Größenangaben bei Bildern, dh langsamerer Aufbau, weil erst die Bilder geladen werden müssen. Sicher keine Beschleunigung. Na und? Ist halt zeitgemäß, sagt man so.

Einsparungstipps:
Kopiere alle CSS der Module, die häufig geladen werden in deine template.css und benenne die frontend.css der Module um. Das selbe mit den frontend.js. Dauert: 3 Minuten.

Luisehahne:
Hallo Leute,

ich habe zwar nicht alles gelesen, ist ein bisschen viel  :-D, aber ein Beitrag ist mir aufgefallen.


--- Quote from: dbs on November 18, 2014, 06:42:25 AM ---Moin, ich versuchte mir vorzustellen wie es wäre mit

--- Code: ---register_frontend_modfiles('jquery','google','1.8.3');
--- End code ---

Auf jeden Fall ist es sprechend und inzwischen für mich auch ansprechend.
Für den Fallback wäre natürlich Manu zuständig. *g*


--- End quote ---

So ähnlich habe ich das bei mir gelöst, allerdings ohne Versionsnummer:


--- Code: ---<?php
  register_frontend_modfiles('jquery','south-street','CDN');

--- End code ---

oder


--- Code: ---<?php
  register_frontend_modfiles_body('jquery','south-street','CDN');

--- End code ---

Der Parameter"south-street" bindet das entsprechende Theme (ui.min.css) ein

eingelesen werden die Parameter in der function bind_query (framework/frontend.functions.php)  indem ich die Funktionsargumente abfrage, und entsprechend einen Schalter setze.

Eine andere Möglichkeit wäre die Versionsnummer, Urls, usw.  über eine jqeury.ini, die im Templateverzeichnis liegt,  festzulegen

Der Designer hätte dann die volle Kontrolle welche Version, welches Theme und von wo sollen die Scripte geladen werden. Würde auch die Übergabe von Argumenten überflüssig machen.

Sollte dss sinnvoll sein, werde ich mich für eine Umsetzung in der kommenden 2.8.4 einsetzen.

Wäre gut, wenn alle Module auf Inline Scripte verzichten würden.  Somit könnten Jquery und ModuleScripte vor Body Ende mit register_frontend_m odfiles_body() eingebunden werden, was sich wahrscheinlich auf die Ladezeit auswirkt.

Dietmar

fischstäbchenbrenner:
Naja, die VOLLE Kontrolle habe ich, wenn ich das alles selber mache.
Zumindest muss ich dazu keine Dokumentation lesen und wenn mal was nicht funktioniert, kann ich es sofort selbst reparieren, ohne im Core herumfrickeln zu müssen.

Abseits der Diskussion um technische Machbarkeiten sollte man den praktischen Nutzen nicht aus den Augen verlieren.

DarkViper:
Chio, da stimm ich Dir sogar zu 100% zu.. ;-)
Ich möchte keine halbgaren Krücken zur Verwaltung einer undefinierten, sich laufend ändernden Menge an Frameworks etc. im Core integrieren...  die letztlich doch wieder durch manuelle Eingriffe korrigiert und angepasst werden müssen.
(und ob ich einem Dau jetzt die X Parameter irgendwelcher Funktionen etc. erklären muss, oder das Include einer JQ-Datei... schenkt sich nichts)

Core ist Core und Präsentationsschich t ist Präsentationsschich t.
Für ersteres bin ich zuständig und für letzteres zu 100% der Designer.
Ich stelle einen vollständigen Satz Daten zur Verfügung, sorge noch für Variablenübergabe von PHP -> natives JS fertig... und der Designer kann absolut frei entscheiden, was er zum Aufbau der Anzeige damit anstellt. Er entscheidet auch, ob und welches Framework etc. er wo und wie einsetzt. Das geht mich auf Core-Seite rein gar nichts an.

Manuela

Navigation

[0] Message Index

[#] Next page

[*] Previous page