nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

New Map Viewer is super slow to load when WMS and WMTS layers are in the map

dougbrowning

I have a map with 300 WMS and WMTS layers from outside my org. I made the map in Pro and then published so that it was easy to add so many and so I could make nested groups easily. (they are for reference by year and can vary in use a lot)

All layers are turned off. Map Viewer classic loads them all fast no problem but of course there are no groups.

New Map Viewer totally hangs for several minutes. Sometimes I get a memory error and other times it finally loads but its super slow to use. I have a feeling the new map is trying to touch all the layers in some way.

Anyone know what is going on here? Why it is touching all the layers when they are all off.

Open to any ideas.

thanks

Find more posts tagged with

Mapping

Accepted answers

All comments

D_McRitchie

Hey Doug,

I think this will be the expected performance as even when the layers are turned off, the web map will need to make requests to these layers to have them available within the Web Map. In this case it will mean that every time someone accesses the map there will be 300 requests being sent out.

Generally I'd advise having no more than 10 layers within a web map, of course this can be subjective depending on the size of the data within each layer.

Differences between Map Viewer Classic and Map Viewer tend to occur due to the underlying JavaScript versions being used within both.

Hope that helps,

dougbrowning

These are Rasters by year so we need to have all the years in the map. WAB and Pro are ok with the map. Map viewer should not have to make a request until the layers are turned on right? Somehow Classic is fine with this so I was hoping the code can be corrected to do the same. This pretty much shuts our project down. Free JS web maps seem ok too.

Martin1

Hi David,

I notice a significant difference in performance between Map Viewer Classic and the new Mapviewer already when using one single WMS. I also think that this must be due to the underlying JavaScript versions being used within both.

However, is there solution to this? It is hard to explain, why the new version of Map Viewer should do so much worse than the classic one. Can we do something with the custom parameters maybe?

I am using the following WMS: https://geodienste.ch/db/av_situationsplan_0/fra

D_McRitchie

Hey Martin,

I gave this a test on both Map Viewer and Classic and didn't note any significant difference on my test environments.

Usually in these cases it is due to a difference in the JavaScript versions. The New Map Viewer tends to load features much quicker and more efficiently, however it does have higher hardware requirements with it. Can I just confirm if you are also seeing performance issues when loading Hosted Feature Layers and if your device meets the specs listed on the JavaScript requirements documentation?

If your device does then could you also ensure that your browser has hardware acceleration turned on?

Many thanks,

David

D_McRitchie

Hey Doug,

Map Viewer Classic has lower hardware requirements so I would suspect this is why the layer might be performing better on this. In terms of the requests, these will still be sent out to the layers when they are turned off, as the Web Map still needs to make requests to have these toggable within the layer selection pane.

Could I ask if you could confirm that your device meets the listed requirements on the JavaScript Requirements page and if you have any issues with loading an app that uses just a few WMTS layers?

Many thanks,

David

dougbrowning

I am our lead GIS person so I have a pretty big machine, 64 GB of RAM and 32 GB of video ram.

We have many reference layers in WAB now and all is fine for over 6 years. Making us pretty worried about the new map viewer honestly. We cannot simply reduce the number of reference layers are these are time series over a 37 year period. Then we have these 37 for each of 5 indicators. Plus we have fire, weather, Sentinel 2 imagery, the list goes on and on.

Again WAB and old map viewer work perfectly fine (as does Pro) so I think some adjustment to the new map viewer like lazy loads or something. Maybe 80% of the time the user will not even need these layers so it still seems weird to me to have to touch every single one of them. Also some sort of cutoff and not have it just try until the end of time.

I get what you are saying but there has to be more of a balance here. thanks

Martin1

Hi David,

Thank you for your suggestions.
The hardware requirements are no problem, my laptop is still pretty new. I also verified that hardware acceleration is turned on.

You should clearly see the difference in loading speed, when you zoom in very much and then pan around. For me Map Viewer Classic is much faster than the new one.

D_McRitchie

Hey Martin,

I took a look at this again and I am still getting the same performance between both the Map Viewer and Classic.

I would check to see if the issues are just happening on this one WMS on your device, or if it occurs for other WMS layers.

