User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Setup mulitple network calendar (CalDAV) with thousand of items each...

Actual results:

Every time Thundebird starts, it sync all items full time frame (one by one - or by chunk of 100 by default) which is highly inefficient.

Takes 5mn before I can access emails or calendars... as calendar items keep loading... slowly very very slowly...

Expected results:

At startup Thunderbird shall quickly download and sync only items which are relevant like within a time range between 'sync timespan past' 60 days and 'sync timespan future' 365 dyas for example by default.

The rest of data could be downloaded in the background later when TB is idle or less in use (5mn after startup perhaps?).

Also by default the chunk size is set to 100 it would be great to be able to adjust it to a bigger size on per calendar bases for those that use gigabit connection and have multiple calendars with thousands items...

Those three options (chunk size, initial sync timespan past, initial sync timespan future) shall be configurable per calendar via their properties UI interface...

Outlook Caldav Synchronizer (https://caldavsynchronizer.org/) client offer such options and they are quite handy. See attached.

Once again the idea would be to reduce initial sync requests to only what is essentials to maximise performance at startup and leave some options to the end-users.

See also partially related Bug 1247240 "Enable configurable time sync window to mitigate performance problems on very large calendars"

There is already an option available for chunk size in the advanced config editor calendar.caldav.multiget.batch.size for default chunk size of all calendars... but not sure it is really effectively used within the Lightning code... there is a variable set with this value (or 100 by default) but not sure it is applied accordingly during calDAV requests.

This options could be made available on per calendar bases via UI... to allow customisation for each calendar apart from global default value...

See also my Bug 1543953 Comment 9... for info...

Important enough for 68?

While this will be nice to have fixed/improved, I think this is probably too much to tackle for 68, given the current time frame and priorities.