Caching behavior is browser-dependent, but I’m pretty sure the combination of max-age=0 and must-revalidate is going to cause most browsers to always check to see if the cache is stale; AND for some resaon, it seems as if Xojo web is no faster delivering a 304 response than a 200 response (and may even be slower at least in some of my tests)
Browsers also cache content if not instructed to avoid it.
Cache-Control: no-cache
This instructs the BROWSER that it must revalidate with the server every time before using a cached version of the URL.
How is your table created? What controls?
Why not? That is the whole purpose of the cahe isn’t it?
to avoid versioning conflicts, you can add the Xojo version number to the filename as Mike D suggested.
Sorry, didn’t see this response until just now - not sure what this is referring to, can you clarify?
Your initial post shows a table with a number of columns and it looks like a web 1.0 weblistbox.
Just realized, that’s not in your app is it?
To make a table that looks right I’ve had to switch to all containers and its running slowly
That is just a web inspector, must be Safari.
I did this on Web 1.0, works great, Even feels faster than the Native. Not using 2.0 because it still feels like a beta
If I have a table of 20 rows by 20 columns it was taking 3 minutes to load the page in web 1.0. They’ve made some change in 2021r1 that sped it up, but it’s still slow.
Am I going to have to suck it up and make my app look like childish crap in web 2.0?
and any claims of continuing to support web 1.0 are BS.
Today’s comments from clients:
“when I am in, it is either not accepting clicks or moving extremely slow.”
“Literally click the button for the skill…10 secs…then the drop comes down…click the skill…5-10 sec before it shows up, and so on”
Wow, your other post censored and closed. My answer censored and deleted. Xojo needs to put more quality in their product instead of censoring the coments that expose the lack of it.
To try to stay on topic here 
and not get this thread closed.
My experiences with Web 2 is that it’s very slow to start up, but once it does, it’s generally faster than Web 1 apps and handles a much higher load gracefully.
My old Web 1 apps would get crushed by over 20 users at once, whereas my Web 2 apps handle 50+ quite easily.
I wonder what’s the difference? My web apps tend to be pretty simple and have small data sets.
John, maybe upload a simple demo project of a 20x20 list taking 3 minutes to load and others can take a look and point you in a direction to speed up UP?
1 Like
This is still an extremely little amount IMHO. For some of our WebApps we need to handle at least 2000 users simultaneous (as requests in the same second) and because of the huge number of requests by Xojos event system to the server, it was no option immediately and we had to move to something else that could.
All depends on for what you intent to use it of course, but for bigger enterprise projects, we found Web 2.0 could not handle it.
The slow startup could be improved by not loading unneeded javascript/css. In the tests I did when Web 2.0 first was released for example, although it had maybe two of three little components on it, big chunks of never used javascript/css was transferred and processed by the browser before the first paint.
As Xojo has full control over what js/css is actually needed for the final app, they could easily get rid of big parts of it in the final app. Most other tools can make that distinction and it would significantly improve the user experience.
Good job on FastStart BTW! I hope at least this comes stock Web 2.0 (as it should’ve been already).
As for the HTTPS problem, I wonder if a workaround couldn’t be using something like Apache/HAProxy to handle the https stuff and let it pass-through the requests locally on the server to the Xojo WebApp over normal http. This is often done in other environments.
EDIT: after re-reading some of this topic, I see you do not like that last suggestion using other tools, but I think in the short run it may be a solution for some.