If it is happening on numerous layers then I would recommend raising a support case with your distributor. Key things I would recommend testing are if the performance is the same on different networks as well other types of data like Hosted Feature Layers.

I would also confirm that your network/firewall follows the domain requirements from the ArcGIS Trust site.

Many thanks,

David

RTPL_AU

@David_McRitchie Anything new to share?
I have noticed that when you have more than just a handful of external Esri REST services coming into a new map viewer it will start to grind when doing anything in the interface when interacting with our hosted feature services. (symbology, filters, grouping layers, etc).
The latest project has to overlay project data over various agency & department open data sources - and no we're not going to download it all and republish 🙂

You earlier mention a limit of 10 layers - Is that an official Esri position that is documented? Link or it doesn't count. Not sure if Esri UK is the same as Esri Australia (i.e. Esri in nothing but name) and caught in the middle between users and Esri Inc. but hopeful you have something to give this thread a decent conclusion.

It has happened enough that I feel the only common denominator is AGOL - different computers, different data sources (mix of Esri REST & WxS open data services by various agencies), internet speed increasing over time but currently 100mbit only. Cannot say I can see a difference compared to when we only had 24mbit.

EDIT:
Experience Builder apps' performance are fine - users use apps but I have to make the map to publish and it is my time that is compromised.

Classic Viewer didn't fall over so it must be a new thing - Maybe I should get ADSL again, run Classic Viewer on Internet Explorer on my old XP machine? Pity that won't work with the new feature service functions and Field Maps requirements....

Also refer to https://community.esri.com/t5/arcgis-online-questions/map-viewer-is-slow-including-setting-default/td-p/1188905
and the search that brought me here:
https://community.esri.com/t5/forums/searchpage/tab/message?filter=location&q=map%20viewer%20slow&location=category:arcgis-online&sort_by=-topicPostDate&collapse_discussion=true

Sorry I can't share a map - commercial in confidence etc. I'll see if I can find the time to build a map to share with dummy data over the government data but seeing as this is not an uncommon issue, maybe Esri could better document the exact constraints to Viewer performance rather than us trying to hunt issues blindly?

Something like - If you have a top spec PC and fast internet (100mbit+) then you should be able to load 10 external REST endpoints (examples below) + 10 organisation hosted layers.

These are typical web service sources we use A LOT :
https://spatial-gis.information.qld.gov.au/arcgis/rest/services/PlanningCadastre/LandParcelPropertyFramework/MapServer

https://spatial-gis.information.qld.gov.au/arcgis/rest/services/Economy/MinesPermitsCurrent/MapServer

https://spatial-gis.information.qld.gov.au/arcgis/rest/services/Environment/MattersOfStateEnvironmentalSignificance/MapServer

Regards,

Chris

dougbrowning

I can share my map to you if you send me your AGOL username and you can take a look and see the old vs new map viewer difference. It is unusable now. thanks

AnLizeGCC

Hi,

I'm just adding a bit to that topic, as I'm experiencing as well some major performance issues trying to migrate WAB apps to EB apps, on Enterprise 11.1 though. It's on an internal instance so cannot share at the moment. I have to try on AGOL. So a bit off-topic, but similar experience.

We have a generic map (classic web map) containing around 30 layers, some of them internal, other external, some light, others with a heavy load of data. That classic map is embedded into a WAB app to expose internally our data to staff. This runs perfectly fine and extra fluid.

Converting this to a Web Map and EB app, this becomes unusable. So laggy. I tried to recreate the maps from scratch, the slowness appears at some point with heavy layers.

On a Fibre company broadband with a high spec computer, so not a hardware nor connection issue. Just poor performance from the Web Map.

I've used in the past couple of years the JavaScript API 4.x, with heavy data as well and it didn't seem to be that slow. But for some reason the new Web Map cannot keep up.

For now, we cannot migrate from WAB to EB sadly, this is clearly not good enough.

AspenN

We are experiencing extreme slowness in Map Viewer when compared to Map Viewer Classic since upgrading to Enterprise 11.3. The slowness gets worse and worse as the number of layers increases, regardless of layer type/source. I am writing to see if anyone has updates or has found solutions to this.

BenBakerBSR

