cal.com
cal.com copied to clipboard
calcom
[CAL-1660] event booking page loads availability slowly without any spinner
Issue Summary
Loading a public availability page shows all the days greyed out for several seconds:
After waiting a few seconds, it loads properly:
I don't remember ever seeing this until recently, so it feels like there has been some kind of regression here.
Proposed solutions
IMHO there are three aspects to this problem, each of which can be tackled separately:
1. Reduce the loading time as much as possible
I don't know if there are architectural limitations causing this delay, but if there is room for optimisation then obviously that would be a very positive step forwards.
2. Show a spinner icon or some other visual indication that the page is loading
Regardless of whether the delay is somewhat unavoidable or can be optimised away, there should certainly be something in the UI which makes it clear to the user that the page isn't broken but it's still loading and that they should wait patiently for the availability to appear. Currently there is no such indication, so users are liable to think it's hung or the site's crashed/broken or similar, and in the worst case they will just give up, close their browser tab, and go away without a successful booking.
3. Show calendar days on first load
Before the availability has loaded, it should immediately display the numbers of the days of the month rather than blank grey squares. At least then while the user is waiting for it to load, they can potentially still use those dates and that calendar month layout to start mentally figuring out their own availability.
Steps to Reproduce
- Go to https://cal.com/aspiers/30-mins or probably any other booking page
- Note that it initially appears like the above screenshot.
- Wait a few seconds
- Note that
Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?
Technical details
Saw this on both Chrome mobile on Android 11, and desktop Chrome on Linux, which are effectively totally different browsers. This seems to strongly indicate that the problem is not specific to browser versions and more likely server-side.
So this may be developer bias but re. (2) the skeleton is our loader - shown whilst the dates are being loaded. It fades in and out to show it's doing something.
- is an interesting suggestion and it ties in to the existing ideas I had for 1. We're looking into ways to improve the performance of the booking pages with high priority.
So this may be developer bias but re. (2) the skeleton is our loader - shown whilst the dates are being loaded. It fades in and out to show it's doing something.
OK that's interesting - I know this is only a single data point but I completely missed the fading in and out, both on mobile and desktop. So if that's your version of a spinner, I think it needs to be much less subtle. Even if I had noticed it, I don't think I'd have been 100% confident of what it meant. Why not be a bit more explicit and at least add a spinner and/or loading message?
- is an interesting suggestion and it ties in to the existing ideas I had for 1. We're looking into ways to improve the performance of the booking pages with high priority.
Great. Thanks a lot for the response!
I think 3. makes sense, we can do that while we find more ways to speed up fetching data faster
It takes more than a few seconds to load on Firefox (both Ubuntu 04/2022 and Android-Fdroid). Unfortunately, that leaves the impression no time slots are available.
related: https://twitter.com/alex_barashkov/status/1638252522895732782?s=46&t=XsU6yrqPhYPfQwlOR-9I-w
@hariombalhara posted: https://www.webpagetest.org/video/compare.php?tests=230321_AiDcV5_B20,230321_BiDc7Z_B2Q
@roae posted:
https://cal-15ihm3fw5-cal.vercel.app/api/experiments/prisma https://cal-15ihm3fw5-cal.vercel.app/api/experiments/raw
avatar took 7s
@zomars posted: https://pagespeed.web.dev/analysis/https-cal-com-peer-15/xtn0x55hru?form_factor=mobile
@roae posted: I removed prisma from avatar's endpoint, here is the preview https://cal-15ihm3fw5-cal.vercel.app/api/user/new-avatar?username=pro
could this be wroth looking into? https://www.prisma.io/data-platform/accelerate
@KATT asked:
Does calendar page still require calls to google et al or is it just a db call?
@PeerRich I think we can ssg prefetch the slots query to avoid some waterfalls.
This is local prod build with a production DB in Frankfurt (local docker is just too fast xd). However, now the flickering is almost causing bad UX on the other way around :/ - not sure how it'll look like in your production environment though.
https://user-images.githubusercontent.com/51714798/227511831-7c1ea9be-1f1f-4f52-878f-2dbc8bd19050.mp4
For contrast, this was the loading before:
https://user-images.githubusercontent.com/51714798/227512031-ad8220b7-b877-4039-a42f-a2af189cb127.mp4
@PeerRich I think we can ssg prefetch the slots query to avoid some waterfalls.
This is local prod build with a production DB in Frankfurt (local docker is just too fast xd). However, now the flickering is almost causing bad UX on the other way around :/ - not sure how it'll look like in your production environment though.
https://user-images.githubusercontent.com/51714798/227511831-7c1ea9be-1f1f-4f52-878f-2dbc8bd19050.mp4
For contrast, this was the loading before:
https://user-images.githubusercontent.com/51714798/227512031-ad8220b7-b877-4039-a42f-a2af189cb127.mp4
I tried this, but getSchedule endpoint depends of client time zone, we need fix that first
I tried this, but getSchedule endpoint depends of client time zone, we need fix that first
You mean if a visitor has changed timezones with the timezone selector that you store in LS?
What would happen then is that the response would come back initially with wrong hours displayed for the booker and then a second later it would get the new response with corrected times?
Why do you need to send the visitors timezone to the server? Can you not convert this on the client and use UTC on server?
You mean if a visitor has changed timezones with the timezone selector that you store in LS?
yes
What would happen then is that the response would come back initially with wrong hours displayed for the booker and then a second later it would get the new response with corrected times?
is not a desired behavior, it should not show the wrong slots.
Why do you need to send the visitors timezone to the server? Can you not convert this on the client and use UTC on server?
is currently required to correctly calculate DST, we are working to eliminate this requirement.
I think we can improve the performance of the getSchedule endpoint if it only responds with the busy slots and generate the slots in the client, it will not be a very big task for the client, since it is only necessary to generate the slots for one day.
a lot of improvements happened in 3.0 launch, lets open a new issue for anything that's left over
I think I do see some performance improvements on loading time, but TBH it's still slow enough (often taking multiple seconds) that everything I originally reported and suggested in this issue is still valid, and I would suggest to keep it open.
The main difference since when I reported it is that choosing the new week view displays a spinner which is a huge improvement over the month view, which still uses grey squares pulsing a tiny bit in lieu of a spinner. But I find that visually this is such a subtle effect, it's barely noticeable and feels like nothing is happening. So with regards to the month view, I stand by all three of my original recommendations here.