Hi there - We did recently release deferred drawing to all apps on the main cluster. What you’re seeing should be intended behavior, but it’d be great if you could send us reproduction steps and an app name via direct message or bug report, so we can double check this isn’t a bug. Thank you!
1 Like
Hi @grace.hong
I do not believe it is a Bug. I do believe it is the intended behavior. My post was to request a feature addition which would after page is loaded entirely, to then have those hidden element data sources be automatically fetched without a need to setup workflows or other work arounds to achieve the same.
If the page gets loaded entirely with the deferred drawing logic, and the app page load has already benefited from the improvement this feature provides, and then subsequently fetches all the data needed for hidden elements, so that once those hidden elements are made visible, the data is already available and there would not be the lag time between when the request to the server is made, servers performance search, and the results are returned to client device.
3 Likes
Good idea. In some cases this could be wasted effort (which can still impact the UX experience if they are actively doing other interactions/workflows). So I think it may be prudent to add this as an optional feature on an element basis (maybe just for those typically heavy load items like RG and Search Boxes??). You may still decide some data could wait if it’s unlikely to be used or not part of important critical path workflows but could still cause unnecessary load.
2 Likes
Yeah. I don’t like the update. My one page apps feel much slower while using now. What a pain. I’m actually not happy about this update. We need a way to turn this off on pages where we don’t want it.
3 Likes
Same here. It does not perform better but worst.
It feels super sluggish on our side as well. Looks like is broken and then suddenly comes up out of the blue.
@grace.hong - Can revert this update back, please?
Or as @boston85719 and @J805 suggest to deactivate the feature on pages we don’t want to?
1 Like
Hi @boston85719 @avr @J805 @ryanck would you be able to submit bug reports for the specific apps (and their pages) that are exhibiting this behavior? Deferred drawing should only make your page loads faster, so we want to investigate your page load times and determine the root cause.
Also a point of clarification about Grace’s comment earlier - the behavior around Repeating Groups loading data only once they become visible predates the deferred drawing update release, so if you are seeing Repeating Groups becoming suddenly become slower to load that might indicate a bug (potentially related to deferred drawing)
1 Like
Hey @alex.stanescu 
Initial page load is faster. It works as intended. I just don’t want that behavior.
It’s almost like one page apps are useless now. I might as well go back to each page as an actual page. It takes the same amount of time to load now.
It’s on all of my apps that use one page apps. Now when I choose a different group to load it’s not as instant because it has to load once I make it visible now. I want it to load everything on page load so the app is fast after the initial load. Does that make sense? Maybe I’m not explaining myself clear enough. 
I’m also pretty tired of submitting bug reports because it takes so long to get past the first tier of support devs. Last few bug reports took over a week to resolve. 
5 Likes
Hey @J805 I fully understand what you are saying and we’re currently looking into what we can do. In the meantime if you don’t mind submitting a bug report (or sending me a DM with a sample app) that would be very helpful in our internal investigation! We have an internal mechanism for fast-tracking bug reports specifically requested by engineering so don’t worry about it getting stuck at first-line support 
2 Likes
The question, I when I decide to show an element will it be Fully loaded when it appears?
I absolutely hate when elements load on the page when it visible to the user. I want a way to hide the element until it is fully loaded then show the element without drawing performance from the site. Is there a way to do this? Will this do that?
No. I’m not expecting a quick response either. Sorry 
3 Likes
Hello there!
Just to be clear, are you asking if when you use a workflow to reveal an element whether that element will be guaranteed to have all of its data sources fully loaded and the element be in its final form before it is made visible to the user?
That would not be something that this feature enables. We have been looking into the feasibility of exposing a setting like that to users but that is a separate project.
We’re still looking into this and trying to identify the best path forward. I got @J805’s DM with the app (very helpful, thank you!) and either Grace or I will update this thread whenever a decision is made
2 Likes
Thanks for looking into it @alex.stanescu. It makes sense to have this for my index page but not helpful for my single page app pages. 
2 Likes
The work around I am taking as I do not expect there to be a fully satisfactory solution
Gets the benefit of the faster page load from deferred drawing logic and eliminates the issue of the hidden element data sources not being fetched until they are shown, so there is no lag time experienced by the user.
4 Likes
I am currently building out a project with hidden elements and this feature makes for a very poor user experience. Please enable a feature for us to disable the feature.
I have an element that is hidden. It has a datasource coming from a URL parameter. There is a delay in the data being visible after I make the main element visible and it really destroys the user experience since it causes a 1-1.5 second delay in when the data is visible from the point the element was made visible.
Prior to this release I never experienced the issue.
7 Likes
Hey everyone,
We’ve spent some time doing investigations (mostly based off of @J805’s app) and we have some updates we would like to share. First off, we did performance analytics both with deferred drawing enabled and disabled and determined that deferred drawing itself is only slowing down interactions post-load no more than a couple percent. However, we were able to identify the root cause of the slowdown (a separate issue) and are currently working on implementing a fix. Thank you all for pointing these things out!
To address some other comments / concerns I’ve seen popping up in this thread:
- This feature does not affect the timeframe for when datasources or element properties are evaluated. Most data sources (especially for repeating groups) have always been evaluated when those elements first become visible.
- Selectively disabling deferred drawing on a per-element is an interesting idea. As of right now it isn’t one we’re considering for a couple of reasons: it would add additional complexity to the property editor, and we believe once we push our fix, the benefit to element load speeds wouldn’t be significant .
We appreciate the feedback you all have given in this thread and we are continuing the conversation of what additional features we can implement to allow you to have more granular control over when data sources are loaded. We appreciate your patience while we work on a fix for the loading time issues that you have pointed out. Once we deploy our fix, we believe that deferred drawing will decrease both load times and interaction times in the vast majority of use-cases, but we will definitely want to know if you find that is not the case in your apps. Thanks again for all of the help identifying the issue here, and we will be sure to update you when our fix is live!
6 Likes