@DougBrowning I am experiencing similar issues with MapViewer. However, all my data is published and self-hosted within AGOL. These maps certainly have more than 10 layers within them! Open the maps within MapViewer can take over 15 minutes but my users consuming within Experience Builder don't have any rendering / opening issues. Experience Builder has 'Lazy Loading' which works perfectly, specifying only specific layers to render. But obviously is the GIS professional who suffers when they have to edit they map within MapViewer.

@David_McRitchie Wouldn't implementing a 'Lazy Loading' equivalent within MapViewer be sensible?

Thanks

Ben

D_McRitchie

Hey Chris,

10 layers is what I generally recommend, but it isn't a hard limit and not something that is possible to confidently document. The limit is dynamic and will be on a use case by case basis depending on the layer and map configuration. For example if we were loading a Hosted Feature layer with a few points, it will be a lot more performant than a large polygon layer with complex geometry. I have seen instances with 15 large services performing slowly, while in other cases Web Maps with around 60 layers have performed fine.

When starting out a new Web Map its good to go with 10 layers and see if performance is acceptable before adding additional layers.

Obviously, this can add a lot of complexity and potential red herrings in troubleshooting. A first step I usually use is to check if a new Web Map works with just one layer, then add services back in blocks to see if a particular service, or group of services is causing the slow down.

Web traffic is really useful, we can put exact time stamps for how long particular requests are taking, and observe where slow performance is coming from.

Republishing is a useful step, particularly if a service is coming from ArcGIS Enterprise/Server as it provides a new service, that isn't being used by other users. Often we can see that the tuning for a service is out of sync with what should be used as the service is seeing an increase in users.

Comparing Classic Map Viewer and Map Viewer can also yield useful results as we could be seeing an issue between the ArcGIS JavaScript SDK v3.x and v4.x. Generally from the performance perspective v4.x will subdivide query requests more, causing a large total volume of requests which typically is more performant, but can cause issues if there is an overwhelming number of requests coming in. This in my experience tends to be the case if we see identical services functioning fine in Classic Map Viewer.

In your use case Chris given that the services are external, I would suspect that perhaps these are Enterprise services that need additional instances assigned, or data that is in a different projection. Reprojecting on the fly can add significant delays in performance.

Hopefully that helps. If not then it is worth raising a Support Case. We occasionally do get performance issues and defects with the system and troubleshooting such issues can be easy, or very complex depending on the cause.

Thank you,

David

dougbrowning

10 is too few for just about every use case we have. Esp with reference layers. For sure needs to be updated and tested way larger than that. Not handling enterprise class size data has been Esri's biggest downfall for years. We broke WAB going over 250 fields once. Every single thing should be tested at 300 fields, 100 layers, and 1 million records before it ever gets released.

RTPL_AU

@David_McRitchie
To give you a useful example - we often want to use the reference layers published by Queensland.
https://spatial-gis.information.qld.gov.au/arcgis/rest/services

Typically topics in transportation, biota, enviro, economy (mining stuff), planning cadastre (properties).

Maybe add some items from contours, inland waters, farming, or flood lines.
Queensland is big so an infrastructure project may span a few hundred km and nearest towns/hubs another few hundred away again.
These are all large & complex datasets hence not wanting to download & re-publish as the benefit would not be there.
If you are mentioning the numbers 10 & 60 as your starting points I feel Esri lost the plot a bit as a constraints map could easily exceed that. Add the project specific data and you may have 10 in a specific feature service.

yes - we do make targeted and optimised maps but sometimes you have to add a lot of info to find context between constraints & a client can turn it all on or off themselves.

What I find strange is that the published web apps seems to work fine & old map viewer (bar incompatible features) also works fine but 'New' Map Viewer sucks on a potato.

@DougBrowning makes a good point about testing.

D_McRitchie

Hey Doug,

Understandably 10 could be more than enough, or too few layers depending on the use case. When requirements begin to get large it is vital that performance testing is done to ensure that applications and maps are performant.

300 fields and 100 layers is a large example. I would expect a web map to perform poorly in this context. Even with most layers' visibility disabled, that is 100 requests that are being sent out each time a user pans or zooms on the map.

David

D_McRitchie

Hey Ben,

