Regading discussions of Web2.0 speed - I think it’s quite a bit faster than web 1.0 in general operation, and can handle much higher load. My old web 1.0 app would fall to pieces with 30+ users, whereas web 2 can handle 80+ with ease on the same hardware.
However, the initial page load time is pretty poor in Web 2.0.
Doing some debugging in Safari, I quickly see a major problem. It appears as if the initial page load pulls in a lot of inidividual files, and even if these files are cached, the 304 “unchanged” server response is stalling for up to 1 second.
Here’s an example - note that even though these items are all fully cached, it’s taking the Xojo web engine up to 1.0 seconds to respond with a simple 24-byte “304 Unchanged” response.
This is testing a Web 2.0 app built with Xojo 2021 R 2.1 on local ethernet. Server = macOS 10.13, client = macOS 11.6 / Safari 15.0. I see the same behavior in Chrome, so I don’t think it’s browser-specific.
While loading several files could be a performance issue with HTTP 1.1, normally you will setup your Xojo Web App behind Nginx or Apache anyway, and they will serve those files using HTTP 2.
That request has been stalled in your browser for 1s, not on Xojo’s, because of using the old protocol. HTTP 1.1 has a limit on the amount of files your browser can download in parallel (six I think, depends on the browser).
CustomColumnTypes.js seems to be a session specific file, so it won’t be cached.
Sorry Mike, but inlining every JS file in the HTML isn’t suggested by that article. Also, improving performance on Single Page Applications is not the same as improving plain marketing websites.
If you’re deploying an internal web app, Xojo standalone is easy and fast enough.
There is a ticket for HTTP/2 support, if you want to give it some points: Feedback #38227
But again, a proper web server is more suitable for public web apps. They will take care of SSL offloading/termination (so Xojo won’t have to deal with SSL), HTTP/2, caching headers and much more. Anything else is just trying to go upstream, I prefer Xojo to fix other things than trying to compete with industry standard dedicated tools.
Tim’s Lifeboat or Xojo Cloud can also help deploying public web apps.
If the external scripts are small, you can inline their contents directly into the HTML document and avoid the network request latency.
However, note that inlining also increases the size of the HTML document and that the same script contents may need to be inlined across multiple pages
Since Xojo web app is a SPA (single page app) this warning is not relevant.
In fact, there’s advice for this type of app:
The files range in size from 521 bytes to 300KB with a median size of about 10KB. “Small” of course is relative, but making 25+ requests for ~10KB files is terribly inefficient.
Nobody is suggesting that Xojo Web should replace a full-fledged web server. It is what it is.
However, Xojo Web 2.0 is an app which has bad performance, (for initial page load) and it would be very straightforward to optimize.
The lack of optimization is causing the initial page load to take 3x to 5x as long as it needs to take. In my opinion, fixing this is a no-brainer.
If I were in charge, I would do this:
see what the problem is with the 304 results taking so long - from my initial investigation, I think the xojo server is doing something wrong with multiple requests (is it serving them up in LIFO order perhaps?) Something doesn’t seem right there.
fix the performance bug with SSL sockets. I think there may be an actual bug, or at best, a poor implenetation of cooparative threading as described in <https://xojo.com/issue/66149>
For clarity, the CustomColumnTypes.js file is generated on-the-fly at runtime because they can be different per session. They also have a high possibility of change and when gzipped they tend to be tiny anyway.
In terms of the rest of the framework, obviously there are a lot more assets to retrieve in web2 vs web1. That’s what we get for using standardized libraries and publicly licensed controls, but the benefits outweigh in terms of speed.
In web1, we generated and delivered the portion of the framework that was needed for a particular session and each time you made a change, the whole thing need to be pulled to the browser again. We also didn’t always take advantage of gzip so the framework transfer could be quite large. The original system also generated a lot of html snippets on the server and delivered them to the browser over the wire, now html is generated completely client side.
With web2, the framework files won’t change unless we (Xojo) changes something in a major release and even then, only the files that have been changed will be delivered again once per browser, but we check every time because we can’t tell when the page loads if you’ve changed the version of Xojo that you’re using. This is however part of the reason the framework can handle more users per instance… less startup overhead.
In terms of deployment, no, you don’t have to use a load balancer like Apache or Nginx, but if you are deploying your app on the public internet, you certainly should. Not only that you’ll be able to host many more users, they provide you an extra level of protection against bad actors because they can filter out requests that don’t need to go to your app.
Good points - it really depeneds on several factors (public vs. private, proxy vs. naked, etc.) but I think the basic issue is that Xojo Web 2.0 is not delivering optimal cache-control values, and this has non-trivial impacts on performance.
Dont get me wrong: In actual use, I find Xojo Web 2 much faster than 1.0, and it can handle a much higher # of users with ease.
The only issue I’m focusing on here is inital load time, for which Web 2 shows some serious issues, which I feel I’ve diagnosed well and offered good suggestions.