Web extrem slowly

Hi everyone I am transferring my application from web 1 to web2.
I have an edit container control opening without data takes up to 30 seconds.
Web2 is extremely slow can you tell me if there is a possibility of acceleration?

1 Like

Yes. Stay at Web 1.0 until Web 2.0 is ready. Okay, Web 2.0 has several Issues as I can see and it is possibly so that you need to wait until you are migrating your Web 1 App to Web 2

1 Like

There is currently a known issue with WebContainers in Web 2.0 that causes this slowness at init. I think it’s even fixed for the next release, but I can’t locate the Feedback Case right now.

1 Like

Hi Anthony The problem is not only in the container control but also when switching to the webpage or inserting the control into the webpage in the video attachment Video

Yeah, it looks like you have the Feedback Case two-fer there. The Containers lagging and the CSS caching issues. Both, I think, are either fixed or will be soon.

It has a design flow, the framework makes tones of round trips to the server, plus many other bugs and deficiencies like the no caching of images CSS, etc, etc. If you found that your app takes more time to load than web 1, DONT move it. It is a shame they killed Web 1 in 2019 having Web 2 like that.

1 Like

xojodocs.com isn’t slow - just don’t use, what is known as still having been reported as a bug.

Yes, it does seems to be design flaw which is maybe not solvable unless rewriting the whole framework.
Here is a very good explanation why web2 is not fast.

3 Likes

Does that mean I don’t use components, webpage, containercontrol? so what should i use the xojo web for? :frowning:

2 Likes

It is not just slow, it is painfully slow. And that is the score working around the bugs? :roll_eyes:

1 Like

Well, as said above, there is a known issue with WebContainers. Fixed, but not yet in production, as too big for a point release. I have a handful of FC which are solved as well, but not yet rolled-out.

True, not sure if Google Speed Test is the right tool for analysing the performance of a Xojo Web App. At least the results were never good for a Web App 1 either. In my case of xojodocs it can’t anyways be good, as that app is starting with a nested SQL Select over 6000 rows, so I’m not surprised.

The whole app is not best for performance testing as I’m pushing the weblistbox very hard, with all those icons (in SVG BTW), the listbox was considerably faster without icons and sole text.

I am not saying that Web2 is the fastest possible web application on the planet (it actually isn’t), but it is fast to develop compelling apps and it is by no means slower than Xojo Web 1. It still has bugs (that’s correct). Some smaller, some nasty. Including the one referred by the OP.

1 Like

What an incredibly small minded answer. We’re using the wrong tools to evaluate now?

I just ran the Google test against a Web 1.0 app and it got a score of 90…

Edit: I’ll remind you that I’m here for the technology, not the drama. I’m okay with learning to work around shortcomings, but flat out ignoring them is irresponsible.

6 Likes

Well, Xojo KILLED web 1 with the promisse of a “modern” tool, the Google Speed Test is the RIGHT tool to measure any “modern” web content.

So? the select take a couple of ms IN THE SERVER, and to populate the list, Xojo said that the lazy loading will be fas, so that argument makes no sense at all.

I had a score of 80+ with a web 1 app, with many controls, a custom table using graphics and paging.

Web 2 is SLOW. Denial will not help anyone.

2 Likes

I still bet my app would be no way better in web 1with my bad selects at the beginning. That’s what I wrote. “extremely” slow is for me an app that would open in 5 seconds. For what I’m doing in my code (and this is a playground for me) I’m happy with the actual performance and not interested in any metrics.

I wrote many postings (and I will continue) with flaws in the current version. And it is a pity too that some solved issues haven’t made it into the last point release. But as much as you are annoyed by many things, I’m annoyed by those generic postings claiming that web2 is overall slow. Yes, it is very slow if you are using functionality already known to be broken and with open FCs, for the rest it is ok. OK, in terms that you can build a working app.

1 Like

The sample examples that come with Web 2 do not work either. So if your application uses external javascript to display. I just don’t believe that you will achieve this with the classic use of xojo Ide. I’ve been trying for a week without success. If you want to convince me, publish the source. If Anthony doesn’t know the solution and it’s a Guru for me, it’s probably not

1 Like

Granted, and one of my complaints, which I raised in many postings. And you are aware of those, as you regularly jump like others (including the silent “likers”) on the waggon when someone is complaining about the bad performance of Xojo Web. Though I fully agree that there is room for improvement and an urgent need to fix the open issues and to roll those out those are already (apparently) fixed, I still believe it is wrong trivializing that Xojo Web 2 is “extremely” slow. It isn’t. At least not for me.

I agree on content, but I don’t know for an App. You can slow down WordPress (if we see that as an App) significantly with bad plugins, wrong database settings, etc., and you can quickly speed “WordPress” up by delivering static cached content via plugins. Again I don’t know, and I don’t care; I look at the real performance from an end-user perspective. And I do agree that there is room for improvement, but for me, it is not extremely slow.

Again, I never did metrics. But my last Xojo Web 1 App was anyways developed years ago when Xojo announced Web App 2. It was clear to me that an easy migration path would be unlikely to happen. All I did in the recent past were very small Web 1 Apps, where the login logic was often the largest part of the code. But those I “migrated” during the testing phase “felt” a lot faster.

First of all, great resource your XojoDocs! I was not aware that existed.

I can believe that for you (and other small WebApps) the speed is sufficient. However, when dealing with WebApps that must handle tens of thousands of users and where the dynamic content has to be updated swiftly, it does not. I have written huge WebApps in other tools for that purpose and got great scores (mobile 98%, desktop 100%) and response times under 300ms so it IS possible.

Google’s PageSpeed Insights is a good measurement tool (yes, also for dynamic WebApps) as Google is pushing everyone in that direction. Other (GTMetrix, Pingdom, …) reveal the same issues.

Alwaysbusy

2 Likes

Correct, the right tool for the right purpose, that’s for sure. But when I need max deployment speed, max shortest time to market, little to no hassle to deploy than I’m very happy with Xojo. Would I ever use it to compete with Microsoft on the next Team or build a competitor for Amazon on it? Nope. But I don’t think that’s what Xojo ever had in mind. I might be wrong on the latter, but that’s none of my business :wink:

And when you have mastered Xojo, absolutely! But Xojo is not the only one who can cover those requirements, given one knows those tools with the same passion. But we derail, back to the topic at hand…

2 Likes