We have a web application for correcting automatically-detected mistakes in translation documents. Those are split into sentences and their amount can be up to hundred thousands (its not even closely the usual case, but can happen), which causes todays browsers to lag a lot (actions take seconds instead of milliseconds). The whole document is preloaded, so network operations are not the problem, it is the rendering itself.
In the original design, we had one scrollable area with all the items. It is convenient, because the user has to go through all the items eventually and he often needs to see the context of the translations, i.e. be able to scroll a few sentences back or forward.
When discussing the performance issue of rendering so many items, pagination come to mind. But I consider it an UX fail in this case, since every switch to next page would break the users workflow of checking from top to bottom using just his keyboard. The scenario when looking for the context would be even worse.
The "infinite scroll" is also not a solution, because after some time the performance issues would raise, too. Besides, in this use-case, scrollbar position is important for the user - he would like to know that he is e.g. in the middle of the document.
Can you please suggest some other options for dealing with huge numbers of items, which the user must go through?
Screenshot from current design, user always has only 1 item to edit, and works from top to bottom through all items: