Select to view content in your preferred language

Testing page load performance

389
3
04-27-2025 04:33 PM
Labels (1)
DustinEdge_Boroondara
Regular Contributor

Hi Brains trust

Hoping you can help. I released our corporate "big viewer" using WAB (ExB does not offer the same functionality) and I'm getting woeful load times. 

The website developer suggested using Lighthouse (in Chrome) to test the page. But I seem to get very varying results from it. Ranging from 20 to 40s to a totally random 91 that I was not able to replicate.

So what can I use to confidently test the page?

Yes, the wab has close to 50 services but that's expected for the various data themes and imagery.

I then tried grouping them all together and came down to 6 services (as map services) with all the imagery (hosted on our own Image Server).

Still woeful.

Any suggestions on what I can use to test it and figure out what's killing the load times?

 

0 Kudos
3 Replies
Laura
by MVP Regular Contributor
MVP Regular Contributor

Switched services from dedicated to shared and vice versa helped with my load time. 

0 Kudos
DustinEdge_Boroondara
Regular Contributor

I did that. Even cached the first service that is used by wab. It seems like the the underlying javascript for wab seems to fall over itself at times..

DanLissick
Regular Contributor

I am seeing the same issue. Here is the explanation for Esri:

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:
  • 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.
  • This blog also touches on a similar topic of discussion:
  • 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.

0 Kudos