I’m after some collective feedback from the WeWeb team and others that have published apps (both self-hosted and WeWeb hosted).
Here’s the context in brief;
My editor was crashing on one page.
The diagnosis was I had too many elements on the page.
The frustrating thing was that the majority of elements had conditional rendering, and the performance was unimpacted on the published version – navigation between the elements was swift.
… but the editor became unusable.
The recommendation (and seemingly only solution at the moment) was to split the content across pages to reduce their size.
I proceeded and split the sections into their own pages.
The issue now is I have between a 5-6 second navigation event when a user is navigating between the section – it’s unpleasant and could contribute to churn.
I need to squeeze every bit of performance back so that I get a more seamless UX (like I had on the single page).
So far I’ve made sure;
Every other element outside the ‘workspace’ section is a global instance so isn’t being re-rendered.
I’ve removed any collection or api request being re-called when navigation is occurring between these pages.
Run some comparative tests, simultaneously, with a user in Vermont, USA and myself in Sydney, Australia with significant differences in speed.
It seems to be a server location challenge, but I’d greatly appreciate any advice regarding other things I should try, or whether I have to go down the self-hosting option.
Can you send me an endpoint, so I can benchmark it on my machine? If it’s not something private.
You can do this on your own also, by doing the same request outside of WeWeb.
You see, the way WeWeb works, is that it sends request on your behalf “programmatically” so it’s not like WeWeb is slowing your requests, it’s either Xano, or your connection.
If WeWeb was slow, you’d see nothing in the Network tab for 3 seconds and then it would load in a few miliseconds. If WeWeb was slow by any means, it would be sending the requests slow, not downloading them slow. Because WeWeb doesnt load anything, it’s your browser loading the data.
To benchmark it on your machine, you can simply put your endpoint in a browser and append the parameters as query strings, or create an endpoint that is not secured and has no parameters and test it both in weweb and a browser.
Are your pages private? We already have the problem with other users, when page are private, Weweb server are asking before each navigation if the user is allowed to see this page. If your server is far from the Weweb one, this can cause a big latency on page change.
I’ve just removed private access from the pages in context for a test. It shaves approx. 1 second off this request, compared to the above screenshot. But the content is still rendered in approx. 4.5 seconds
I need the application to be locked down so what is the idea here if I have to remove the ‘Private access’?
@Broberto - it sounds like it’s pointing to my connection then. The only thing that is being rendered is a Section with a Tab Element. The Tab Element has a fair number of divs, but on the page navigation I’m not making any backend request to load data (those requests are made on other actions).
@MichaelLovell experiencing a similar performance issue. No solution so far - so eager to learn what possible fixes / solutions you’ve implemented that remediate performance to an acceptable / desired level.
We are using a WeWeb / Xano combo. Based in Europe.
No no, I just don’t like Xano that much Seems like the only thing together with gated content? these two projects have in common while experiencing these issues. But it’s just a personal biased opinion, until proven otherwise.
I’ll post some more details to the approach I’m experimenting with once I’ve made a direct comparison so that it is more helpful.
But to avoid digression, exporting and hosting the code in Sydney looks to deliver a 90% performance improvement (in the context of what this post was originally about).
Hmm, that’s great discovery, it would still be great to understand what’s up with it. I can’t wrap my head around how it can affect network requests. Might be a WeWeb thing in the end, as Aurelie mentioned the server issue, that might make sense.
To explain a bit further this question of private page.
Weweb is prerendering all your pages. This pages may contains some static content (from static collection, or directly the text you put in an element without binding for ex) and some dynamic content (for example a call to your API).
If your API is secure, and someone not authenticate go to your page, they will only see the static part, and not the dynamic part (as the API will answer 401 or 403)
Because sometimes the static part need also to be secure, when you declare a private page, Weweb will check the authorization on this page when you navigate (their is a call retrieving all the “weweb” data from this page). For that it calls your authentification end point. If weweb server and your auth server are far away, and you also are far from Weweb server, the answer time can start to be long because each exchange add a noticeable delay.
Until Weweb handle localization, and this behavior is a problem for you, you can handle yourself this part.
Double check that you do not have any secure details on the static part, and that any sensitive data is retrieve through a secure dynamic endpoint
Let the page public
Add a onLoad trigger which will check authorization on the page, and redirect to login page or homepage if not authorized.
This is a “bit” less secure, as static info will be available, but most of the usecase this is completly ok.
Seems like the only thing together with gated content? these two projects have in common while experiencing these issues. But it’s just a personal biased opinion, until proven otherwise.