Xojo web apps are slow on startup. Any small optimizations are good to take I think.
I see that there are 5 requests could be avoided at startup: framework.js, pagestop.png, appicon.png, dimmer.png, pointer.png files are cached but they still ask the server validation. it might be nice to put a high time for the cache-control. And change the file name if there is an update: framework3.2.js, framework3.3.js …
Even the “open” event seems to be optimizable, but it should be more difficult.
Why not minify framework.js when not in debug mode?
On mobile, small optimizations are helpful, they can do very little of simultaneous requests. It was not so long even desktop browsers could do only two or three simultaneous requests.
Actually, the browser still has to request them, but the framework returns a 304 NOT MODIFIED response if they haven’t changed. That’s about all we can do without changing how browsers cache images.
The problem that we have is that if you rebuild your app, you don’t want the cached versions to be used any more. Especially the framework.js file which could have had code added to it if you started using a control that you hadn’t before.[quote=169341:@olivier vidal]Even the “open” event seems to be optimizable, but it should be more difficult.
Why not minify framework.js when not in debug mode?[/quote]
We have talked about that in the past. The issue that we have at the moment is twofold. First, we’d have to add a minifier to the framework somehow. Second, it makes it impossible for us to remotely debug issues in user deployed projects. I do that a lot, and not having that capability would severely hurt our ability to troubleshoot user projects.
[quote=169431:@Greg O’Lone]Actually, the browser still has to request them, but the framework returns a 304 NOT MODIFIED response if they haven’t changed. That’s about all we can do without changing how browsers cache images.
The problem that we have is that if you rebuild your app, you don’t want the cached versions to be used any more. Especially the framework.js file which could have had code added to it if you started using a control that you hadn’t before.[/quote]
Yes, that’s why I suggest numbering the versions in the file name: framework2015_1.js, and after the release of Xojo 2015R2: framework2015_2.js, etc.
Like this, as there is no update, the browser does not send these requests to each launch. The files are cached, there is no validation request (cache-control: max-age=15552000), and we can still update the files without problems by updating the name.
At these 5 requests, must be added those of framework and ours (librairies, fonts…).
it slows down the application startup, especially on mobile.
Even the style.css might be cached, and without validation request, by numbering and updating the file name.
In the end, this really is not negligible.
As a web application can easily disconnect (no network for a few seconds), it is important to quickly restart the application.
That won’t work. The framework.js file only includes the javascript for the controls that you’ve actually used. Lets say you have a project that only uses WebLabels. The framework.js file would include the base framework plus what’s necessary for WebLabels, nothing else.If you went back to your project and added a WebTextField and build again, the framework.js file now has WebLabel and WebTextField code in it. Versioning the file based on IDE revisions won’t work for that.
Style.css is the same way, because all of the control IDs are generated randomly, there’s no way to cache it.
[quote=169551:@Greg O’Lone]That won’t work. The framework.js file only includes the javascript for the controls that you’ve actually used. Lets say you have a project that only uses WebLabels. The framework.js file would include the base framework plus what’s necessary for WebLabels, nothing else.If you went back to your project and added a WebTextField and build again, the framework.js file now has WebLabel and WebTextField code in it. Versioning the file based on IDE revisions won’t work for that.
Style.css is the same way, because all of the control IDs are generated randomly, there’s no way to cache it.[/quote]
ok, interesting! In this case, automatic numbering work. Whenever the application generates new files, it increments the counter: framework1233.js, and the next change: framework1234.js, etc.
Then we need to keep track of the counter in the project and rely on you to save the project. If you don’t, the next time you run or debug, the cache would be bad anyway.
I understand, but there must be a reliable, for example whenever Xojo generates new files (framework, images of the framework, css), it completes the name with date / time / sec .: framework20150215154423.js
I’m not trying to solve a particular problem. I was working on the cache of a website, it gave me the idea to look at how Xojo managed caches. As xojo web apps are a little slow to start, I think these are interesting optimizations.
Ok, well what I’ll say to you then is that we know there is room for improvement. If you want to see improvement in this area though, you should go back to 2011r2 and compare the speed of the framework then to what we have now. We’ve made a lot of headway since then and it just keeps getting better. If you see specific places where you think we could do better, my suggestion is to file a feature request. Understand though that there will be times when we will just say no because there are things about our framework that either make it impossible or impractical to implement.