update my browser DB virtualaizer pursuit, IDB is fast and OPFS is SUPER FAST but still the biggest challenges of real time DB reads is the read request itself, then once you are in DB you are good to go so the constraints still are: -single request on render === the delay of the request it self -too many requests === slower so the new idea is to eagerly fire the first read request and prepare to hijack it such hijack operation requires working on JS ticks, treating each tick as progression in time so lets have an IDB example: lets say the user is scrolling fast downward tick one: indexes [1, 2, 3] are requested tick two: [2, 3, 4] tick three: [3, 4, 5] third four: [4, 5, 6] firing a request for each tick would result in 4 parallel read-requests aka "SLOW". soo, we can compare tick 2 with tick 1 to derive the direction (assume defaults for tick 1) and open a read-request in that direction then let any future ticks in the same direction just hijack that same read-request rather than firing a new one so in our example the read-request is fired against tick 1 but it might actually be used to retrieve tick 4 also in case our read-request got fulfilled on tick 3 but its still on-going then tick 4 can still hijack it and extend it instead of firing a new one always prioritizing what is actually on the screen by the time a read-request is fulfilled. View quoted note →