Is it possible to configure Geocortex Viewer as a Progressive Web App to speed up the site response
We are implementing our Geocortex Viewer for public use but our major headache in this project is that after building the site, we observed that it is way too slow when loading and also the response time is pretty slow as well (Takes about 45seconds to load)
I have used Google chrome developers tools to troubleshoot the issue and I have also tried applying some of the recommended best practices to optimize viewer startup performance I found on the Geocortex knowledge base (Article # 000002548)
and these have not yielded much result.
So I am asking to know if it is possible to configure Geocortex as a Progressive Web App to enhance the speed of response.
Please has anybody looked into this? I am not very verse with the Progressive web App technology though.
0
-
Have you looked at Statistics on ArcGIS Server? That can tell you which service is causing the slowdown. How many services do you have on the site, and how many layers on each? There is a lot you can do to speed up sites. What does memory and CPU usage look like on your server? I also had slow sites after switching to HTML5, but have been able to speed them up. Here is a parcel viewer that opens in 5-10 seconds, and even our everything and the kitchen sink site opens in 10-15 seconds.
https://maps.srcity.org/Html5Viewer/Index.html?viewer=parcel
https://maps.srcity.org/Html5Viewer/Index.html?viewer=publiccity0 -
I have a total of 21 Map Services and some of the Map Service have just about 2 layers while some the services have up to 8 to 12 layers.
I also have some Basemaps comprising of Topological Map, Aerial Map and Street Map
All the data sources are registered with the server.
The Server CPU and Memory do not appear stressed to me.
I noticed that some layers that are not supposed to be taking time to published are taking unecessary time for instance a boundary layer which is supposed to be just vector line is shown to be the heaviest when i checked the network tab on chrome developers tool.
I dont know what could be causing that0 -
Is that a public service that I could look at? Where is your data stored? SDE, FGDB? And is it on the same server? What about virus scanning? Turns out we were doing some real time scanning that absolutely killed my services. Are you using cached services for aerials, etc? Why have services with only a couple layers on them? I've been making mine smaller, but all are still larger than your bigger ones. I still have some with 100s of layers. Each service uses resources. Each service needs to be loaded separately. If you made a site with just the one slow service, how long does it take to open? 0 -
I don't want to imply that you can't have that many services (There are 30 in the public site that I gave the URL to), but the trick is to not have them load when the site loads. When using cached services, make sure to remove all of the layers from the service in Manager, since they are not needed. I also do not let many dynamic services activate at load scale - I override the minimum scale for most services, and only have a cached service turn on at load. I generally turn on most dynamic services at about 1:9600. Otherwise, you have to wait for them to each load. 0 -
While I agree with the benefits of tuning map services, I'm also of the belief that the HTML client is somewhat 'heavy' and takes a good while to load, even before the requests for mapping data are sent.
We've done some testing and are finding, on our slower networks the client takes an eternity to load. 90 seconds plus. So no matter what tuning I've done to the map services to help them draw faster, I've still got some serious issues with load times. Loading 5MB+ of client code and libraries takes it's toll when not on speedy networks and I've asked our local GE distributors what can actually be done to help speed things up a little.
... And if you're using Feature Services you might want to turn them off by default also. These layers make an extraordinary amount of query requests to the server when we tested these and sniffed the traffic.
my 2c :)0 -
I mostly look at times across our network, which is where most of my users are. While our folks don't like waiting for the site to load, as long as it is responsive once loaded, they generally keep their grumbles to themselves. I'm probably my worst critic. That being said, we are looking to publish more to the public, where internet speeds vary greatly. More and more we will want users to access our sites using mobile devices with cellular. Gareth is making a very valid point here. Even my lightest sites are slow at times for the public. I'm being pressured to start using AGOL more, and while LG says that's fine for certain applications, I would prefer to use a single authoring tool for all of my sites. I understand that LG and ESRI are partners, but I do wish LG could engineer the client code to be MUCH lighter at load time.
However, I doubt that Irene's issues are so much related to the base code load with times like they are having. For me, one of the best tools to figure out what is causing a site to be slow is to look at the average response times for the various services. By going into ArcGIS Server Manager, and clicking on Logs in upper right and then Statistics in the blue bar. Below is a look at all the dynamic services for my main internal sites. Mine are behaving at the moment, but when a service starts taking more than .5 seconds, you should start looking at it. Pick the worst one first, since that is the one most likely slowing your site down. Take a look at your cached services, but they should all be fast.
0 -
Hi Irene, Mike, Gareth,
It's great to see this conversation, I hope other users can find this information useful. Building the Viewer as a Progressive Web App is not in the works yet, but we are always looking at the newest architectures and methodologies to make sure our products are designed to be as effective and efficient as possible. Mike makes a good point, however - the base code load times are generally not the main issue. Response times in ArcGIS Server and AGOL will have a great effect on the overall load time, as will your Site configuration.
Thanks,
Aaron Oxley0 -
It's an intresting converstation for sure...
I've just hacked our mobile site to include no layerlist items, and only one layer (tile cache). The client is still realtively slow to load, as it's still trying to load 4.5 MB of files - regardless of map data content.
I guess this is my biggest beef with the HTML client - in it's Handheld and Tablet forms. I'm simulating a slow network speed of 1000kbs on an iPad and it's takin g40+ seconds to basically load a blank client with just the map tile base.
If LG could look at improving the load of a site in it's most simple sense that would also be great :)
I'm testing the same things with AGOL and other Web clients we have and it must be said that the GVH is indeed very heavy. I can understand that for perhaps the Desktop client, but for Tablets and Smartphones, it could be argued perhaps that there should be a choice of more lighterweight alternatives.0 -
I agree with Gareth. On a phone, a 5-10 second load time is even too long. Especially since you need to do a fair bit of customization to create any type of animation on load (to let the user know something is happening).
From what I understand though a lightweight alternative is part of the new 5 series viewer. Not sure on release date though. For our simplest maps I've switched over to just using the ESRI JS 4.x API until this gets improved.0 -
Mike,
Your average Time response chart looks good to me. There it is showing a maximum of 0.6 seconds.
I briefly checked mine for a period of 2 hours and this is what I got. Maximum average response time is 4.05seconds
I can identify the services that are causing the damp in response time and i am currently looking at what can be done to quicken them up a bit
0 -
I believe the Average calculates the time of individual loading of these services after the initial loading. Now here is what i have as the maximum response time which i belive includes the time it takes the services to initialize (i.e when the Viewer is just starting up). it looks pretty crazy to me! 
0 -
I always took it to mean what it says: average = the average response time for all calls to service during the period, and max is the slowest response time during period. I like average, but both tell you something. It looks like your public service is having issues. Can you describe that service? Is it always on? How many layers? When it is published, is it giving any warnings in analyzer? Do you ever play with min and max instances? Are you hosting service, or on AGOL? 0 -
I just discovered something - my sites open in Chrome about 1/3 faster than in Internet Explorer... 0 -
Have you tested MS Edge Mike?
This is interesting!0 -
I have always found the Chrome, Firefox etc load and perform much better than IE and we recommmend if at all possible DONT USE Internet Explorer! ;-)
Unfortunately that doesnt really apply to internal desktop users as currently IE is the only option. However, with our Citrix users IT have ensured that any Geocortex Sites open in Chrome by default.0 -
No, haven't played with MS Edge at all. We are an IE shop, except that folks are beginning to use Chrome if they can (not using legacy Apps). Certainly our public users are mostly using Chrome. 0 -
I made a simple site that opens internally on Chrome in under four seconds... Just three services - ESRI's World Topo, and Address service set up with Instant Search, and a service with 5 ParaTransit zones. Not much there, but does show that the HTML5 viewer alone is not what is causing most site open time. I would be curious how fast it is out in the real world...
https://maps.srcity.org/Html5Viewer/Index.html?viewer=ParaTransit0 -
I've tested this a few times and get a pretty consistent 20 second load time down under in OZ. The client takes 15 seconds approx to load.
You're doing well to get it down to 4 seconds!0
Please sign in to leave a comment.
Comments
18 comments