What might be causing slow loading (in editor and front end)? Cumulative image upload limits?

1143
6
02-01-2024 06:39 AM
MackenzieCope
Occasional Contributor

Hello Community! 

I'm hoping people will have ideas on how I might solve a loading and performance issue I have come across a few times now in various experiences I've built. Our content-based experiences (based on a publication or something similar) typically contain a few pages (up to 10) that have plenty of content, images, and some interactive maps. It gets to a point where the ExB editor (in AGOL and Dev edition) and front end will start slowing down, especially when you're selecting or uploading new images.

We are doing final testing on our latest experience and have found that the experience won't ever finish loading on tablet and mobile devices and is slow to load on desktop. Because we came across this issue last year, we've been careful to use only reasonable-quality images to not overload the experience but it didn't help.

https://geology.utah.gov/apps/roots/

Has anyone else seen this issue and have ideas on what might be causing it? I have some ideas:

  • Is it the amount of photos saved in the library?
  • Should I be using the upload via URL option or does it not make a difference?
  • Is it the amount of photos on any given page (even if it's the same image in multiple places like an icon)?
  • Are there image upload limits besides per image? (if yes, how can I see that? or is there documentation with upload limit recommendations?)
  • Is there a completely different cause like the amount of pages or text or interactive maps or something?

I'm also submitting a ticket about this issue with Esri, but I'm desperate for any ideas as we're on a time crunch! Thanks!

0 Kudos
6 Replies
KenBuja
MVP Esteemed Contributor

Start by exploring the network traffic to see how much time it's taking to get all of the items. At a quick first glance, it's taking 35 seconds to download the config.json file. That's a very big file, containing many layouts and widgets.

time1.png

Look at the images that are getting added. It's taking three seconds to download one image. Do you really need an image to be that size? Instead, use a thumbnail with a link to the full-sized image.

time2.png

 

MackenzieCope
Occasional Contributor

Thanks for the reply, @KenBuja! You have some great ideas and probable causes. I wonder if there have been any established file size recommendations for the config.json file? I didn't know that that file contains all the layouts and widgets and that it might be an indicator for experience size limits...

Also, yes, the image sizes don't need to be that big. Most of the figures are coming from a print PDF so we've tried to reduce a lot of the images' sizes, but we could maybe do more reducing or just cut images from the experience.

I also wonder if we had uploaded images by the URL option if that would've made a difference? Do you know anything about that?

Thanks again for your reply! Very helpful!

0 Kudos
JeffreyThompson2
MVP Regular Contributor

I ran a load test on both my desktop and Surface Pro. On desktop, the site loads in 4.3 seconds and the Surface loads the site in 5.2 seconds. Personally, I would consider these load times slow but acceptable.

Great website. I have a Master's in Geology. I kept getting distracted by the content, making it hard to investigate the problem. Keep in mind that the rest of this is all speculation by a guy who has taken many college courses in rock and none in computer science.

I think you are running into a major design trade-off built into React. (Experience Builder is based off the React framework.) React loads everything needed to render a site, for all the site's pages, when it is first loaded. This makes can really bog down the initial load times, but it makes switching pages or loading additional elements lightning fast. Additionally, everything in rendered client-side (i.e. the user's computer), making load times highly dependent on the speed of the user's hardware and internet connection. 

Using the URL option to upload images should help as the image will be rendered server-side by the separate site in the URL and the image will not have to be transmitted to the user in that initial load.

Your site does not appear to have much interconnectivity between its sections. For example, the Wasatch Fault section does not need to send data to the Southern Utah Faults section. It might be possible to break apart your site into small chunks in separate Experience Builder/StoryMap projects and then use the Embed Widget to stich your site back together again. I think this should off-load portions of the site to multiple servers and Experience Builder would delay trying to load the embedded sections until they are actually needed. I have not tried this personally and it would be a major re-design, but I think it should speed up the initial load at the expense of slower rendering when the embedded section is needed. 

GIS Developer
City of Arlington, Texas
MackenzieCope
Occasional Contributor

@JeffreyThompson2, Thanks for your reply! (I'm glad you like our experience! It has some really great EQ info, I don't blame you for getting distracted!)

Your idea to split out sections or pages into separate experiences is a solution we used when we ran into a similar issue last year. Besides the work it would take to do that, it also messes with our Google Analytics tracking with embedded experiences. Maintaining multiple interconnected experiences, storymaps, etc. is not ideal for this project, but we may have to go that route anyway. I'm glad you mentioned it. (if anyone is curious, this is our project that splitting out full pages worked for us: https://geology.utah.gov/apps/energy-resources/)

Do you (or anyone else perusing this thread) know for sure if using the image URL upload option would help? I could switch out all the images in the experience with ones living on our server if I knew for sure it would solve the issue.

Part of that, do you know if the images are uploaded to the experience using the URL option? Or do they get pulled dynamically from the URL location on page load? If they're getting uploaded to the project files anyway, switching out images and using the URL option wouldn't matter, right?

0 Kudos
JeffreyThompson2
MVP Regular Contributor

@MackenzieCope Don't send me another geology site. I'm trying to get some real work done. There goes my afternoon.

The image URL option is dynamic, so it should reduce your server load. Consider trying a third-party image hosting service like Cloudinary.

GIS Developer
City of Arlington, Texas
MackenzieCope
Occasional Contributor

For those subscribed to this thread or encountering the same issue, I have an update.

I submitted a ticket to Esri and they said the amount of photos uploaded to the experience was too much and the main cause of the loading issues. They suggested like @KenBuja and @JeffreyThompson2 did to host the images elsewhere and use the URL option to add images.

I switched out all the photos for ones hosted on our server and the loading performance is better, but still has major loading issues on mobile devices. https://geology.utah.gov/apps/roots/

I'm probably going to reopen my ticket with Esri and see if they have any other ideas like the amount of widgets? We do have long pages with lots of widgets and customizations for tablet and mobile versions. I really don't want to cut down on content, but if widgets are causing the issue, I may have to do it anyway.

If anyone has other ideas to try, I'll do anything to try to save the project at this point.

0 Kudos