Layout container: Can you make chart objects and KPIs load faster?
Hello,
In general, I find that the layout container generates its content quite slowly. Can something be done about it - or is it just the way it is?
I have attached a video that shows how slowly a dashboard made with a layout container is generated. As you may notice in the video each sheet has several actions that selects specific values in five different fields that then has an effect on the values generated.
Is this normal behaviour of the layout container? Or can something be done to make it load faster?
I would like it to load a lot faster since many of our users need to see 3-5 versions of this dashboard with different values of the fields whose values are set by actions in each sheet.
So you think / mean that default bookmarks would actually make the layout container load faster?
The default bookmark in this case needs to be dynamically set, and I can not seem to make it work. I need to set the value of 6 fields where the values of 5 of these fields will be different for different sheets for the same user.
The first field (where the value will be the same across the different sheets) is the initials of the user, where the field "Initials" needs to be set to: subfield(GetUserAttr('userEmail'),'@',1)
This expression gives me the right user.
I have made a variable: v_CurrentUser with the definition: subfield(GetUserAttr('userEmail'),'@',1)
I then have made a filter with the field "Initials" and in the search field of the filter I write "=Initials=$(v_CurrentUser)" - but no result comes up.
This is just the first of my problems with creating dynamic bookmarks.
Perhaps some one can help me out? But help is only needed if default bookmarks actually will make layout container load faster than by using sheet actions (where the field values currently are set - and it works).
This is rather old subject I would say and I would not blame layout container for this behaviour.
What is causing this issue is number of individual objects you are loading on the page effectively creating web browser traffic. I suggest you open chrome developer tools and see load time of those objects. It is not based on calc time of actual KPIs and it is limited to your network speed + number of objects.
We used to have the same issue and solution was to smarter use other objects like tables instead of individual KPI or text objects.
cheers
cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
I have not tried it without the layout container as I need the exact placement of objects which is only avaliable in the layout container (AFAIK).
I can not answer all of your other questions, though of course they are very relevant for the performance.
I am looking for general input about whether there are issues with the performance of the layout container. This is also because we have general landing page for our BI solution made in a layout container where only button objects (70+) are used, so no KPI's and thus the load time does not depend on any data model. This landing page does not load super slow but you can still see and follow how each button (more or less) is generated. And this behaviour has led me to ask the original question, since I now have a more complex dashboard made with the layout container adn with a data model, KPI's and thus dynamic calculations which of course leads to more time for generating the dashboard.
I have attached a video that shows how the landing page loads. The layout container starts generating from around second 5 and is then finished around 3 seconds later.
The problem is usually not the layout container object. The container is just a shell. The slowdown you are seeing is because the Qlik engine recalculates the entire data model and each affected visualization multiple times for each click.
When you navigate to a sheet that runs several actions (which select specific values in five different fields)
Since your container's sheets likely many objects, five sequential recalculations are causing the noticeable lag.
If the case we used to apply bookmarks.
If each "sheet" (view) in your container is meant to represent a predefined set of selections (e.g., Year, Q$ Data, XYZ, etc.), the absolute fastest way to apply those filters is with a Bookmark.
The bookmark stores the state of all selections across all fields. Applying a bookmark is one single action that triggers only one engine calculation.
I agree with your comment about each click and recalculating by engine, but...
In this particular case there is no lag on object calculation - you can see this on the short clip recorded. It is time of objects being loaded to the browser. Funny enough load time will also depend highly on object type you are loading. In some instances we were using button object instead of KPI object as there was significant difference in loading time of for example 50 kpi objects vs 50 button objects, despite each of them showing just a kpi value. In KPI object value would be shown as a measure and we had to use button object and have measure loaded as actual label of the button as that was loaded much faster. Strange, ain't it?
@blipblopdk - you can test this by simply creating a ctrl +0+0 app with super small dummy data model and 1 measure which you can put into 50 kpi objects and the same measures put as label into 50 button objects on another sheet. You can then measure your time in browser dev tools on how long it takes to load them and you will see the results. Also in dev tools you can enable/disable caching of objects loaded to browser so that you can have repetitive and comparative analysis done.
bottom line is - we have been there and have done this analysis already so we know that even with super simple data model the root cause of slow load is not in slow engine or calc time but actual web browser rendering time. I will be happy to be proved wrong 😑
cheers
cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
@Lech_Miszkiewicz - Yes, May be you're right that the lag isn't always in the computation (on the Qlik engine side), but in browser rendering and object initialization.
"The button is a simple object, when you place a measure in its label, Qlik can quickly display the result as basic text in the browser. This is much faster than loading a KPI object."
