we're developing a small web application with the sole purpose of displaying a map and some features fetched from a feature layer service. We're using webpack with esri-loader and load all esri modules at once at the beginning. The website is served from S3 via CloudFront over a corporate wireless network to a laptop.
Here are some timing values:
Now if we simulate a mid-tier mobile device using Chrome's Developer Tools (throttled CPU & network, increased latency) the time until the first data access increases to 12s with Esri's CDN (Chrome Mid-tier ArcGIS-CDN.PNG) or 10s with our custom build (Chrome Mid-tier Custom-Build.PNG).
Loading the website (no basemap, no data access) takes about 4.5s and then it needs another 5.5s processing time until the first data access.
I have a strong suspicion that it is dojo or the ArcGIS JS API that causes this delay because Chrome's profiler tells me that the interpreter spends a lot of time in dojo.js (dojo-profile.PNG, note: no cpu throttling in this case).
I think Chrome's Simulation seems reasonable because using my private smart phone over mobile broadband takes about the same time to load the Website.
Is it possible to speed up the loading time any further or is this as good as it gets? (the custom build was made using the attached build.profile.js)
@egubser I do have some suggestions.
>>We're using webpack with esri-loader and load all esri modules at once at the beginning.
I have a number of initial thoughts:
1) Where possible, use a lazy loading pattern with esri-loader for modules you don't need immediately. Excellent that you are experimenting with both the built version and comparing it with the CDN. Also try to lazy load any other resources (images, 3rd party libraries, CSS) that aren't needed immediately.
2) There are approximately eight .PNG images that are loading slowly, for example: 46129.png and 46128.png. Are these your own custom images? 46129.png is 46.4KB took 296ms using Esri CDN. If these are your own images you can try to optimize them, or lazy load them if you don't need them immediately.
4) I see quite a few queries. If possible look into optimizing how many features are loaded on initial load, or perhaps lazy loading feature layers.
thanks for your suggestions.
2) These are the basemap tiles coming from a third party. We are currently in the process of replacing them with our own.
4) Indeed, we can avoid two or three of these queries. (Note that those queries and basemap images are not included in the loading time.)
I think the problem that Elio is refering to is not related to networking (though it is important to optimize here and your suggestions are very helpful).
At the moment, I have the impression that there is no way to improve the client processing time because of the way dojo works. If we want to decrease the initialization time for this webmap, we need to say goodbye to the ArcGIS JS API and use Leaflet with tools to work with ArcGIS services. Am I wrong?
Stephan, Elio, I have more questions for you, but it might be best to take this conversation offline so we can quickly and more thoroughly dig into your observations and use cases.
There may be a variety of things we can look at. All web app performance tweaks come with both pluses and minuses and should be explored very carefully. What works on some devices may not work so well on other devices, etc.
In the meantime, do you have sample code you can share? And, can you send me the link to your web page performance test? I'd also like to run some local tests.
Also, what device(s) are using for testing and what versions of the operating system are they running?
In the 4.6 Release, they have optimized the startup routine and reduced the initial download size by ~1 MB.
But IMO, the underlying problem remains that dojo does a lot of script processing on startup which results in higher loading times on older, less performant, hardware.