I have a page with several different functionality items on the same page. The prep has nothing in it. Based on inputs to the page one of 5 web blocks may load. Each web block is under an if so that on load, only one of the web blocks will load. However, even with the web blocks all under if's the initial load is still long because the web blocks are there - even if they are under if's and not being shown. We tried deleting all except the one web block we know would be loaded and initial load went from 9 seconds to 3 seconds so we know its because they are there, even if they are not being currently shown. Is there a way around this? Yes, I can make 5 different screens but trying to avoid that.
What version of the platform are you running? What version of Service Studio?
Can you share a minimal OML that reproduces the issue?
If you're able to reduce load time by 6 seconds by deleting the web blocks, one thing I would be looking at is what is causing the individual web blocks to load slowly? Are you doing a lot of work in the preparations?
You should also check the warnings/errors tab in Service Studio, in case there are recommendations that may relate to performance. You might find that performance optimization in your web blocks is a more effective means of addressing the problem.
G. Andrew Duthie wrote:
Reducing the load time of each block is a worthwhile effort and that is our next step - however the base question is still if something is under an if and not currently being displayed why is it still taking load time when the page loads. I thought it might be because the items under the if were named - and therefore had to be loaded in case of ajax refreshes but I just removed the names and still did not decrease the load time.
Server Version 11.0.212.0
Studio 11.0.511.0
So, I tried a simple repro, using a web block containing a preparation that uses a forge component to artificially pause execution for 5 seconds.
I put 4 If blocks on a screen, tied to 4 boolean local variables, all of which default to a value of False, and put an instance of the web block in the True placeholder of each If.
With all local variables set to the default value of False, the page rendered instantly.
With a single variable assigned the value of True in the screen preparation, the page rendered after approximately a 5 second delay. Each additional True value for the variables underlying the If blocks resulted in an additional 5 second delay in rendering.
So for my test, when the web block is inside an If that evaluates in a way that does not render the web block, it has zero impact on screen rendering and load time.
Again, it would be helpful if you could share a simple repro, as an OML, as there may be something you're doing that is resulting in the web blocks always executing, even if they're not visible on-screen.
You are correct that the prep logic does not run for these blocks within the blocks. That is not what appears to be the issue.
The ASP/ASCX files of our primary web application consists of approximately 37MB. To better serve our customers we allow them to choose from 5 different templates, with about a dozen different blocks. (Which themselves contain dozens of other blocks)
In order to allow a database driven model for the users to choose and manipulate these blocks, we must have all of the available blocks inside 1 'master' block, and the database values determine which block is loaded in which location of the template. This allows nearly all of our functionality to be accessed via the dashboard.
Unfortunately, from looking at the straight ASP/ASCX code, ALL code for ALL blocks on each page and block is generated on the page load. It's not running any logic, but it is compiling all of the code for that logic into the central page when the ASPX is loaded.
So instead of 1 page loading 8 blocks (with an avg of 5 subblocks each), we're loading 5 dashboard layouts, with 8 blocks each, and loading 12 blocks in each of those 8 blocks, with probably 5 blocks average in each of those 12.
At this point, instead of loading 40 blocks in an ideal situation (which is all you ACTUALLY see when the page loads) the code loads 2,400 blocks of code.
Math Follows:
Ideal: 5 avg blocks for8 total dashboard blocks in a single template
=40 loaded in an ideal world
VSWhat Happens:5 avg blocks, per12 'all available' total blocks per8 total dashboard blocks loaded for each 5 possible dashboard layouts.
=2,400 loaded via the ASPX
All - I plan on making a separate PSA post about this shortly as well as making an idea request however I wanted to put this information here in case anyone else finds it. So I did hear back from tech support and we were correct that if you have an if, BOTH branches of the if DO get evaluated and are part of the code that gets sent to the browser even if they are not rendered in the HTML. This is directly from OutSystems tech support and this was described as the system operating as expected. I disagree with this as in any other language if you have an if you only expect one branch of that if to be evaluated and used based on the if condition. This was causing our page to load extremely slowly as stated in the first comment on the post. I am hoping that we can find a work around for this on our page and as stated I want to get the word out about this through another post as well as making an idea request to not have this happen.
@Jason - what controls the navigation between the blocks? Following @Duthie's lead, I created an example that verifies your observation and proposes a workaround.
What I've seen is that the "Visible" flag on a web block or container simply uses "style='display:none'" to hide the element from display - so any data it needs would indeed be loaded. The trick is to load just the data you need in a preparation for the screen, for example based on an input variable (query string param).
I can think of some other ways to address, but this should solve your short term pain.
You seem to have the issue figured out, but I'll tell you a story about this issue anyway. Once I worked on a project that was trying to build a CMS using OutSystems; the CMS worked by placing elements (text, images, video, carousel, timelines, etc.) on a page and those elements were mapped to web blocks.
The rendering of these elements was done through a web block that contained 40 IFs, each with a web block inside its True branch.
Our tests showed that just rendering a single page like this would use 100% of the server's CPU for a few seconds. With 4 concurrent users our server would become unresponsive.
We had a meeting with a few people from OutSystems who explained that this architecture caused massive rendering overhead from merging and managing the viewstate among all the webblocks.
To try to salvage the project, we ended up changing our approach, saving the HTML content of a CMS page to the database and implementing any dynamic behavior through JavaScript.
João Pedro Abreu wrote:
We are doing something similar - it looks like the renderwebblock() removes all the overhead because basically in the prep of whatever block you want (however deep you want to go) you decide what block is going to be displayed, render the html for that block and display it. So any one block could be 100 if's, each if a block and because you are not referencing the blocks themselves it looks like it bypasses the problem. Now if you load one that has 100 in it you get the same problem but then it becomes a question of where to put the render(s).
So we tried the RenderWebBlock() action and it does make the html for the web block however then on-change actions, buttons etc do not work. So this is not a viable solution. OutSystems is still looking for a possible work around.
Hi Jason,
I'm currently facing a similar issue involving blocks inside IFs and load times. Were you able to work around this issue?
Aurelio Junior wrote:
Aurelio, no solution in normal web. From what I have seen if you rewrite the page in the new react is "should" speed it up as the react has no viewstate that is being created.
Jason Herrington wrote:
Oh - well one solution is to take the page and split it into multiple pages with forwards to other pages depending on what you want to show. That is the only solution in normal web - have less stuff on any one single page.