Long loading time

[Snailedlt]

My analytics site has incredibly long loading time (over 40 seconds)!
https://www.apianalytics.dev/dashboard/fb1f330ea13b4f4c91a8de83895e56e3

That's the analytics for this website: https://markdown-videos-api.jorgenkh.no/
The source code is available here in case you wanna look at it as a part of the debugging: https://github.com/Snailedlt/Markdown-Videos

Here's the console log before the loading is done:

And after the loading is done (the same error continues below the screenshot:

Here's the file it's pointing at:

Seems like this is an error, but perhaps adding some form of caching could also speed things up?

[tom-draper]

Thanks for raising this. It really is a problem and it's definitely an issue on the server side, I'm looking into ways to speed up query lookup times.

It looks like those client errors are due to a separate Flagmoji chrome extension. It's failing to convert the location flag emojis on the dashboard into true flag emojis for Windows. I'm not sure why that would be, but it wouldn't be affecting load performance.

[Snailedlt]

Now it doesn't work at all anymore :/
https://www.apianalytics.dev/dashboard/fb1f330ea13b4f4c91a8de83895e56e3

It loads for a good few minutes before it just stops and displays a "server error"

This is the output using Google Chrome:

Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
fb1f330ea13b4f4c91a8de83895e56e3:1 Access to fetch at 'https://www.apianalytics-server.com/api/requests/fb1f330e-a13b-4f4c-91a8-de83895e56e3' from origin 'https://www.apianalytics.dev' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
www.apianalytics-server.com/api/requests/fb1f330e-a13b-4f4c-91a8-de83895e56e3:1

  Failed to load resource: net::ERR_FAILED

Dashboard.svelte:199 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'requests')
at Dashboard.svelte:199:26

On Firefox it looks like this:

And it links to these two resources:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin?utm_source=devtools&utm_medium=firefox-cors-errors&utm_campaign=default
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Unexpected_type?utm_source=mozilla&utm_medium=firefox-console-errors&utm_campaign=default

[tom-draper]

The server is only small and running out of memory on your request. If you try again in a few minutes and wait until it loads, avoid clicking refresh. Does it eventually get through?

[Snailedlt]

Nope, it still doesn't go through due to a server error

[tom-draper]

I'll update the frontend to stop this from happening, but it will be a few days from now. Thanks for letting me know

[Snailedlt]

Great, thanks tom :)

[tom-draper]

Should be working much better now, the data will load in chunks. You may need to clear browser cache with Ctrl+F5. It may take a while for all requests to be pulled into the dashboard. I'll continue to work on improving load times.

[Snailedlt]

Nice!
Now it works!

Takes about 1min to load, but at least it works now! :D

Related to loading though I have another improvement suggestion.

Take a look at this screenshot:

Notice how you can't see what it's loading in. It would be great if the title was showing even though the data is not there yet. This way we can know before the data is loaded if it's a data point we're interested in or not. No use waiting if it's not interesting to us, right? :)

This could also be done for the entire website instead of having the whole website be a big loading icon, make each metric load on their own, and show which stats can be shown before they are shown.

[tom-draper]

@Snailedlt Thanks, that's a good suggestion. The loading is essentially just waiting for another chunk of logged requests to be fetched from the server. It isn't loading anything in particular like certain metrics or processing a particular set of data, that all happens pretty fast. So there isn't really a 'title' that could be displayed as such that would explain to the user what is currently being loaded, it's just waiting for another chunk of requests. It loads requests from most recent to the least recent, so after a while the additional requests may not be relevant for the timescale you are currently looking at (e.g. the last month), so I could hide the loading icon at that point to inform the user that the current page (i.e. currently selected timescale) they are looking at is now 'complete'. If the user selects a larger time period straight afterwards, the loading icon would reappear again. Does that sound like it would be useful, or do you have any other ideas?

[Snailedlt]

Do the titles need to be dynamic? If they don't, I don't see any reason why there should be a loading icon preventing those titles from loading in before the data itself is available. When I say titles I mean these:

They shouldn't need any data in order to be displayed, right?

If they for some reason do need to be dynamic, or you're limited by the libraries you're using. Perhaps you could hardcode a skeleton interface with titles while it's loading?

Sidenote:
If I change the timescale it looks really weird, and also there's no on-click feedback, so for a few seconds it looks like the website or browser froze, since it's impossible to see if the button was clicked or not :)

[tom-draper]

I see what you mean! I agree, I've always thought skeletons would be much cleaner. There's no reason why the majority of the dashboard cannot be rendered with titles before the initial data load. I'll try and get that included soon.
I'll also include some kind of feedback response when clicking on a timescale button. Thanks for these suggestions, if you have any more, let me know!

[Snailedlt]

Awesome! I'll probably have more suggestions down the line, but for now I'm very satisfied with the app except for the things I mentioned already 😄

[Snailedlt]

Actually.
Do you have any idea why the data before July-ish this year is not showing for my api? It has been using fastapi analytics since July last year. So there's about 1 year of data missing from the graphs.

[tom-draper]

There's a limit to how many requests we can store and process per user while still able to keep the service free. I've had to find a balance between decent server infra while avoiding charging users. I'm working on some efficiency improvements that means we can handle more data per user. A self-hosting solution for the backend should be ready within the next 2 weeks, if you wish you take over the processing and storage. In future, I should be able to offer a paid tier that can handle far more data.

[Snailedlt]

That makes sense. A paid tier would be great, as well as being great for your motivation ;)
Perhaps a self-hosting alternative would be good too? :)

[Snailedlt]

@tom-draper any updates on this issue? Seems like it still persists