What I notice most of all is that the loading time of the web app and the individual pages is very, very slow. You can see the pictures and page building bit by bit.
Yeahā¦ for some people it loads really fast (even on relatively slow connections), for others donāt.
I make test all the way using a couple of Network providers (even on Cell data) that, Iām sure, do not use the same backbone.
In addition, would be good to know the amount of network hops made on every case by the BIG backbone players until the request reach the server
@Christian_Schmitz @Javier_Menendez - I experience this only after a period of inactivity for the tab in which I loaded the Showcase. If using Google Chrome, it is likely the result of Chrome ādiscarding / freezing / suspendingā inactive tabs to manage memory. Not a function of time alone, but time and memory management. Next time you encounter the ātrouble communicatingā dialog, before you reload the page open a new tab and enter the URL chrome://discards/ (you should be able check the status of that particular tab). I had 28 tabs open, with more than half suspended due to inactivity including 2 tabs with the Showcase. I do not believe the issue is with the web app, unless it includes code to terminate the session after a period of inactivity. Even in low bandwidth Xojo Web apps usually perform ok. Interesting to see what info is in the server logsā¦
1 Like
Check feedback 61912. Clicking the Xojo info link at the top, or probably any link to another page, and then back button several times in a row seems to trigger the canāt communicate with server error. I can refresh the page after that and get it back, but there is some issue that is very repeatable from my machine in Safari, Chrome, and Firefox.
Probably the same thingā¦ session lost from the server, so it needs to open a new one.
The list should get bigger with time. It would be useful to have an indicator to show the number of applications in the list.
EddieÕs Electronics web demo should also be incorporated into the list as well.
It is REALLY SLOW no matter wich conenection I tested. The least it takes is 6 seconds, ridiculous for such a simple demo. On other conections (100mb downstream) takes 20 seconds
It is really slow even on a refresh. It is downloading ALL the resources again, what happened with the caching? 
Yes @Ivan_Tellez you report it as slow (as other users do); but others are reporting it as really fast (near instant); so, because the App is hosted in the same server for everyoneā¦ and even many of us being far, far more away of the server than probably you (and getting instant rendering)ā¦ probably the latency and quality of network connection may be an issue?
Iām missing the caching too, itās 0-cache while the framework files doesnāt seem to have changed. Or am i missing something here?
Well, your server is in the New Jersey area, IĀ“m testing with one datacenter in Ohio with an excelent network connection and I get the 20 seconds thereā¦ So, more likely a problem with the server, the app or the framework itself.
Maybe 20 seconds could be tolerable if it is just the first time but, why the caching is not working?
At least with the images, it looks like the cache header is being set properly by the server, but the paths are different each time itās being shown. The browser wonāt realise itās the same file and cannot use its cache.
3 Likes
I did an experiment. Iām currently in a regional town in Australia. Iām likely as remote from your server as anyone globally. Bandwidth @ time of test < 10Mbps (actually 9.45Mbps download). Using Chrome / Win 10 / Incognito mode. Chrome console tools reports:
First Load:
- DomContentLoaded: 3.42s
- Load: 3.52 s
Reload:
- DomContentLoaded: 1.97s
- Load: 2.01 s
Subsequent loads (series of 5 loads) range 1.98 - 2.01 s
Small app (I know) but the experience, even here, is nice.
(No need for sympathy) I usually work off a 100Mbps connection, but thought this would be interesting.
I did take screen shots of the console (if required).
I hope that helps.
It seems like a real issue. I have gotten it again by clicking on an app in the list, then clicking back and going out of the site, because the back button doesnāt work for navigation, and then clicking forward and going back to the page I was on. Then it seems just scrolling the page will trigger the canāt communicate with the server error.
This is not a good sign. I was thinking weād be able to make the back button work properly with web 2 and server communication would be better. Hopefully this is just a bug or a quirk with the way itās deployed, but Iām not seeing any noticeable improvement from web 1 so far.
I read about the back button and I donāt see it using Chrome. Tried Safari and Firefox and both show the back button. Weird.
It occurs when you navigate away from the showcase.xojo site and then press the browser back button to return to the showcase.xojo site. I just tried it and the very first time the showcase site would not load. I filed a feedback case yesterday. Since it occurs when you return to the site after first visiting it and navigating away, then it probably has something to do with attempting to restore the session.
I think Feedback/Web is going to be really fun.
4 Likes
Yes, that happens because the session is closed; so when you go back againā¦ a new session is needed.
Since itās returing a 404 if the session is not existing anymore. It may be better to return 401 (Gone), and then have the client side automaticly recreate (open) a new session ?
Itās pretty annoying since we had this same problem in Web 1.0 and now itās in Web 2.0 again.
1 Like
I hope if you build this with a future Web 2 release, this will fix.
The Web framework should find the cookie and the session identifier for the old session and reuse it.
2 Likes