That is interesting to know that we can get issues on Hosted Feature Layers as well. I wasn't actually aware that Experience Builder had Lazy Loading but that is really useful to know for performance.

I'm presuming we could load a lot of these layers in Experience Builder, and not note any performance problems until we try to interact with these (perhaps through a layer list widget?). While in Map Viewer we are getting slow performance when loading the map?

Could be one to log an idea on ArcGIS Ideas. For my understanding it would be good to know what happens if we check the Datastore metrics for the Organisation?

How about if we make a new Web Map and begin loading layers in blocks? Can we identify if any specific services, or types of data are encountering the largest slow downs in data? From what I usually see in cases reprojecting on the fly can cause bad performance. Occasionally rebuilding the Spatial and Field Indexes can help a lot, particularly if data schemas are frequently changing.

Happy to discuss further,

David

BenBakerBSR

Hello @David_McRitchie,

Yes, you are correct - the MapViewer and layers within can be consumed easily and swiftly with the Experience Builder as I have implemented the 'Lazy Loading'. Prior to enabling the 'lazy loading' functionality the Experience Builder also struggled with loading / rendering.

Please could you provide the link for where I can publish an idea on the ArcGIS Idea website? I have browsed the ArcGIS Idea pages but cannot find where I'm able to publish an idea for myself.

I have tried adding the same layers into a new MapViewer but these still encounter the same issue.

Many thanks,

Ben

BenBakerBSR

Here's what the Datastore metrics look like

L77

I created a thread about map viewer loading very slowly, before seeing this thread. I am attaching the link to my post in case anyone has any advice. Map Viewer is basically not useable which is scary because I am trying to recreate all of the work I already did in experience builder before web app builder doesn't work anymore.

https://community.esri.com/t5/arcgis-online-questions/automatic-fallback-to-software-webgl-has-been/td-p/1580584

DanLissick

I am experiencing the same issue. Below is Esri supports response:

SummaryDocumentation:

The information we received from internal is that this behavior is expected with 4x (i.e., the Maps SDK for JavaScript). Complex polyline and polygon layers are generalized to improve query time. This is different than 3x which loads these geometries differently.
We also see layers be generalized/optimized by default when they have more than 400,000 vertices to protect the organization's datastore. This is mentioned in our documentation here:
- Manage hosted feature layers—ArcGIS Online Help | Documentation.
From the example layer with which we've reproduced the behavior with in-house, we observed that it's a complex polyline layer that by default, has been optimized by the software upon publishing.
In general, we have the mantra of no more than one vertex per pixel at any particular scale, meaning that data is being generalized dynamically when being viewed. This isn't bluntly stated in our documentation anywhere, but this topic is touched on in the video resource linked below. Note the discussion at about 24:50 minutes in.
- Optimize ArcGIS Online Maps and Apps for Audiences of Any Size - Esri Videos: GIS, Events, ArcGIS Products & Industries
This blog also touches on a similar topic of discussion:
- Essential Configurations for Scalable ArcGIS Online Web Applications.
My colleague that I was working with has mentioned to internal that the difference between 3x and 4x loading should be documented somewhere - but they would also encourage you to leave feedback directly on our documentation using the 'feedback on this topic?' option on the Map Viewer documentation page as well.
Additionally, the reason that ArcGIS Field Maps and our other Mobile applications do not display the same behavior is because our mobile apps are not built on the same code base - JavaScript is used for web clients while our mobile apps use a product called ArcGIS Runtime or ArcGIS Maps SDKs for Native Apps | Documentation | Esri Developer.
The existing Enhancement requesting an improvement in how Map Viewer renders features upon zoom in is ENH-000163087, and has been attached to this case.

I've also provided the feedback you passed along to me in regards to this change and inquired regarding if escalating an Enhancement is possible.

Unfortunately there isn't a set process of escalating an Enhancement in the same way that bugs can be escalated - Our bug escalation documentation page states this directly. However some indirect methods of escalating it would include creating a post on our ArcGIS Ideas forum, which can bring additional views and attention to the issue as our development team does browse the ArcGIS Ideas forum. If you do end up doing this, if you can provide me with the link to the Ideas Page, I can directly attach it to the Enhancement to route other users that create cases for this issue to the same enhancement number.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.