Do my users abuse the embed option in Experience Builder and Sites?

1119
4
02-25-2021 08:02 AM
JoëlHempenius3
Occasional Contributor II

Here is the case:

My users created an Experience with 6 pages.
Each page contains at least a Site 
Each of these sites contain either multiple webapp embeds, or another Experience with a Carroussel with multiple webapps, or multiple webmaps.

So I think there a at least 20 mapviewers active when a user opens all the pages.
There are complaints about performance. I took a look at it and it even made my Chromium Edge crash. A closer inspection using the developer console of Edge showed al lot of WebGL Errors and webassembly errors. And indeed, the performance was terrible. And after clicking a while through the pages some maps even crashed and the map wdiget only showed a grey square. 

Can somebody confirm?:
-All the Experiences, Sites and webapp embeds are embedded using iFrames and therefore all the webmaps are active at the same time (not visible at the same time) and therefore take CPU, RAM resources.
-This might cause the WebGL errors, because the JavaScript API was not designed to run 20 maps viewers at the same time...
-Experiences or sites should not contain a lot of maps?

What can I advise my users?
-How many maps / webapp or dashboards embeds is reasonable in a Site or Experience and should not give performance issues?
-Should I advice them to split the big experiene with multiple pages in smaller single page experiences and make hyperlinks between them using the button widget? This should refresh all window content when they switch page/experience and the sites will contain less maps, which should improve performance. 
-Any other advice?

 

-Joël Hempenius.

Languages: JavaScript, Python and Dunglish
4 Replies
EmmaHatcher
Occasional Contributor

I'm not sure if your goals with this Experience Builder are to showcase sites/apps, or to be more data-driven. If it's the former, a hub site would be much better suited to that goal. If it's the latter, you can better accomplish this by reducing the number of web maps as much as possible and using widgets to provide the same data views the multiple web maps and apps were accomplishing. One bummer is that there are many widgets in WebApp Builder that don't have equivalents in EB, as I'm sure your team has discovered, so if there are must-have widgets on the embedded apps, they might try a story map or hub site still as alternatives... 

I found a major drop-off in performance with a draft EB that included even just three web maps. Instead, I changed the design to a single web map and leveraged lists & filters to accomplish the same map views that I had been attempting using more of a tabbed approach with separate maps (and I can't overstate multiple web maps led to terrible performance for me). That massively improved performance. Even if you want to show different data in each view, rather than subsets of data, you can set up action triggers using a key field between the list and map that will return no results for whatever layers don't need to be shown.

The other thing to check is if the web maps themselves have good performance. If the final web map has large, complex polygon layers, for example, it might still be slow in EB until you take steps to optimize the web map's performance itself.

Hope that's somewhat helpful... I haven't used pages yet in EB though, so I'm not sure how that complicates the picture.

JoëlHempenius3
Occasional Contributor II

Thank you for your informative response.

I think they want to showcase web apps and maps, so following your advice they should stick with sites only and not use Experience Builder. Maybe they like the way you can shape the widgets and the freedom of placing them on the page. As far as I can see, this is only a feature of EB and not Sites.

Most of the webmaps had really good performance. However, there was one Webapp builder dashboard themed webapp with an timeenabled layer and a timeslide widget. When the user switched to the layer list widget in the map, the timeslider widget disappeard and this caused all data to be rendered instead of only the selected time. 

I will check with my users if it is possible to reduce the number of maps and will have a look at action triggers if they can provide the functionality my users want.

-Joël Hempenius.

Languages: JavaScript, Python and Dunglish
0 Kudos
EmmaHatcher
Occasional Contributor

You just reminded me of a great application the State of Alaska Dept. of Commerce utilizes to provide a series of web apps and maps using the Map Journal Classic StoryMap template. It's linked here in case it might be a useful example for your team!

https://dcced.maps.arcgis.com/apps/MapJournal/index.html?appid=3bfb4237e6304f9aa4029a01715e15f9

0 Kudos
JoëlHempenius3
Occasional Contributor II

The application looks great and a lot of effort has been put into this. However, this application is not without error either. When I open all the pages and load all the maps, it works fine (except for a layer missing error, but this error can be ignored). But when I go back to the first or second map, the basemap has disappeared:

JoëlHempenius3_0-1614582176444.png

Only the elevation is still visible. I reproduced this on two different laptops and both in Edge and Chrome. Zooming or panning on the map doesn't help, I cannot get the basemap visible anymore. 

On my old laptop, only the last two maps show the basemap after  a while. On my new laptop the last 5 maps still have basemap.

My laptops should be able to run this without error:
-AMD ryzen pro 4750H 8Core CPU, 32 GB RAM
-Intel Core i5 2Core CPU , 16GB RAM

Based on this, I think there is a limit of 10 maps in one page (storymap, Experience). If more maps are needed, the page needs to be refreshed by navigating to another page. This can be achieved by making multiple sites / experiences or storymaps and creating hyperlinks between them. Navigating from one to another will force the browser to release the resources used by the maps and apps on the first page and make them available to the next page, maps and apps. Downside will be that navigating back and forth will reset the state of the map or the app and users will have to wait a few seconds before the map or app is reloaded.

-Joël Hempenius.

Languages: JavaScript, Python and Dunglish
0 Kudos