Mit einer Kombination aus neuer Logik und prefetch sind KreiseRouter jetzt unter der Wahrnehmungsschwelle von 100ms angekommen. Die Seite lädt nun im Hintergrund ein paar mögliche Routen pro Controller-Ebene vor, für den Client wichtiger war aber, dass das Frontend jetzt keine Renderfunktionen mehr unnötig doppelt ausführt.
Ähnlich wie im Backend wird jetzt von hinten nach vorn gestapelt und nur gerendert (und auch nur dann die Funktion überhaupt als import geladen) wenn sie nicht schon gesetzt wurde was 2-3 roundtrips unnötig macht. Initial und bei dynamischen Klicks muss nun garantiert immer nur 1 bis maximal 2 Mal der Server kontaktiert werden wobei der 2. Request über HTTP/2 beliebig viele Assets und Chunks holen kann.
Bislang war notwendig einzelne Views nachzuladen oder erst pro Controller-Level das Skript zu holen und dann zu gucken was noch nachgeladen werden muss - das wird jetzt direkt übermittelt.
Die Konsole hat einen Benchmark eingebaut, mit Fiber schaffe ich 40-80ms pro Route.
🚀 🌱 Initial: 327.08ms (Logic: 326.32ms | Render: 0.76ms)
🚀 🧭 Navigate: 57.87ms (Logic: 56.81ms | Render: 1.06ms) - easy route but another controller (prefetched though)
🚀 🧭 Navigate: 62.75ms (Logic: 61.92ms | Render: 0.83ms) - non-prefetched subcontroller
🚀 🧭 Navigate: 76.00ms (Logic: 74.84ms | Render: 1.17ms) - non-prefetched view (privacy has 1 await impor)
🚀 🧭 Navigate: 41.96ms (Logic: 40.12ms | Render: 1.84ms) - a blog post, here the css and js is already known so its mostly 1 fetch for the blog post itself.
Ich würde argumentieren, dass es eigentlich nicht schneller geht, denn alle Routen sind jetzt single-fetch, alle renderer laufen exakt so ab wie nötig und auch die Module kann ich unmöglich noch effizienter laden.
Zudem nutze ich keinerlei Frameworks, alles Vanilla JS Code, daher auch sofort lauffähig.
Wer es trotzdem noch besser weiß - ich bin lernfähig!
... und wer eine Seite haben will die trotz komplexer Routen nicht langsamer ist als ein oder zwei Pings - der kann mich gern beauftragen.