App runs very quick locally.
Number of controls varies, but max is about 10 on a few pages.
Internet speed measured using speedtest.net is about 25 Mbps: http://www.speedtest.net/my-result/3762197527
Let me know what else to test and I will test it. I need to get this figured out today.
Keep in mind all things being equal Chrome will beat IE11 performance every time. The V8 javascript engine is extremely optimized and efficient. I don’t recall IE breaking any speed records with javascript performance. The Xojo web framework is entirely javascript driven. If you have users using older IE browsers performance is going to be bad.
You must also consider what your app does. If you load a listbox with 5000 rows then all those have to be sent over the wire. Locally thats not a very interesting challenge but as JSON web calls it can be a bit of a burden. Optimize optimize optimize. Don’t do anything heavy in your method calls. Break out long running functions into separate utility apps if necessary. Your Xojo web app is single threaded and only aware of one core. Every second its servicing your request it’s putting someone else on hold.
CGI just adds another layer that has to be processed. Apache or similar has to field the request, log the request, decide what to do with it, pass it off to the CGI, wait for a response, and return it. Standalone is faster because it connects directly to the socket. You don’t get the logging and ease of use however.
Xojo web framework sends images down using the framework as well. If your app is stuffed full of images and other resources that are consuming precious bandwidth (i.e. processing time for the app to send them one at a time) then you will see slow performance. Off load those to a web server, S3, nginx, Apache, whatever so some other process somewhere else is dealing with that crap. If you can use just HTML img tags even better, avoid the framework having to make decisions.
Xojo web is extremely fast to develop proof of concept apps in. Like all things you must spend a decent amount of time optimizing if you want the best results. This starts with a reasonable understanding of whats going on under the hood so you can identify potential and obvious bottlenecks. If you have no idea how a browser makes a request to a web app then it will be difficult to optimize and you will likely build a slow app. I’m not saying this is you of course I’m speaking generally. My point is Xojo web is fast to develop with and very powerful. With great power comes… well you know the rest.
[quote=129539:@Ken Gish]App runs very quick locally.
Number of controls varies, but max is about 10 on a few pages.
Internet speed measured using speedtest.net is about 25 Mbps: http://www.speedtest.net/my-result/3762197527
Let me know what else to test and I will test it. I need to get this figured out today.[/quote]
You got to separate connection speed and Internet response time. To take an analogy, the speed limit on a freeway is 90 miles an hour, but in case of traffic jam, cars stop bumper to bumper and much lag occurs.
There is unfortunately nothing you can do when the path between the server and your browser gets jammed. Once can see such delays routinely on all sites. It is the nature of the Internet.
Now, optimizing your app is key to minimize load time. It varies with each app and it is not possible to give you the magic recipe. While writing, I notice Phillip already gave you some pointers.
If you have many pictures, it can be relatively easy to gain much improvement by manipulating their format. Jpeg compression ratio is one way. Other means help, like reducing the number of colors or using indexed colors. For instance, one can find in the Mac App Store PNG Mini which compresses PNG images.
Why not look at some of the sites listed here : https://duckduckgo.com/?q=how+to+reduce+images+size
I hear you. I think in my case the media is the problem. The preloading works pretty well so I might just preload all images. It takes about 10 seconds to preload about 57 640x480 JPGs so that’s acceptable. Even so, I don’t like the idea of having to preload because to me is seems like what you are doing is just downloading the app in chunks; doesn’t seem like a “web” app if you have to preload. It would be much easier and cheaper for me to just package an exe file for download off of a shared server (just a hint of sarcasm there; not completely serious).
I am also fighting IE11. Clearly slower. One tweak that seems to have helped is turning off the new IE11 feature (on by default) where it tries to download the site in the background. Since doing that, IE11 seems downright peppy (but it might just be a random coincidence).
I also made a tweak to a couple pages and this seems to have helped. The cumulative slowdown seems to have been reduced.
I am hoping I don’t have to learn how to deploy standalone apps.
In another thread someone used pictures loaded with the app, until he switched to using files stored on a server and used in the app through their URL. Speed improvement was drastic. I do not use Xojo Cloud so I will not be able to assist doing that, but I remember Greg mentioning ways of making files available “above the app”. It could be worth investigation.
Another approach, instead of having your app unresponsive for 10 seconds while it loads all images, could be to load the first page just with the required images, and load the rest in a thread while the user visits.
Optimizing is just a series of gains that accumulate in making the app much faster…
I have no way to tell you how to test the number of requests needed per page, and the difference or 130 ms per request could do for it. But I have the feeling before going for standalone, there are many things you can do that will bring you much more speed improvement.
I was using URL before to load ImageView component. Switched to loading via me.picture (instead of me.url) when I went to preloading. Problem is, I might have to go back to URL because someone just told me Firefox is asking to “Allow?” each image download (didn’t happen on Chrome or IE11). I guess this means packaging the images up somehow.
Is this the thread you were thinking of?
Latest suspect for cumulative slowdown: segmentedcontrol. I think this component has a glitch in it. I will try to reproduce the problem with a test app.
For all intents and purposes, displaying a preloaded picture or a URL picture is the same. In the first case, the program will assign an on the fly URL to the HTML control, whereas it will simply fetch the picture from the preset URL. Unless the picture storage site is much faster or slower, it makes no difference in time. Except when you preload in your app, as you say, it takes 10 seconds. And it may also take more memory, since the app has to load the pictures in it’s work space. If you load the pictures in each session instead of App, it is a lot more demanding than simply fetching the pictures from a URL.
Google image not only indexes, but caches all the pictures it finds along the way. Whatever the precautions one takes to protect the images, like the well know Javascript which prevents right click, in effect any image you display on an HTML site becomes fair game for download. Short of obnoxious watermarks, nothing prevents anybody to use your images for its site or anything else.
Google spider is an unsupported browser. So when googlebot gets to your app, all it gets is the unsupported browser message, or an error if your do not place code in App.AllowUnsupportedBrowser. So in effect, it has no chance to pillage your pictures, since it will never be able to display them. That is a built in advantage of a Xojo Web App. But it also means a Web app cannot be indexed by Google as it is. See below to render that possible.
But when you place the pictures on a URL, and even if you do not link to them, you run the risk that some misbehaved bot does not respect the instructions in your robots.txt file to ignore it, and index them anyway. All search engines copy on each other, so in no time your folder becomes common knowledge. David suggested to use a different folder at intervals, so it does not happen. But that implies creating the new folder and loading pictures into it. In practical terms, that is an advantage of the load(picture) : it is done automatically for you.
If you still want Google to index your app, so it can be found in a search, look at https://forum.xojo.com/15323-hashtag-in-allowunsupportedbrowser where Ralf Van de Ven uses AllowUnsupportedBrowser to feed Google a text only version of the site for it to index.
The cause of the progressive slowdown was the Google Analytics tracking code. Apparently, the GA tracking code has a memory leak.
I will just use the tracking code on fewer pages.
Spoke too soon. While there is no more memory leak on local pc, app is still slow towards end. Probably a memory leak on Xojo Cloud server. I will try profiling.