Open thehabes opened 7 years ago
This is greatly exacerbated when on a slow internet connection. I have to assume users have been experiencing this.
There is standard formula causing this.
Recipe for load crawl.
We can only help with 2, but we can make a big difference with the experience there. Lazy loading would be the way to go, either automatically after some amount of time and pulling them in one by one one or two seconds apart, or by only loading once the user tries to click on an option from the drop down.
Since it is hardcoded, it makes sense to chain these calls instead of firing everything. In classic TPEN, I loaded a dummy iframe that was empty and put the src in only when someone calls on it. I think that would work fine here. The iframe needs to hold a loader spinny, but should be fine otherwise.
I can help with this if you like.
It is definitely in my back log, I have a couple days worth of stuff that takes priority. If you want to pick this up, go for it.
You will notice the iframes do not have src hardcoded. I hardcoded into an attribute like so
I can tell I modularized and timed the iframes' loading process to have a minimal effect on the UI. However, you can tell it causes the page load to crawl. Button hovers and clicks and stuff don't work for 6-7 seconds, or work very choppy or at a delay, as all the iframes are pulled in at the same time. Can we make the Iframe loader a bit lazier so it has less of a detrimental effect?
** Note that if in the first 5 seconds a user calls a a split screen, it always works. If we make this lazy, we could run into a race case with users trying to call a split Iframe that hasn't loaded yet, just something to keep in mind.