Closed dumblob closed 1 year ago
This is an issue with the current design, too many posts and so much media is being shipped to the client. The bundle is 600KiBs AFTER gzip compression, this simply cannot do. I am planning to implement pagination.
Yep, pagination would help (ideally with two buttons "load more content above" and "load more content below").
Alternatively (IMHO as a better alternative but I digress) JS could be used for "infinite scrolling" in both directions (i.e. as a necessary optimization). If no JS on client, then it could nicely fallback to the traditional pagination (as you suggested) with "user clicking instead of AJAX clicking" :wink:.
Also (without looking at the generated HTML) if there are some <table>
or similar tags known to slow down the loads of pages (waiting until the whole table gets downloaded and rendered), I would consider not using them at all.
Pagination has been implemented in it's entirety!
Yep, it does not kill Android Firefox any more and the loading is not anymore infinite.
Yet, the page load is still very slow compared to what I am used. I tried it on my desktop (Chromium) as well as in Android Firefox. Both load still somewhat slowly.
Any ideas why is that (I did not measure it nor run the V app on my desktop itself to see its behavior also on a localhost)?
I live in Australia. Accessing the web application has to perform two hops, one to a front facing VPS, another routed to my home infrastructure. Other than this, the website is very fast.
On average accessing the web page takes 400ms due to latency, and the server spends at most 15ms rendering and replying, usually sub 10ms.
It's extremely performant, but will suffer if you are far away from it.
I use Android 12 with Fenneck (mobile Firefox) and clicking on the example blog linked from the readme leads to an extremely slow experience of both loading of the page and the extremely sluggish scrolling.
After a few scrolling gestures, the browser crashes and restarts.