Large graphs with many TOs produce a lot of data to transfer when a certain number of records is in the found set.
This works fine in a LAN environment. Over VPN this causes significant delays while loading and scrolling due to much smaller available bandwidth.
Re-writing the concerned part of a solution is one thing, but cannot be done overnight.
What is your experience with a larger file cache settings in order to mitigate delays in scrolling large lists?
May I ask you something back? Why should one want to scroll a large list? Is there not a way to constrain the list early in the process?
Unfortunately not. The customer wanted to see these large lists. It was not a problem until working from home started. Now everyone is hooked on VPN.
We will most certainly rewrite the module. It just takes time...
How many fields are in the specific table? Maybe you could divide the table into two parts - with a 1:1 relationship. And for the list take the part that contains only the fields for the list. This could possibly take away ballast. Have no experience with this, it's just a guess.
__
Like in the party role model you could let the id’s be the same in both tables.
Splitting the table, as you suggest, is the way to go for the base TO (has over 100 fields). However, there are many related TOs, which account for even more payload.
The rewrite will see the graph split up into smaller units and each graph being put on a separate layout.
Only, this takes time and I am looking for a tweak and thought of the files cache 
As far as I know, the changes you make in the data end up in FileMaker's cache. Then increasing the cache should not help you with the list - if I understand that correctly.
_
German: Festlegen von Speichereinstellungen
English: Setting memory preferences
Just a guess, coudl-it be faster to retrieve the data with the Data API ?
One other thing, would it possible to get the data in chunks of say 20 records and when the user scrolls near the bottom then get more data, much like some web apps do ?
I never tried it, but it's worth thinking about this. And if Claris could automatically do this from behind the scene, that would be fantastic !
If you use FMP client then the use of the relationship to lighten the load is not going to work. That will only work for CWP and DataAPI clients.
The quickest strategy would be to reduce the number of records in the list.
Another strategy would be to mirror data in a table that is purpose built for the list view. For example, the list view may only need a few fields. In the mirror table you replicate all the IDs from the original table and then create a 1:1 relationship back to the original table. Create calc fields to dynamically pick up the data from the few fields you need. In that way you can create a very narrow table that is lighter than the original.
That is exactly what Claris do at present, since v14. The implementation is not as clunky as web apps, so you do not even realise that it is happening.
If I understand the concept, the mirrored table is for displaying data. Users are entering data in concerned layout. It is clearly over-optimised for fast-paced work on a list.
It is only today (the solution is online for over two years) that each user does not need to see the full list all the time.
Yes. It is a display concept. You could use scripted edits to manage data entry and push the changes back to the original table but that may be more work than you want to do.
An alternative is to split the table into two. Have one table that only includes the fields needed for the list. The other table can store all the other fields. In the form view, both tables can be combined.
@Malcolm Your alternative is what I described above. You’ve found better words to explain this. 
This is one of the things FileMaker does for the developer behind the scene, and there are more. This is what makes FileMaker apart. But many people don't realize that.