Stop redrawing the screen. It seems each time someone clicks on anything you get a document (however small) from your cdn and redraw the whole screen. Why make me inspect local in-memory and disk caches as well as fetch a document off the cdn? Why not load everything up front (using whatever bundler) for the route you're on (for example /spells) and never force the browser to do all that labor? At work, I'm also building a new (web) application, but the product manager would kill us if we delivered something that redraws this much, it would never get signed off on. Clicking on Bard to filter the Spells, Chrome Dev Tools, Network tab:
66 requests, 8 are actual network requests, and 58 are cached either in memory or disk. This number does get reduced to 4 network requests with repetitive visits to the same filter, with the following effect:
You never needed to make more than the built in pre-flight request and then request for the data, so 2 request were actually necessary max, and frankly none were necessary if you either had the data in the initial payload or lazy loaded it once the page rendered and the user has no idea you're making network requests in the background.
Maybe you already have a plan to not make the user endure the screen redraw (which I have yet to test on a phone, but you can only expect the performance to get worse), I don't know. It does seem weird to say you are using an in-house framework when Cobalt CRM which you are using is a Joomla CRM plugin. Have you guys not considered the current generation of frameworks for front-end binding?
It's not Cobalt CRM for Joomla. Cobalt is our internal project name for our framework that's built on .NET MVC. Our front-end engineering team is in the process of upgrading the existing client-side parts of the framework, that will affect not only DDB, but most of our other sites running on the same stack. However, that will be a multi-quarter project and will take time to roll-out.
Ah, my bad on the Cobalt front then. Just left the .NET MVC world. Now I get your caching strategy. Best of luck to them upgrading the front end and as a potential D&D Beyond customer, I'm hoping that portion comes sooner rather than later. If they are still in the research phase, may I suggest the latest Angular on the front end, it's fairly easy to work with and for your use case (lots of read data), it can be blazing fast. May you leave the monolith behind you.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I ask so I don't provide feedback about bad UX unnecessarily as it's something you won't be able to change.
We use an in-house framework, so we can pretty much change whatever we want. Suggest away!
I am the Inquisitor Imperitus. I am judge, jury, and executioner. Draw your last breath now, as I send you to the Nine Hells.
Stop redrawing the screen. It seems each time someone clicks on anything you get a document (however small) from your cdn and redraw the whole screen. Why make me inspect local in-memory and disk caches as well as fetch a document off the cdn? Why not load everything up front (using whatever bundler) for the route you're on (for example /spells) and never force the browser to do all that labor? At work, I'm also building a new (web) application, but the product manager would kill us if we delivered something that redraws this much, it would never get signed off on. Clicking on Bard to filter the Spells, Chrome Dev Tools, Network tab:
66 requests, 8 are actual network requests, and 58 are cached either in memory or disk. This number does get reduced to 4 network requests with repetitive visits to the same filter, with the following effect:
You never needed to make more than the built in pre-flight request and then request for the data, so 2 request were actually necessary max, and frankly none were necessary if you either had the data in the initial payload or lazy loaded it once the page rendered and the user has no idea you're making network requests in the background.
Maybe you already have a plan to not make the user endure the screen redraw (which I have yet to test on a phone, but you can only expect the performance to get worse), I don't know. It does seem weird to say you are using an in-house framework when Cobalt CRM which you are using is a Joomla CRM plugin. Have you guys not considered the current generation of frameworks for front-end binding?
It's not Cobalt CRM for Joomla. Cobalt is our internal project name for our framework that's built on .NET MVC. Our front-end engineering team is in the process of upgrading the existing client-side parts of the framework, that will affect not only DDB, but most of our other sites running on the same stack. However, that will be a multi-quarter project and will take time to roll-out.
Thanks for the feedback!
I am the Inquisitor Imperitus. I am judge, jury, and executioner. Draw your last breath now, as I send you to the Nine Hells.
Ah, my bad on the Cobalt front then. Just left the .NET MVC world. Now I get your caching strategy. Best of luck to them upgrading the front end and as a potential D&D Beyond customer, I'm hoping that portion comes sooner rather than later. If they are still in the research phase, may I suggest the latest Angular on the front end, it's fairly easy to work with and for your use case (lots of read data), it can be blazing fast. May you leave the monolith behind you.