Best Practices zu Datenmengen umsetzen

  • Zumindest in der Vergangenheit war WoltLab kein Freund davon, die nun folgende Best Practice umzusetzen. Einen konkreten Vorschlag dafür gab es meines Wissens nach aber auch nie, deshalb versuche ich es hier einmal.


    Ist-Zustand

    Aktuell werden möglichst alle Assets, die auf irgendeiner Seite einmal benötigt werden, bei jedem Seitenaufruf geladen (bzw. beim ersten geladen und dann im Cache gehalten). Das führt dann auch dazu, dass ich beispielsweise beim Aufruf des Forums auch direkt alle Assets für beispielsweise die Filebase (sofern installiert) mit herunterlade. Ob ich diese dabei aufrufe, ist allerdings egal. Das führt zu erheblich größeren Datenmengen, die übertragen werden. Das ist insbesondere für Benutzer mit langsameren Leitungen, schlechtem Empfang oder auch leistungsschwächeren Geräten problematisch, aber auch für Suchmaschinen, die entsprechend große Datenmengen nicht gerade freudig gegenüberstehen – meiner Meinung nach zurecht.


    Weiteres Beispiel: Selbst als Gast lade ich das JavaScript für die Moderation. Das werde ich wohl nie benötigen.


    Wunsch-Zustand
    Das System erkennt, welche Assets (sowohl JavaScript als auch CSS, eventuell sogar Icons) für die aktuelle Seite erforderlich sind und lädt nur diese. Das führt zu einer drastisch geringeren Menge und Größe der übertragenen Daten und gleichzeitig auch zu wesentlich weniger Code, den der Browser interpretieren muss (und ja, bei der aktuellen Größe des CSS ist auch das von Relevanz).

  • Müsste man mal sicher die Frage stellen wieso Woltlab das so macht? Hat sicher einen Grund? Ich meine sie kennen ja die aktuelle Technik....

  • Ist das mit JS/CSS wirklich möglich, ohne statt 1-2 Requests > 5 Requests zu haben? Oder kann man das als 1 Request irgendwie live kompilieren.

  • Weil der Soll-Zustand Arbeit erfordert - und serverseitig Ressourcen.

    Ich frage mich ab und an, wieso du Woltlab in mancher Situation so negativ darstellst.... du nutzt doch die gleiche Software bei dir (Wenn auch abgewandelt?)

  • Ich frage mich ab und an, wieso du Woltlab in mancher Situation so negativ darstellst

    Das hat doch nichts mit WoltLab zu tun. Die Best-Practices um zu setzen erfodert wie MysteryCode schrieb halt einfach Arbeit, das kann auf jeden zutreffen. Und Kritik aueßern darf man ja gerade weil man dessen Software nutzt?!


    Unterstuetze den Vorschlag.

    Regards,


    Alexander / Aebian

  • Ich frage mich ab und an, wieso du Woltlab in mancher Situation so negativ darstellst.... du nutzt doch die gleiche Software bei dir (Wenn auch abgewandelt?)

    Wie Aebian sagt, es ist relativ egal um welche (kleine) Firma es sich dabei handelt. Hier entwickeln über die letzten paar Jahre gesehen hauptsächlich 2-3 Leute, zumindest kriege ich es von den dreien überwiegend mit. Da bedeutet eine große strukturelle Änderung nunmal Arbeit. Viel Arbeit. Viel Zeit. Und damit viel Geld.

    • Official Post

    Eine grundsätzliche Anmerkung von mir zu dieser Thematik: Beim JavaScript sind wir bereits mit 5.5 bemüht, die statische Bundle-Size zu reduzieren, in dem wir zukünftig mehr Module on-the-fly laden lassen. Auch gibt es mehr Abstufungen zwischen des "min"- und des "tiny"-Bundles, letzteres ist für Gäste und reduziert es nochmals.


    Unser Ziel ist es es, einen Mittelweg zu finden, der die Datenmengen pro Seite gering hält, aber auch die Navigation über mehrere Seiten hinweg berücksichtigt. Daher arbeiten wir stärker daran, die Bundles so zu wählen, dass diese möglichst nur Module enthält, die durchschnittlich auf einer Seite benötigt werden.


    Zum Thema HTTP/2: Es gibt auch hier einen "sweet spot" für die Anzahl der Requests, auch im Hinblick auf die Latenz zum Nachladen der Module. Die "dicken" Bundles gehen vor allem auf HTTP/1 zurück, bei dem die Kosten für zusätzliche Module unverhältnismäßig hoch waren ("TCP window scaling" lässt grüßen).


    Beim CSS ist das ganze noch deutlich komplexer, weil die Software aktuell nicht "ahead of time" weiß, welches CSS benötigt wird. Anders als in JavaScript gibt es keine implizite Logik zum dynamischen Nachladen von Inhalten, so dass wir das System an dieser Stelle grundlegend überarbeiten müssen. Das haben wir zwar grundsätzlich auf der Liste, aber eine schnelle "Besserung" kann ich aktuell nicht in Aussicht stellen.

  • Auch gibt es mehr Abstufungen zwischen des "min"- und des "tiny"-Bundles, letzteres ist für Gäste und reduziert es nochmals.

    Wird das dann explizit bei aktivierter "Seitenbeschleunigung für Gäste" greifen, oder generell im Gast-Modus, unabhängig von dieser Einstellung?

    Gruß

    Jörg

    (Jaydee)

    • Official Post

    Wird das dann explizit bei aktivierter "Seitenbeschleunigung für Gäste" greifen, oder generell im Gast-Modus, unabhängig von dieser Einstellung?

    Die "tiny"-Bundles gibt es nur für die aktivierte Seitenbeschleunigung, denn diese verhindert grundsätzlich, dass bestimmte Code-Pfade aktiv werden, für die das normale Bundle notwendig wird.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!