I’ll try to be very straight to the point in this post. I’ve got a price comparison website and, in general, I feel like WeWeb is taking too long to display product data (which are retrieved from Xano) and I’m trying to figure out what is causing this delay.
For an example, you can visit my home page and everything that is static loads super quick, but you’ll notice the deal feed (which is a dynamic collection from Xano) takes a few seconds longer than (I feel) it should considering it’s only scanning a database of 1000 products and you can see on Xano it only takes half a second to process:
I feel like I’ve set something up wrong on WeWeb that is causing the unnecessary delay. Let me quickly give you context as to how this is set up:
The Collection
As I stated before, this is a dynamic collection (since prices change throughout the day) with the following fetch settings:
The Loading
I’ve got two sections in WeWeb:
Loading Section - This section only appears if the collection data is being fetched. It lets the user know that the page is loading.
Featured Deals - This is the section that includes the dynamic collection from Xano.
The “Loading Section” has a Display setting to only appear if the Xano collection’s “isFetching” is true.
I feel like this is all setup correctly, but for some reason still have that slight delay and I have the same issue on other pages like this one, which is setup the same way.
Any tips on how I can better diagnose this speed issue?
What a great idea for a video tutorial! As I’m not a big expert on the topic, I’ll ask someone on the team to help me with that.
In the meantime, in this video, you can see me opening the inspector on the Network tab. Then I refresh the WeWeb page to see in the inspector what’s loading and how long it’s taking.
The Fetch/XHR tab is especially interesting because that’s where you’ll find the API calls and responses but you can also check if images and CSS are slowing down your page for example.
Does that help? Don’t hesitate to keep posting your questions in this thread if anything is unclear. It’ll help me understand better what would be helpful in a future video.
@joyce’s advice is spot on regarding starting with the networking tab. That’s where I would go first. I’d look for slow requests, and long the page takes to settle after the request comes back (the latter is measured in a couple of “complete” metrics along the bottom in chrome devtools).
We’ve been discovering issues like speed-of-light limitations and large numbers of components on a page driving user experience in addition to the overhead of hitting the xano instance. Queueing can be a challenge too - Xano can only handle so many simultaneous requests, so it can be that your network request languishes in line even if the request itself is relatively quick. One can compare the time we see in the network tab with the time inside xano to suss out that kind of issue.
But more detailed diagnosis benefit from a slightly more interactive approach. Maybe this would work in weweb office hours? In addition, we’ve recently been working on performance of weweb apps and managing self-hosting over on Statechange office hours.
The queue time indicated here come from the preflight request, made before the request, a preflight request is like a check to confirm with the server this request can be made.
I don’t know why but the preflight take a lot of time and I dont think it should
For an unauthenticated GET request, there shouldn’t be a preflight at all, because in normal circumstances this is a “simple request.”
I did notice the content-type request header is set to “application/json” which IIRC will force the preflight request. An authorization header would do this too, but that’s not the case here.
I bet Weweb throwing this header into all requests. If they remove it for GET requests, I bet you would get some performance juice out of it. Before then, you would probably have to code around it by making the fetch request through custom javascript until then, but that would probably add some work and ceremony in the site.
The browser will only allow so many fetch requests (usually 6) to be outstanding at any one time. So if you make 8 requests, 6 will go and 2 will wait for slots to open up. So lots of simultaneous download requests cause queuing. Also slow requests create a traffic jam. This is why caching and the like has a better-than-linear impact on performance.
The browser can decide that it doesn’t have the bandwidth to deal with the request right now, and takes care of some rendering first. An image-heavy site like yours can have a lot to do on the rendering front, and this will cause downloading more stuff to take a back seat. In general I don’t expect this to be a problem in most systems, but particularly if the site is very responsive and dynamically sized, the renderer can have a lot more to do as content gets incrementally loaded.
There are other reasons for queueing, but those are the big culprits I tend to pay the most attention to.
Nice catch, I will explore it, as well as another things I saw on this blog post that we could try to implement on our side.
You could try to change the content-type header by yourself by adding a custom header globally on the xano and xanoAuth plugins (we added the feature in the previous release).
I’m curious about this as well. It seems that something that’s queried in xano in 0.09s, in the browser takes around 1.9s, and there are no images involved.
